Полезные музыкальные статьи: MIDI Show Control и как на нем работать?

MIDI Show  Control.  С некоторых пор слово "шоу" прочно  закрепилось в нашем языке для  обозначения всего того, что раньше  называлось представлением.  Спектакль, мюзикл, концерт — то есть некое массовое мероприятие, где  задействованы артисты, звук, свет,  видео, спецэффекты. На западе "шоу"  трактуется и в более широком смысле, начиная от мультимедийной лекции  или семинара и заканчивая парками  развлечений по типу Диснейленда. А  если говорят о "живом" выступлении,  то есть когда на сцене работают  артисты, используется более  конкретное Live Show.  Техническое обеспечение  современного шоу может включать в  себя весьма сложный комплекс  оборудования: звуковые и световые  системы, видеопроекторы, механику  сцены, пиротехнику, динамические  пневмофигуры, трансформируемые  декорации, спецэффекты разногокалибра. Многое из перечисленного  (например, акустические системы и  световые приборы) зрители видят  непосредственно. Но есть еще и  подводная часть айсберга —  вспомогательное оборудование,  начиная от простейших механических  переключателей и заканчивая  интеллектуальными устройствами и  робототехникой, а также  компьютерными программами,  обеспечивающими согласованную  работу всех систем.  Технология управления шоу  зародилась еще в 60­е годы, в  развлекательных парках. Все началось, конечно, с ручного управления, когда  стейдж­менеджер подавал команды  голосом, а оператор конкретного  устройства (например, электрического подъемника) их исполнял. Один из  американских стейдж­менеджеров  вспоминает, как ставились мюзиклы на Бродвее: "В шоу было занято от 40 до  50 техников, бегающих за сценой как  сумасшедшие. Я использовал вспышки  света, чтобы дать команду на запуск  определенной сцены, давал командыоператорам через головные гарнитуры  и работал по сценарию, записанному  на листке бумаги".  Сегодня технология управления шоу  — это целая индустрия со своими  стандартами и протоколами. Приборы  одного типа объединены в системы:  управления светом, звуком,  машинерией (механикой сцены),  проекцией, пиротехникой. Каждая  система состоит из контроллера и  конечных приборов, которыми  контроллер управляет посредством  определенных сигналов. Например,  световой пульт может управлять  диммерами и сканерами посредством  цифрового протокола DMX­512 по  интерфейсу RS485. Эти устройства  совместно с пультом образуют  самостоятельную шоу­систему, внутри которой все взаимодействие  происходит с помощью протоколов  класса "контроллер­прибор".  Термин Show Control означает нечто  большее — соединение  самостоятельных шоу­систем в одну  большую управляемую систему. Так,компьютер, подключенный к дым­ машине и регулирующий количество  тумана в декорации морской гавани — это еще не система Show Control, как,  впрочем, и звуковая система,  воспроизводящая шум прибоя сама по  себе. Только объединение этих систем  в одну, управляемую от главного  контроллера, является полноценной  системой управления шоу.  По отношению ко времени все шоу  можно разбить на два типа:  асинхронные и синхронные. Пример  асинхронного шоу — "дом с  сюрпризами" в парке развлечений.  Здесь посетители, бродя по дому,  задевают разные датчики, запуская  сопоставленные с датчиками сцены (то есть последовательности каких­либо  механических процессов, звуковых и  световых сигналов). Все сцены могут  происходить в разных частях "дома"  одновременно и независимо друг от  друга, без привязки к единой шкале  времени.  В синхронном шоу, как следует из  названия, используется некий способсинхронизации событий. Каждое  событие привязано к определенному  моменту времени, а шкала времени  формируется мастер­устройством на  основе, например, видеофрагмента или саундтрека. Мастер­устройство  генерирует таймкод, который  поступает в подчиненные контроллеры или непосредственно в конечные  приборы. Возможен и более простой  вариант, при котором устройства  только стартуют одновременно, по  команде с главного контроллера, а  долговременная постоянная  синхронизация отсутствует. Пример  синхронного шоу — концерт или  спектакль, где световые сцены и  другие элементы шоу  синхронизированы со звуком.  Появление MIDI Show Control В конце 80­х годов прошлого века  протокол MIDI стал привлекать  внимание театральных инженеров и  специалистов по концертному свету в  качестве альтернативы  существовавшим на тот момент  протоколам управления. И хотя MIDI­секвенсоры и средства ввода  (контроллеры) не очень подходили для задач театральной автоматизации, сам  протокол подходил вполне, как по  возможностям, так и из­за невысокой  стоимости и широкой  распространенности.  Основная задача состояла в вызове  сцены, запрограммированной в  световом пульте. На всякий случай  уточню, что сцена — это  фиксированное состояние функций  осветительных приборов. Сцена могла  быть сколь угодной сложной (с  закольцовками, связанными  макросами, подпрограммами и т. п.),  но для ее вызова требовалось нажатие  всего пары кнопок светового пульта:  LOAD (загрузить) и GO (запустить).  Очевидно, MIDI здесь вполне мог  заменить оператора пульта. Все, что  нужно передавать в сообщении, — это  номер сцены и саму команду. А  данные, связанные со сценой,  находились бы в памяти светового  пульта.  Постепенно производители световогооборудования стали использовать  MIDI в своей продукции. Но, как это  часто бывает, возникла проблема  совместимости. Компании,  занимающиеся театральным светом,  производили системы, в которых  сцены менялись MIDI­сообщением  Program Change, а компании,  производящие концертное световое  оборудование, использовали команды  Note On.  В 1989 году Andy Meldrum, сотрудник фирмы Vari­Lite, предложил  разработать открытый протокол,  который позволял бы соединять шоу­ системы разного назначения и разных  производителей, и управлять ими с  помощью любого MIDI­контроллера. К концу 1989 года Charlie Richmond из  компании Richmond Sound Design  организовал рабочую группу в составе  MMA (MIDI Manufactures Association) и открыл форум на электронной доске  объявлений. Созданный в результате  проект стандарта был утвержден  MMA и JMSC (Japanese MIDI Standard Committee) и 25 июля 1991 года  превратился в "Рекомендованнуюпрактику RP­002", или, иначе, в MIDI  Show Control версии 1.0.  Основные принципы Протокол MIDI Show Control (MSC)  предназначен для объединения  интеллектуальных систем управления  шоу­техникой (контроллеров) в  единую сеть. MSC напрямую не  управляет конечными приборами и не  заменяет такие протоколы класса  "контроллер­прибор", как DMX­512  или Strand. Это очень похоже на  соединение MIDI­секвенсора и  синтезатора. Секвенсор посылает  синтезатору высокоуровневую  команду "взять ноту", а синтезатор в  ответ запускает заложенную в его  недрах программу формирования  звука, то есть целый набор  низкоуровневых операций.  В спецификации MSC используются  термины Controller и Controlled Device. Обычно MSC­система состоит из  одного, главного контроллера — им  чаще всего является обычный  компьютер (PC или Mac) ссоответствующей программой  управления и MIDI­интерфейсом.  Этот компьютер и называется в  спецификации словом Controller. А  световой пульт в данном случае  является управляемым устройством  (Controlled Device), которое  выполняет команды главного  контроллера, переводя их в команды  типа "контроллер­прибор" и посылая  последние к световым приборам по  своим коммутационным каналам,  независящим от MIDI (в случае DMX­ 512 — это витая пара с земляным  проводом в оплетке).  Схожим образом к главному  контроллеру подключаются по MIDI  остальные шоу­системы (механика  сцены, пиротехника и тому подобное).  Набор команд MSC основан на  структуре команд существовавших в  то время шоу­систем.  Управляемое устройство (например,  световой пульт) может также  передавать команды MSC через свой  MIDI­выход. Это позволяет  записывать действия, производимыеоператором на пульте — примерно так же, как происходит запись в секвенсор с MIDI­клавиатуры. Только в данном  случае используется программа,  оперирующая не треками, а списками  сцен (Cue List). При записи она  фиксирует все события, приходящие  от управляемых устройств, и  размещает их в списке сцен со своей  позицией на шкале времени.  Таким образом, можно заранее  прописать нужную последовательность событий с каждого пульта управления, используемого в шоу, отредактировать полученные данные, а во время шоу  запустить список на воспроизведение.  В MSC используется таймкод MTC, а  это значит, что управляемые  устройства можно синхронизировать с  главным контроллером. Свет со  звуком, изображение со светом, и всю  систему в целом. При этом точность  выдачи команд по времени равна  одному кадру (то есть около 1/30  секунды).  Кроме того, по MSC можно связать  несколько контроллеров одного типа.Так, например, если две световые  консоли соединены по MIDI, то  нажатие кнопки GO на одной из них  приведет к тому, что вторая консоль  отработает ту же команду GO, но уже  без оператора. Здесь все довольно  очевидно и напоминает  первоначальное предназначение MIDI  — управлять с одной клавиатуры  несколькими синтезаторами  одновременно.  Важный принцип управления "живым"  шоу состоит в том, что сбой одного  управляемого устройства не должен  привести к сбою в управлении другими устройствами. Этот принцип может  быть реализован с помощью открытой  или закрытой петли.  В системе "открытая петля"  подтверждение команд от  управляемого устройства к  контроллеру не требуется.  Используется однонаправленная  передача данных и, соответственно,  одностороння коммутация. То есть,  MIDI­выход главного контроллера  соединяется с MIDI­входомуправляемого шоу­устройства, и  только. Этот экономичный способ был выбран в MSC в качестве основного.  В системе "закрытая петля"  используется взаимная коммутация  устройств и ожидается  стандартизированный ответ от  управляемого устройства. Такая  система требует более  интеллектуальных контроллеров и  занимает большую полосу  пропускания, но при этом достигается  большая точность во взаимодействии  устройств, обнаружение, коррекция  ошибок и прочие прелести. Метод  закрытой петли предложен в версии  MSC 1.1, появившейся в феврале 1996  года (документ RP­014). Для работы в  режиме закрытой петли используется  двухэтапный протокол подтверждения (2 Phase Commit), о котором  поговорим в следующей статье.  Предосторожности и ограничения В шоу­системе нередко используется  опасное оборудование (в том числе  представляющее угрозу для жизни),например, пиротехника или механика.  Но это не значит, что такое  оборудование управляется MSC  непосредственно, и сбой или ошибка в  программе приведут к неприятным  последствиям. Спецификация  крупными буквами предупреждает:  "[Протокол MSC] никоим образом не  отменяет обычные меры безопасности,  какие должны соблюдаться при  использовании потенциально опасного  оборудования. Для максимальной  безопасности должны применяться  такие ручные элементы управления,  как аварийные выключатели,  блокираторы, ограничители, системы  подтверждения команд и прочее. Из  автоматических устройств —  запирающие переключатели, датчики  близости, детекторы газа,  инфракрасные камеры, датчики  движения и давления. Протокол MSC  не предназначен для отдачи команд  опасному оборудованию. MSC лишь  подает сигнал о действии, которое  желательно выполнить, если все  требования и условия безопасности  соблюдены. Только соответствующим  образом спроектированные системы иподготовленный обслуживающий  персонал могут определить, насколько эти требования выполняются в  конкретной ситуации. Метод  двухэтапного подтверждения 2PC  исключительно надежен и может  использоваться для обеспечения  дополнительной безопасности в шоу­ системах. Однако 2PC должен быть  реализован в соответствии с  требованиями этой спецификации и  только в дополнение к  вышеперечисленным мерам".  MIDI Show Control не является  единственно возможным решением для управления шоу­системами. Он не  лишен некоторых недостатков,  присущих технологии MIDI в целом.  Первый недостаток — невысокая  скорость передачи данных, а,  следовательно, не всегда адекватное  время отклика приборов. Иногда эта  проблема устраняется простой  разгрузкой линии, то есть соединением приборов не цепочкой, а "звездой" из  распределительной коробки (MIDI  Thru Box) или многоканального MIDI­ интерфейса/маршрутизатора.Для большинства же задач управления  шоу, скорость MSC вполне приемлема  и даже избыточна. Например,  стандартная команда "Свет­Сцена  36.1­Пуск" займет 10 байт, которые  будут переданы примерно за 3 мс  (подробности смотрите в предыдущих  статьях цикла). Это время примерно в  сто раз меньше среднестатистической  скорости реакции оператора пульта.  Второй очевидный недостаток —  максимальная длина MIDI­кабеля,  которая не должна превышать 15  метров. Он может быть устранен  применением усилителей на линии  ("бустеров"), в результате чего длина  линии может быть доведена до трехсот и более метров. Кроме того, есть и  другие варианты передачи MIDI­ сообщений (FireWire или  беспроводные системы).  Формат сообщений Сообщения MIDI Show Control  относятся к категории универсальных  эксклюзивных сообщений реальноговремени (Universal Real Time System  Exclusive) и используют Sub­ID#1 =  0x02 (подробнее о системных  сообщениях и Sub­ID см. в третьей  статье цикла).  Шаблон сообщения MSC показан на  рис. 1. Начинается сообщение байтом  0xF0, признаком SysEx. Затем идет  байт 0x7F, определяющий категорию  реального времени, затем передается  номер прибора, которому адресовано  сообщение. Далее — Sub­ID 0x02,  признак MSC. Байт формата команды  показывает, к какой категории  оборудования относится сообщение: к  звуку, свету, механике и т. п. Далее  следует сама команда. Как правило,  это одно действие, например, "пуск"  или "стоп". Затем передаются  дополнительные данные — параметры  команды. Чаще всего это номер сцены  и данные времени. Завершается SysEx­ сообщение, как обычно, байтом 0xF7.  Общее число байт в сообщении MSC  не должно превышать 128.Как правило, команды адресуются  одновременно только одному  устройству. Например, для  выполнения команды GO на двух  световых пультах нужно передать от  главного контроллера сообщения,  показанные на рис. 2.  Номера с 0x00 по 0x6F соответствуют  индивидуальным устройствам. Номер  устройства, как правило, задается  пользователем в настройках (как  главного контроллера, так и  управляемого). Возможно также  создание групп устройств, для чего  используются групповые  идентификаторы (с 0x70 по 0x7E, то  есть всего до 15 групп). Это удобно,  если одни и те же сообщения  необходимо постоянно посылать  нескольким устройствам. Не все  устройства обязаны отвечать на  групповые номера.  Наконец, есть специальный  широковещательный номер 0x7F,который используется для передачи  сообщений всем устройствам сети,  независимо от того, на какой номер  они настроены. Один управляемый  контроллер может отвечать на  несколько номеров, как  индивидуальных, так и групповых. И  наоборот, несколько управляемых  контроллеров могут отвечать на один  и тот же номер, что позволяет  обойтись для них одним сообщением.  Формат команды Название "формат команды"  (command_format), на мой взгляд,  несколько неудачно, поскольку не  отражает сути вопроса; к тому же, его  можно перепутать со следующим  байтом — самой командой. Формат  команды в терминологии MSC — это  просто­напросто категория  оборудования, для которой  предназначено сообщение.  Стандарт определяет несколько общих категорий, внутри них — несколько  более конкретных, и особую  категорию All­types. К общимкатегориям относятся свет, звук,  машинерия, видео, проекция,  спецэффекты и пиротехника. Номера  этих категорий содержат в младшем  полубайте ноль, за исключением  категории "свет". Номера более  конкретных категорий заключены  внутри общих и имеют тот же старший полубайт, что и общая категория (рис.  3).MIDI Show  Control.  Двухэтапное подтверждение (2PC, Two Phase Commit) — это особый метод  взаимодействия устройств, при  котором все команды подтверждаются  и до выполнения, и по завершении.  Технически — это набор команд,  расширяющих базовую версию  протокола MIDI Show Control. Этот  набор появился в 1996 году и описан в  документе RP­014, выпущенном  организацией MMA. Вместе с исходной спецификацией MSC (документ RP­ 002) он образует новую версию  протокола (MIDI Show Control 1.1).  При разработке метода 2PC стояла  непростая задача — обеспечить связь  нескольких устройств закрытой  архитектуры друг с другом, при  которой все они работают согласованно либо не работают совсем, независимо  от наличия ошибок в коммутационных  каналах. Задача была решена с  использованием двух фаз (этапов) в  коммуникации. На первом этапе всестороны соглашаются о том, что  должно быть сделано. На втором этапе  стороны реализуют это соглашение и  сообщают о результатах.  Метод двухэтапного подтверждения  напоминает метод сценической  координации, применяемый при  взаимодействии стейдж­менеджера и  оператора устройства. Первая фаза —  ожидания (STANDBY), соответствует  команде "приготовиться". Вторая фаза  — "выполнить" или "пошел" (GO).  Метод 2PС предлагается использовать  для тщательно спланированных шоу и  тогда, когда в целях безопасности  требуются дополнительные проверки и  избыточность в механизмах управления (например, при работе с машинерией  или пиротехникой). При этом  обеспечиваются проверка данных и  обнаружение ошибок в  коммутационных каналах.  2PC требует взаимной коммутации  устройств. Это значит, что, кроме  соединения главного контроллера с  контролируемым устройством,требуется и обратное, то есть MIDI­ выход пульта управления прибором  соединяется с MIDI­входом главного  контроллера. Команды 2PC образуют  четвертый рекомендованный набор (о  первых трех см. предыдущую статью),  он приведен в таблице на рис. 1.  Спецификация предполагает, что в  системе 2PC около каждого  контроллера и контролируемого  устройства присутствует человек­ оператор, который называется в данном случае "локальный оператор".  Локальный оператор может просто  наблюдать за процессом, либо  выполнять дополнительную проверку  безопасности и ручное вмешательство в управление при сбое оборудования.  Предполагается, что локальный  оператор выполняет свои функции  через специальную панель управления(пульт или схожий интерфейс),  который называется "интерфейс  локального оператора".  Сообщения 2PC В отсутствие сбойных ситуаций для  выполнения одной сцены в протоколе  2PC используются четыре сообщения.  Они показаны в таблице на рис. 2 с  указанием порядка следования и  стороны­отправителя.  Сначала главный контроллер посылает  подчиненному устройству сообщение  STANDBY ("приготовиться"). Это  сообщение "разогревает" прибор и  уведомляет его о том, что скоро  должна быть выполнена заданная сцена. В ответ на это устройство отвечает  контроллеру сообщением  STANDING_BY ("наготове"),  показывая свою готовность выполнитьданную сцену. Для выполнения сцены  главный контроллер посылает  сообщение GO_2PC. Последнее  сообщение серии, COMPLETE  ("выполнено"), посылается прибором  главному контроллеру и сообщает о  том, что выполнение сцены завершено  успешно.  Предусмотрены также три сообщения  на случай, если произошел сбой:  ABORT, CANCEL и CANCELLED.  Если контролируемое устройство  обнаруживает сбойную  (исключительную) ситуацию, то есть  ситуацию, когда нормальное  выполнение сцены невозможно, оно  уведомляет об этом главный  контроллер посредством сообщения  ABORT. Для указания причины сбоя в  это сообщение помещается код  состояния, на основании которого  главный контроллер может выбрать  дальнейший вариант действий.  Сообщение CANCEL посылается от  контроллера к прибору и говорит о  том, что предыдущее сообщение(STANDBY и/или GO_2PC) нужно  отменить. В ответ на это прибор может  ответить сообщением CANCELLED  ("отменено"), подтверждая отмену  предыдущих команд.  Сообщения 2PC имеют несколько  общих элементов, таких как номер  секвенции (nn nn), контрольная сумма  (сс), код состояния (s1 s2) и данные  сцены (d1 d2 d3 d4). Эти элементы  описаны далее, в соответствующих  разделах. На рисунках 3­9 показана  структура сообщений 2PC.Номер секвенции Нумерация сцен в сообщениях от  контроллера к контролируемому  устройству происходит в протоколе  2PC так же, как и в обычных  сообщениях MSC (то есть с помощью  полей Q_number, Q_list или Q_path,  см. предыдущую статью). Кроме того, для каждого из сообщений  STANDBY, GO_2PC и CANCEL  главный контроллер генерирует  уникальный номер (от 1 до 16383),  который называется номером  секвенции. Этот же номер передается в  обратных сообщениях  (STANDING_BY, COMLETE,  CANCELLED и ABORT), и по нему  главный контроллер определяет, к  какой сцене относится сообщение.  Таким образом, в обратных сообщенияхдостаточно использовать только номер  секвенции, полный номер сцены  передавать не нужно.  Номера секвенций позволяют работать  по методу 2PC простым устройствам,  таким как различные детекторы и  датчики. Например, детектор газа  может не понимать концепцию сцен.  При получении сообщения STANDBY  он просто проверяет наличие газа. Если газ не обнаружен, детектор отвечает  сообщением ABORT, если обнаружен  — сообщением STANDING_BY.  Детектор игнорирует поля типа  Q_number и просто копирует номер  секвенции из входящего сообщения в  исходящее. Кроме того, номера  секвенций облегчают отслеживание  ответных сообщений от  контролируемых устройств оператору  главного контроллера.  Контрольные суммы Каждое сообщение 2PC содержит  контрольную сумму, состоящую из  двух MIDI­байт (14 бит). При расчете  контрольной суммы поляcommand_format, command и data  сообщения рассматриваются как  массив двухбайтовых значений. Если  число байт в этих полях нечетное, для  расчета суммы в конец добавляется  один нулевой байт. Перед расчетом те  байты, которые занимает контрольная  сумма, обнуляются.  Контрольная сумма рассчитывается  путем простого сложения элементов  полученного массива, при этом  переполнения игнорируются. После  чего к полученному результату  прибавляется номер устройства. В  завершении над полученным числом и  константой 0x7F7F (32639)  выполняется логическая операция AND (см. статью цикла "Передача данных.").  Сторона, принимающая сообщение,  проверяет его правильность, заново  рассчитывая контрольную сумму и  сверяя ее с полученным значением в  сообщении. Если контрольная сумма  отличается на стороне  контролируемого устройства, оно  посылает контроллеру сообщение  ABORT с кодом состояния "ошибкаконтрольной суммы". Если сумма  отличается на стороне контроллера, он  реагирует на это так, будто было  получено сообщение ABORT.  Коды состояния Коды состояния используются в  сообщениях ABORT и CANCELLED и  отражают причину ошибки или  состояние отмененной сцены. Код  состояния представляет собой  беззнаковое двухбайтовое целое число.  Чтобы оно могло быть передано по  MIDI, два младших бита числа должны  быть нулевыми. Соответственно,  наименьший код состояния будет равен 4, наибольший 0xFFFC (65532). В  описании сообщений статус­код  выглядит как "s1 s2". Метод  преобразования кода состояния в  значения s1 и s2, и наоборот, показан на рис. 10.Есть три числовых диапазона кодов  состояния. Первый диапазон — общий  для всех форматов команд, коды  состояния в нем применимы для любых типов контроллеров. Характерная  особенность этих кодов в том, что все  они являются отрицательными  числами, если рассматривать код как  целое число со знаком (подробнее о  представлении целых отрицательных  чисел см. четвертую статью цикла). Все коды, возвращаемые в сообщениях  CANCELLED, попадают в этот первый  диапазон.  Второй диапазон зависит от формата  команды, то есть специфичен для  устройств определенного типа.  Например, код состояния 0x1008  означает "низкое давление воды", если  получен от устройства типа  "спецэффект" (формат команды от  0x50 до 0x5F). Но когда тот же код  получен от устройства управления  звуком (формат команды от 0x10 до  0x1F), он означает "неполадки в  усилителе".  Третий диапазон зависит как отформата команды, так и от  производителя. То есть, производители  используют коды состояния в третьем  диапазоне по своему усмотрению.  Информация об этих кодах  обязательно должна быть  опубликована. Естественно,  наибольшая совместимость систем  достигается в том случае, если коды из  этого диапазона используются как  можно реже. Спецификация 2PC  рекомендует всегда, когда это  возможно, использовать коды  состояния из второго диапазона.  Код состояния 0 зарезервирован на  случай неизвестной ошибки или  ошибки, для обозначения которой  другие коды не подходят. Таблица на  рис. 11 подытоживает вышесказанное.  В таблицах на рис. 12 и 13 приведены  все коды состояния, не зависящие отформата команды. Буквы в столбце  "Сообщения" показывают, какие  сообщения могут привести к  получению ответа от устройства с  данным кодом состояния  (S=STANDBY, G=GO_2PC,  C=CANCEL). Первая таблица  содержит коды состояния,  используемые в сообщении  CANCELLED, вторая — в сообщении  ABORT. Обратите внимание, что  сообщение ABORT, посланное  прибором в результате обработки  сообщения CANCEL, может иметь  только два кода состояния:  "неизвестная/неопределенная ошибка"  и "ошибка контрольной суммы". Код  состояния "тайм­аут" никогда не  появляется в реально передаваемых  сообщениях, он включен для  упрощения внутреннего устройства  контроллера.В таблице на рис. 14 перечислены коды  состояния из второго диапазона, то  есть коды, которые зависят от формата команды, но применимы ко всем  производителям устройств.Данные сцены В сообщениях STANDBY и GO_2PC  используются четыре семибитных байта данных. Эти байты должны  присутствовать обязательно,независимо от того, используются ли  они контролируемым устройством или  нет. Если корректные значения d1­d4  для данной сцены (или для данного  прибора) неизвестны, на их месте  должны быть переданы нули.  Байты данных позволяют сопоставить  со сценой дополнительную  информацию. Например, в световых  пультах, работающих по принципу "Go  On, Go Off", используется величина  "Go Level", или gl, которая задается  выражением gl = d1 + (d2*128).  Последовательность команд  STANDBY­GO_2PC со значением  gl=255 эквивалентна команде Go On.  Та же последовательность со значением gl=0 эквивалентна команде Go Off.  Допустимы и промежуточные значения  gl от 0 до 255. Например, значение  gl=128 эквивалентно команде "Go Cue  To 50%". Любое значение gl вне  диапазона 0­255 в настоящее время  является некорректным, а при его  получении прибор должен отправить  сообщение ABORT со статус­кодом  "некорректное значение данных сцены  d1". Значения gl=256 и вышезарезервированы для возможных  будущих расширений.  В других типах устройств  использование байтов d1­d4  определяется производителем и  должно быть описано в документации.  Если устройство получает  некорректные данные d1­d4, оно  должно ответить сообщением ABORT с одним из кодов состояния  "некорректное значение данных сцены  dx". Например, некорректное значение  d1 должно привести к сообщению  ABORT с кодом "некорректное  значение данных сцены d1". В тех  случаях, когда ошибка данных касается более чем одного байта d1­d4,  сообщение ABORT должно содержать  код состояния, соответствующий  наименьшему ошибочному байту.  Устройства, которые понимают только  часть байтов данных, например, d1 и  d3, должны игнорировать значения  остальных байт.  Взаимодействие устройств Итак, выполнение сцены начинается скоманды "приготовиться" (STANDBY), которую главный контролер посылает  контролируемому устройству. Главный  контроллер ожидает ответного  сообщения STANDING_BY в течение  двух секунд. Если за это время оно не  приходит, главный контроллер считает, что прибор ответил сообщением  ABORT. Если по любой из причин  прибор не может подготовить данную  сцену к выполнению, то он отвечает  сообщением ABORT явно.  Ответное сообщение STANDING_BY  посылается только в том случае, если  запрошенная сцена известна прибору,  находится в его памяти и готова к  немедленному выполнению. В  сообщении STANDING_BY прибор  передает также максимальное время,  требуемое для выполнения сцены.  Позже контроллер использует это  время, чтобы определить, не произошел ли сбой в контролируемом устройстве.  Максимальное время может быть  значительно больше реально  требуемого для сцены, но никак не  меньше. Если для выполнения сцены  требуется вмешательство оператора, товремя ожидания действий оператора  также должно учитываться.  После успешного обмена STANDBY­ STANDING_BY главный контроллер  посылает сообщение GO_2PC, которое  приводит к выполнению заданной  сцены. По завершении сцены прибор  отправляет в главный контроллер  сообщение COMPLETE. Если во время  выполнения сцены происходит сбой,  прибор немедленно передает  сообщение ABORT с соответствующим кодом состояния. Если сообщение  GO_2PC пришло с тем номером сцены,  для которого еще не поступало  сообщения STANDBY (вероятно, из­за  ошибки в главном контроллере), то  прибор должен ответить сообщением  ABORT с кодом состояния "не в  режиме ожидания".  Контролируемое устройство не обязано помнить акт обмена STANDBY­ STANDING_BY для какой­либо сцены  продолжительное время. Например,  если сцена была успешно согласована, а главный контроллер послал сообщение  GO_2PC только через час послесогласования, прибор может просто­ напросто забыть, "о чем идет речь", и  ответить сообщением ABORT с кодом  состояния "не в режиме ожидания".  Возможен также случай  предварительного согласования  STANDBY­STANDING_BY для  нескольких сцен с одним и тем же  прибором до того, как будет передана  первая команда GO_2PC. В этом  случае устройству нужно помнить  несколько сцен, находящихся в режиме  ожидания. Производители должны  публиковать максимальное число таких сцен. Хранимый в памяти акт обмена  STANDBY­STANDING_BY очищается по получении сообщения GO_2PC.  Чтобы выполнить сцену повторно,  требуется новое согласование.  Тайм­ауты Основной метод обнаружения ошибок  по методу 2PC состоит в отслеживании временного интервала между  отправкой сообщения прибору и  получением от него ответа. Если этот  интервал превышает максимальнодопустимый, наступает тайм­аут.  Главный контроллер расценивает тайм­ аут так, будто прибор передал  сообщение ABORT с кодом состояния  "тайм­аут". Этот "искусственный" код  (поскольку он никогда не посылается  прибором явно) говорит контроллеру о  том, что контролируемое устройство  перешло в неуправляемый режим (по  крайней мере, по протоколу 2PC).  Для сообщений STANDBY и CANCEL  тайм­аут равен двум секундам.  Поэтому, например, сообщения  STANDBY должны посылаться как  минимум за две секунды до  предполагаемого времени отправки  сообщения GO_2PC.  Тайм­аут на сообщение GO_2PC (то  есть время между отправкой этого  сообщения и прихода ответного  COMPLETE) не является величиной  постоянной и зависит от  продолжительности сцены, переданной  прибором в сообщении  STANDING_BY. Если после запуска  сцены сообщение COMPLETE не  пришло в течение 125% от указаннойпродолжительности, то контроллер  расценивает это как тайм­аут.  Дополнительные 25% нужны для учета  "разброса часов" в контроллере и  контролируемом устройстве.  Ожидание сообщений Метод 2PC был разработан так, чтобы  контролируемые устройства никогда не ожидали сообщений от главного  контроллера. Прибор просто принимает сообщение, выполняет предписанные  им действия и возвращает ответное  сообщение. Даже в состоянии  "наготове" прибор лишь помнит обмен  STANDBY­STANDING_BY, который  был произведен в недавнем времени, но  не находится в постоянном ожидании  команды GO_2PC.  Преимущество такого способа работы  очевидно. Так как контролируемое  устройство никогда не ждет  сообщений, оно всегда готово принять  команды ручного управления от  локального оператора. Следовательно,  если даже главный контроллер даст  сбой, шоу может продолжаться сиспользованием ручного управления на  каждом из устройств.  Главный контроллер по определению  должен ожидать сообщений  STANDING_BY, COMPLETE и  CANCELLED в течение определенного  времени. Более того, он должен  одновременно ожидать многочисленные сообщения, чей порядок отправки не  определен. Поэтому в контроллере  применяется некий алгоритм  обнаружения тайм­аутов для  множества сообщений от множества  приборов.  Обработка исключительных ситуаций Подобная обработка основана в методе 2PC на простом принципе. Если на  очередную команду главного  контроллера какой­либо прибор  отвечает сообщением ABORT, то вся  система переходит в специальную фазу  восстановления. Главный контроллер  посылает всем приборам системы  сообщения CANCEL, информируя их  об отклонении от безошибочнойпоследовательности сцен. Это  сообщение посылается для тех сцен,  которые находятся в состоянии  "наготове" или уже выполняются.  Если отменяемая сцена находится в  состоянии "наготове", то акт  согласования STANDBY­ STANDING_BY просто забывается.  Если сцена уже исполняется, прибор  может выполнить одно из действий:  1) завершить сцену как обычно;  2) приостановить сцену, ожидая  дальнейшего ее выполнения;  3) прекратить сцену без возможности  дальнейшего ее выполнения;  4) вернуться к состоянию, которое  было до начала выполнения команды  GO_2PC;  5) выполнить сцену в обратном  порядке.  Кроме того, в процесс может  вмешаться локальный оператор и  перевести прибор в режим ручного  управления.  Какое из этих действий будет  выполнено, зависит от оборудования иобстоятельств, при которых получено  сообщение CANCEL. Если  выполняемая сцена приводит к какому­ либо вреду, вероятно, лучший выбор в  данном случае — завершить сцену.  Если сцена приводит к неопределенной, ненадежной ситуации, ее следует  приостановить, сбросить или  выполнить в обратном порядке.  Конечное решение зависит от  оборудования и ситуации в шоу.  Некоторые приборы всегда выполняют  одно из перечисленных  восстановительных действий, другие  позволяют это действие  запрограммировать. Поведение прибора при получении сообщения CANCEL  должно быть документировано  производителем.  Если устройство решит завершить  сцену в обычном порядке, оно должно  послать как сообщение CANCELLED с  кодом "в процессе завершения", так и  сообщение COMPLETE. Первое из них  посылается в ответ на сообщение  CANCEL немедленно, второе — после  фактического завершения сцены.Сцены, приостановленные сообщением  CANCEL, могут продолжить  выполнение после обмена STANDBY­ STANDING_BY­GO_2PC.  В любом случае, на сообщение  CANCEL прибор должен ответить либо сообщением CANCELLED, либо  сообщением ABORT. Последнее  допустимо только в том случае, если в  сообщении CANCEL обнаружена  ошибка контрольной суммы. Если на  сообщение CANCEL не получен ответ в течение двух секунд, контроллер  обработает ситуацию так, будто было  передано сообщение ABORT.  Сообщение ABORT, как говорилось  ранее, посылается контролируемым  устройством в случае сбоя при  выполнении команд STANDBY,  GO_2PC или CANCEL. Номер  секвенции в этом сообщении говорит  контроллеру о том, какое из сообщений STANDBY, GO_2PC или CANCEL  вызвало сбой. Код состояния  показывает наиболее значимую причину сбоя, однако могут быть и  дополнительные, менее важныепричины. Поэтому исправления  сбойной ситуации на основе одного  кода состояния может быть  недостаточно.  Значимость кода состояния  пропорциональна легкости, с которой  сбойная ситуация может быть  исправлена. Например, код  "блокирующий переключатель не  установлен" менее значим, чем "сбой в  моторе". Первый сбой может быть  исправлен немедленным  вмешательством человека; второй,  возможно, удастся исправить, только  разобрав мотор.  Код состояния "manual overriding in  progress" ("сцена в процессе ручного  управления") показывает, что  локальный оператор контролируемого  устройства взял на себя контроль за  выполнением сцены. Некоторые  устройства могут игнорировать все  сообщения 2PC, пока локальный  оператор использует ручное  управление.  Иногда сообщение ABORT не означаетсбой устройства, а просто говорит о  том, что ожидаемое событие все еще не произошло. Подобное поведение  характерно для всевозможных  датчиков и детекторов. Для таких  приборов главный контроллер не  передает сообщение CANCEL.  Пример работы 2PC Посмотрим, как может использоваться  метод 2PC на практике. Для простоты  возьмем небольшую координированную последовательность команд,  образующих сцену. Сначала опишем  процесс обмена сообщениями без  ошибок, затем рассмотрим несколько  сбойных ситуаций и то, как они могут  быть обработаны.  В сцене будет задействован  моторизированный поворотный стол, на котором находится некая конструкция  (предположим, небольшая декорация).  Изначально декорация повернута к  зрителю "спиной", так что задача стола  — развернуть ее на 180 градусов,  лицом к зрителю. Поворот стола  происходит в течение 30 секунд. Вначале сцены декорация дополнительно закрыта от зрителя иллюстрированным  полотнищем, которое прикреплено к  механическому штанкету №12 и  поднимается перед поворотом стола.  Система сценического подъема и  поворотный стол работают по MIDI и  имеют независимые консоли  управления у операторов.  Перед началом сцены со стола должна  выйти актриса. К сожалению, она  выходит так, что этого не видит ни  один из операторов (в реальной жизни  это маловероятно, но здесь  необходимо, чтобы показать  большинство функций 2PC). Поэтому  используется "электронный глаз",  установленный так, что актриса во  время своего ухода обязательно  перекрывает его луч. Перед тем как  начнет работать механика сцены,  электронный глаз должен определить,  что актриса вышла.  Естественно, ко всему этому  добавляются свет и звук. Есть две  звуковые и три световые сцены. Первая  звуковая сцена начинается, когдаактриса пересекает луч глаза, вторая — когда стол повернется наполовину, то  есть на 90 градусов. Первая световая  сцена начинается, когда полотнище  приоткрывает декорацию, вторая —  когда стол начинает поворачиваться,  финальная сцена — когда декорация  полностью развернется к залу.  Весь процесс управляется главным  контроллером — компьютерной  программой. Он разбит на несколько  этапов так, чтобы программа могла  отслеживать ключевые события.  Например, поворот стола разбит на два  этапа по 90 градусов вместо одного,  полного поворота на 180. В таблице на  рис. 15 показан список сцен с коротким описанием.  Все происходит в следующей  последовательности:1. Ожидать выполнения сцены EE­6.  2. Запустить сцену S­109.  3. Подождать 3 секунды (дать время  актрисе уйти).  4. Запустить сцены F­28 и L­118.  5. Подождать завершения сцены F­28.  6. Запустить сцены F­28.1, ТТ­34 и L­ 118.1  7. Ожидать завершения сцены ТТ­34.  8. Запустить сцены ТТ­34.1 и S­110  9. Ожидать завершения сцены ТТ­34.1  10. Запустить сцену L­119.  Названия сцен (типа "L­119")  приведены здесь для удобства, в MIDI­ сообщениях они не передаются.  Например, сообщение для сцены TT­ 34.1 будет содержать следующие  параметры: command_format=24,  Q_number=34.1, а L­119 —  command_format=01, Q_number=119.  Обмен сообщениями без ошибок Последовательность сообщений 2PC в  упрощенном виде при безошибочном  выполнении сцен данного примера  приведена в таблице на рис. 16.Примечания:  A. Контролер посылает сообщения  STANDBY для сцен, которые должны  начаться до того, как стол повернется  на 90 градусов. Эти сообщения  посылаются заблаговременно, с учетомвозможного двухсекундного тайм­ аута.  B. Получена серия ответных сообщений STANDING_BY. Сцена, к которой  относится STANDING_BY, задается  только номером секвенции. Видно  также, что сообщения STANDING_BY  получены не в том порядке, в каком  отправлены сообщения STANDBY. В  данном случае система сценического  подъема послала два сообщения  STANDING_BY одно за другим.  C. Электронный глаз ответил на  сообщение STANDBY сообщением  ABORT, так как актриса еще не  пересекла луч.  D. Электронный глаз ответил на  сообщение STANDBY сообщением  STANDING_BY — актриса, наконец,  пересекла луч. Поскольку больше нам  электронный глаз не нужен, мы не  будем посылать ему сообщение  GO_2PC. Однако это равносильно  отмене сцены, и в соответствии со  спецификацией 2PC мы должны были  бы послать для сцены EE­6 сообщениеCANCEL. Но для простых устройств­ детекторов вроде электронного глаза  это необязательно, так как для них  команда GO_2PC все равно никогда не  посылается.  E. Обратите внимание на столбец  секунд. Между приемом сообщения  STANDING_BY от электронного глаза  в момент времени 06.010 и отправкой  сообщения GO_2PC для света и  системы подъема прошла задержка  примерно в три секунды (время,  необходимое для ухода актрисы).  F. Сообщение GO_2PC для сцены 28.1  отправлено перед получением  сообщения COMPLETE для сцены 28.  Контроллер системы подъема понимает это так, что штанкет №12 должен  продолжать подъем и после завершения сцены 28.  G. По получении сообщения  COMPLETE для сцены 28 можно  приступать к выполнению сцен 34  поворотного стола и света 118.1. В это  время происходит также обмен  сообщениями STANDBY­STANDING_BY для оставшихся сцен.  H. Штанкет №12 поднят до  колосников.  I. Сообщение GO_2PC для сцены 34.1  поворотного стола отправлено перед  получением сообщения COMPLETE  для сцены 34. Так же, как и система  подъема, контроллер стола  интерпретирует это как сигнал не  прекращать движения после отправки  сообщения COMPLETE для сцены 34.  J. После завершения сцены 34  включается звуковая сцена 110.  K. После завершения сцены 34.1  включается световая сцена 119.  Ошибки, обнаруженные на ранней стадии Теперь предположим, что во время  выполнения нашей сцены произошли  кое­какие ошибки. Сначала рассмотрим ошибку, которая приводит к  прекращению всей сцены.  Предположим, контроллер системыподъема обнаружил неполадку одного  из лебедочных моторов, связанных с  двенадцатым штанкетом. Тогда система подъема вместо STANDING_BY  вернет сообщение ABORT. После чего  главный контроллер (компьютерная  программа) ответит сообщением  CANCEL для всех сцен, которым было  отправлено сообщение STANDBY.  Последовательность сообщений может  выглядеть так, как показано на рис. 17.  Примечания:  A. Первая сцена системы подъема  возвращает сообщение ABORT с кодом состояния "сбой в моторе". Этот код  преобразуется в текстовое сообщение,которое выводится оператору  системы.  B. Всем контролируемым устройствам  посылается сообщение CANCEL для  тех сцен, которые еще не завершились.  Это в соответствии с требованиями  2PC по восстановлению после сбоя (см. ранее). Так как отдельные приборы все  еще обрабатывают сообщения  STANDBY, сообщения  STANDING_BY и CANCEL  перемешиваются во времени друг с  другом.  C. К главному контролеру начинают  приходить сообщения CANCELLED.  Как и в случае с сообщениями  STANDING_BY, они приходят не в том порядке, в каком были отправлены  сообщения CANCEL. Статус­код  сообщений CANCELLED —  "terminated", так как ни одна из  отмененных сцен не начала  выполняться.  D. Главному контроллеру не остается  ничего другого, как отменить сцену F­ 28.1 (сообщение CANCEL в моментвремени 0.018 с). Так как контроллер  системы подъема уже забыл, что сцена  F­28.1 была в состоянии "наготове", он  отправляет главному контроллеру  сообщение CANCELLED со статус­ кодом "не в режиме ожидания".  Как видно из этого гипотетического  примера, протокол 2PC успешно  выявил неполадку с лебедочным  мотором. Начало поворота площадки  было автоматически остановлено.  Декорация на площадке не повернулась и не порвала полотнище, которое  осталось неподвижно висеть. Кроме  того, стейдж­менеджер за главным  контроллером был проинформирован о  неполадке сообщением на экране  компьютера.  Ошибки, произошедшие во время выполнения сцены Они обрабатываются почти так же, как  и вышеуказанная ошибка. Все  ожидающие или выполняющиеся сцены  завершаются сообщением CANCEL от  главного контроллера. Отличие здесь в  том, что число возможных вариантоввыключения безобразия на сцене  значительно увеличивается. И выбор  правильного решения не всегда  очевиден.  Спецификация рекомендует  разработчикам тщательно рассмотреть  все варианты — от продолжения  работы как ни в чем не бывало до  возврата в исходное состояние.  Предположим, что мотор поворотного  стола из нашего примера сломался  после поворота стола на 45 градусов.  Тогда, спустя где­то 18 секунд от  начала сцены (см. рис. 16), главному  контроллеру будет передано сообщение ABORT.  Поле чего все сцены получат  сообщения CANCEL. Две из них,  находящиеся в состоянии "наготове"  (S­110 и L­119), обработают отмену  "по­простому", забыв, что им было  послано сообщение "приготовиться".  Однако обработка сообщения CANCEL в сцене F­28, которая к этому моменту  еще не завершилась, более  проблематична. Так как полотнище  продолжает подъем, то вероятно,лучше всего поднять его до конца, дав  сцене F­28 полностью завершиться, с  возвращением статус­кода "completing" в сообщении CANCELLED и  последующим сообщением  COMPLETE. Но если бы по сценарию  полотнище должно было не  подниматься, а опускаться, показывая  зрителю нанесенную на него картину,  сцену F­28 следовало бы, наверное,  завершить немедленно.  Сравнительная характеристика 2PC и MSC Подытожим сказанное выше  сравнительной характеристикой обоих  наборов команд.  Обычные команды MSC посылаются в  любой момент времени и выполняются  немедленно. Команды 2PC  планируются, образуя нечто вроде  сценария, в котором  последовательность сцен должна  выполняться совершенно  определенным образом и никак иначе.  Обычные сообщения MSC хорошо  подходят для мероприятий типа LiveShow (например, для рок­концертов,  где нет жесткого планирования) и для  медиа­элементов, которые не  представляют угрозы безопасности,  таких как свет, звук и видео. Команды  2PC больше подходят для  запрограммированных шоу и для  медиа­элементов, которые влияют на  безопасность, например, машинерия и  пиротехника.  В наборе команд MSC есть несколько  сообщений, которые приводят к  различным электрическим или  механическим процессам в  контролируемом устройстве, например, команды GO, SET, FIRE, STOP и  RESUME. Набор команд 2PC содержит лишь одно сообщение, приводящее к  действию — GO_2PC. К какому  результату приведет данное сообщение, зависит от списка сцен, сохраненного в  контролируемом устройстве, и от того,  как этот сценарий будет  интерпретирован.  Главное преимущество MSC перед 2PC  — быстрый отклик на запрошенное  действие и простая конфигурация