Сообщения SysEx производителей можно разделить на две основные группы: большие блоки данных (Bulk Dump) и изменения настроек инструмента (Parameter Changes). Сообщения Bulk Dump применяются для сохранения (и последующего восстановления) настроек отдельного пэтча или целых банков, обновления операционной системы устройства и других задач, требующих большого объема передаваемой информации. Сообщения типа Parameter Changes используются для настройки параметров встроенных процессоров эффектов, фильтров, паттернов арпеджиатора и т. п. На некоторых инструментах Yamaha, например, посредством таких сообщений можно управлять даже выключением питания.
Сообщения SysEx, как и все остальные, можно записывать в секвенсор. Проще всего это делать в реальном времени с помощью органов управления инструмента. При воспроизведении данные SysEx будут переданы обратно в тон-генератор, и все нужные установки параметров окажутся загруженными автоматически.
Существует целый класс компьютерных программ, которые называются редакторами MIDI-устройств. Они позволяют выполнить настройку инструмента удобным и наглядным способом — с помощью нарисованных на экране кнопок, слайдеров и других органов управления, а затем передать всю эту информацию для записи в секвенсор. Для сохранения, архивирования и последующей загрузки настроек пэтчей и целых банков применяются программы-библиотекари, которые часто выполняют и функции редакторов устройств.
Производителям рекомендовано публиковать формат своих сообщений SysEx, чтобы пользователи могли получить наибольшую отдачу от инструмента. Обычно формат прилагается к руководству пользователя. Другим производителям разрешается свободно его использовать, но только производитель-автор формата может вносить в него какие-либо изменения.
Обычно сообщение состоит из заголовка, команды, числа передаваемых байт, собственно данных и байта завершения EOX (рис. 7). Заголовок состоит из статус-байта 0xF0, идентификатора производителя и номера устройства в системе (Device ID). Многие производители используют также номер модели (Model ID) — ведь зачастую сообщение SysEx имеет смысл только для какого-либо конкретного прибора. Так, например, для звукового модуля Roland JV 1080 этот номер равен 0x6A. Если сообщение с таким номером поступит в другое устройство фирмы Roland (например, в автономную систему записи VS 2480), то оно будет проигнорировано.
Рис. 7
Число передаваемых байт указывается, как правило, только в том случае, если сообщение имеет переменную длину. Данные могут делиться на пакеты; общий их размер может колебаться от одного байта до нескольких килобайт. Перед завершающим байтом иногда передается контрольная сумма, алгоритм вычисления которой у каждого производителя свой.
Ничего более конкретного сказать нельзя — сколько моделей, столько форматов. В качестве примера приведу команду копирования паттерна арпеджиатора из постоянной в перезаписываемую память в звуковом модуле Emu Proteus 2000 — рис. 8.
Рис. 8
Универсальные SysEx
Структура универсальных сообщений SysEx показана на рис. 9. После статус-байта 0xF0 следует тип сообщения (0x7E — Universal Non-Real Time, 0x7F — Universal Real Time), затем номер устройства в системе, затем — так называемый байт Sub ID. Он нужен для указания категории, к которой относится сообщение. Большинство категорий — это расширения протокола MIDI, например, Sub ID, равное 0x08 (в группе Universal Non-Real Time), является префиксом для команд протокола MIDI Tuning. Сами команды кодируются в следующем байте (он иногда называется Sub ID 2). Для протокола Sample Dump Standard (SDS) и общих сообщений "рукопожатий" (Generic Handshaking) сделано исключение — их команды кодируются непосредственно в первом Sub ID. После указания команды следуют сами данные, и, как обычно, сообщение завершается байтом EOX.
Рис. 9
Расширения MIDI будут подробно рассмотрены в следующих статьях, а сейчас остановимся на универсальных категориях, к которым относятся Generic Handshaking, General Information и Device Control. Есть еще категория General MIDI, которая состоит из команд включения и выключения режима GM, но о ней поговорим в статье про совместимость.
Сообщения категории Generic Handshaking используются при пересылке данных между устройствами, и отражают состояние передачи. Например, при ошибке приемник говорит передатчику "последний пакет прошел неудачно, давай-ка его еще раз". Естественно, при этом требуется двухстороннее соединение устройств. Сообщения Generic Handshaking могут включаться в SysEx, специфичные для производителей, либо использоваться в форме универсальных SysEx. Структура последних показана на рис. 10. В таком виде "рукопожатия" используются в протоколе Sample Dump Standard и MIDI File Dump (последний позволяет передавать файлы любого формата по MIDI-кабелю).
Рис. 10
Сообщение Ack (Acknowledged, Sub ID равен 0x7F) посылается после успешного приема каждого пакета и говорит передатчику — "последний пакет принят, можно передавать следующий". Номер полученного пакета указывается перед байтом EOX. Сообщение NAK (Not Acknowledged, 0x7E) означает ошибку приема и требует повторной пересылки пакета. Если приемник хочет, чтобы передатчик прекратил посылать пакеты, он отправляет ему сообщение Cancel (0x7D). Сообщение Wait (0x7C) говорит передатчику "сделай паузу". Приемник посылает это сообщение, если ему нужно выполнить длительную операцию, например, сохранить полученную порцию данных на дискету. Как только операция будет завершена, приемник посылает одно из трех предыдущих сообщений: для пересылки следующего пакета, для повтора последнего, либо для отмены передачи. После отправки последнего пакета передатчик посылает приемнику сообщение EOF (End Of File, 0x7B).
Категория General Information (иногда называемая Inquiry Messages) позволяет одному устройству (или программе) получить информацию о другом. Здесь прослеживается аналогия с принципом Plug’n’Play — интересующаяся сторона спрашивает: "Кто это к нам подключен?", устройство отвечает: "Я — такая-то модель такого-то производителя и т. п.". Команда опроса называется Identity Request (Sub ID 2 равен 0x01), команда ответа — Identity Reply (0x02). Пример команды опроса, которая посылается всем устройствам системы, показан на рис. 11.
Рис. 11
Структура ответа показана на рис. 12. По байту Device ID можно определить, с какого устройства системы пришел ответ. В ответе содержится идентификатор производителя, номер модельного ряда (family code), номер модели, а также версия операционной системы.
Рис. 12
В основном команды опроса посылают программные редакторы/библиотекари, чтобы определить, с каким устройством им предстоит работать.
Категория Device Control состоит из двух сообщений: Master Volume (Sub ID 2 равен 0x01) и Master Pan (0x02), оба появились в 1992 году. Предназначены они для управления громкостью и панорамой на мастер-выходе устройства, в отличие от сообщений MIDI Volume и Pan, которые применяются для настройки отдельного канала. Оба сообщения — высокой точности (содержат пару MSB:LSB). Пример использования Master Volume показан на рис. 13.
Рис. 13
Running Status
Пропускная способность MIDI по современным меркам очень мала — 31,25 Кбит/с. И хотя она дает возможность передать более 1000 сообщений канала в секунду, для насыщенной аранжировки этого бывает недостаточно. Такие сообщения, как Pitch Wheel Change, послекасание, непрерывные контроллеры посылают информацию со скоростью от 50 до 100 сообщений в секунду. Если умножить это число на несколько одновременно звучащих каналов, да еще учесть возможное внедрение синхросигнала, то станет ясно, что превысить пропускную способность MIDI не составляет труда. Результатом перегрузки являются переполнение входных буферов, зависшие или "срезанные" ноты и прочие неприятности. Детали физического прохождения MIDI-потока по кабелю мы рассмотрим в следующих статьях, а сейчас поговорим о методе сжатия потока, который называется Running Status.
Суть его проста — если передается серия сообщений с одним и тем же статус-байтом, то достаточно передать только первый статус-байт, а остальные опустить. Проще всего показать это на примере. Если, скажем, передается сообщение о взятии ноты (предположим, на первом канале), то сначала к приемнику поступит статус-байт 0x90, а затем два байта данных: номер ноты и, соответственно, динамика. Затем приемник будет ожидать следующего сообщения, которое должно начаться со статус-байта. Если вместо него придет байт данных, то приемник поймет, что передача ведется в режиме Running Status и будет считать, что статус-байт все тот же, 0x90. Таким образом, неожиданно появившийся байт данных будет воспринят как номер ноты, а следующий за ним — как динамика. Пары байт "номер ноты/динамика" могут идти подряд до тех пор, пока тип сообщения не изменится. Для остальных сообщений принцип тот же.
Какова эффективность Running Status? Если взять аккорд из пяти нот, то будут сгенерированы пять последовательных сообщений Note On, а по отпускании клавиш — столько же сообщений Note Off. В обычном режиме будет передано 30 байт, а при использовании Running Status — 22, то есть сжатие составит около 30% (рис. 14).
Рис. 14
Однако чаще при исполнении одни клавиши нажимаются, другие в это время удерживаются, и отпускаются потом в разное время, то есть сообщения Note On и Note Off перемешиваются друг с другом. В этом случае Running Status неэффективен, так как длинные серии одинаковых сообщений отсутствуют. Но разработчики нашли выход и ввели правило: вместо сообщения о снятии ноты можно передавать сообщение Note On с нулевой динамикой, которое должно отрабатываться устройством аналогично.
Предположим, мы взяли поочередно ноты До, Ми, Соль и Си первой октавы. В этом случае сообщения Note On и Note Off чередуются. Если инструмент будет передавать сообщение Note Off обычным способом, то пользы от Running Status не будет никакой — на выход пойдут 24 байта (рис. 15, а). Если же вместо Note Off передавать Note On с нулевой динамикой, то достаточно передать статус-байт Note On один раз в начале серии, в результате получим 17 байт (рис.15, б), то есть также около 30% сжатия.
Рис. 15a
Рис. 15b
Режим Running Status применяется только при передаче голосовых сообщений и сообщений режима канала. Он очень хорошо справляется с потоком сообщений непрерывных контроллеров, таких как колесо модуляции и послекасание, но практически неэффективен для чередующихся сообщений разного типа. Если сообщения одного типа чередуются по разным каналам, их статус-байты отличаются, а, следовательно, эффективность сжатия потока также уменьшается.
Общесистемные и эксклюзивные сообщения в режиме Running Status не передаются, поэтому при их появлении в потоке текущий Running Status сбрасывается. Сообщения категории Real Time, напротив, обрабатываются "прозрачно" и на Running Status не влияют.
Режим Running Status обычно не требует каких-либо телодвижений от пользователя — он используется по умолчанию во всех современных MIDI-устройствах. Однако некоторые старые инструменты (например, Ensoniq Mirage, Korg DDD 1 и DDD 5, Sequential Circuits Prophet T 8, ранние Yamaha DX 7) его не поддерживают. Поэтому хороший секвенсор должен позволять включать и отключать Running Status, чтобы можно было работать и со старым оборудованием.
Возможен и побочный эффект: если подключить приемное устройство к источнику, уже начавшему передачу в режиме Running Status, то приемник может вообще не получить ни одного статус-байта. А, следовательно, вся серия байт данных будет проигнорирована.
