Большая часть «системных» сообщений предназначена для синхронизации и управления воспроизведением. Из них наиболее активно используются сообщения SysEx (системные эксклюзивные), скрывающиеся за статус-байтом 0xF0. Они имеют сложную структуру и произвольную длину.
К категории System Common относятся пять разнородных сообщений. Например, сообщение Tune Request (статус-байт 0xF6), это команда синтезатору произвести подстройку звуковых генераторов, и она имеет смысл только для старых аналоговых инструментов, у которых через некоторое время после включения начинает «плыть» строй. Очевидно, что на это сообщение реагируют только те инструменты, у которых есть схема автоподстройки.
Сообщения категории Real Time имеют в MIDI наивысший приоритет, они могут вклиниваться между частями других сообщений и состоят только из статус-байта, без байтов данных. Они используются для синхронизации и других задач, в которых критично время выполнения.
Все три типа системных сообщений относятся не к определенному каналу, а ко всем устройствам MIDI-системы (хотя сообщения SysEx, при необходимости, можно передавать избирательно).
MIDI Clock
MIDI Clock предназначен для синхронизации устройств, внутренняя временная сетка которых выражена в относительных единицах, зависящих от темпа. Это могут быть, например: секвенсор и ритм-машина, или два секвенсора, или две ритм-машины. При синхронизации одно из устройств становится ведущим (master) — у него включается функция передачи сообщений MIDI Clock, а другое — подчиненным (slave), т.е. переводится в режим внешней синхронизации, который может иметь название "Sync: External Clock", "Sync: MIDI", "Clock: External" и т.п. Ведомых устройств может быть несколько.
При этом не требуются специальные разъемы и кабели — сообщения MIDI Clock передаются по обычному MIDI-кабелю:
Для синхронизации по MIDI Clock применяются пять сообщений: текущая позиция (Song Position Pointer), информация о скорости (Timing Clock) и три управляющие команды (Start, Stop, Continue). Сообщение Song Position Pointer относится к категории System Common, информация о скорости и управляющие команды — к категории Real Time.
Основное сообщение здесь — Timing Clock. Оно состоит только из статус-байта (0xF8) и посылается ведущим устройством 24 раза за четверть. Если, например, текущий темп равен 120 bpm (ударам в минуту), то генерируются 48 сообщений Timing Clock в секунду (120 / 60 * 24), если 180 bpm — 72 сообщения. Поскольку Timing Clock никакой числовой информации не несет, то для определения темпа приемное устройство должно получить как минимум два сообщения Timing Clock и измерить интервал между ними.
Известно, что разрешение секвенсоров гораздо больше, чем 24 импульса в четверти (у современных программных секвенсоров оно доходит до 15360 PPQN — Pulse Per Quarter Note). Поэтому, при передаче сообщений Timing Clock ведомому устройству секвенсор вынужден отбрасывать часть своих внутренних импульсов. Приемное устройство также может иметь более высокое разрешение, и должно будет добавлять внутренние импульсы между приходящими сообщениями Timing Clock. Возможна ситуация, когда в промежутке между сообщениями Timing Clock в ведущем устройстве произойдет плавное изменение темпа. Точно его передать на ведомое устройство не получится — в нем произойдет скачок темпа (см. рис.). Обычно это не является проблемой, но такое ограничение нужно иметь в виду:
Сообщения Timing Clock, как и все сообщения группы Real Time, могут вклиниваться между частями других сообщений, если подошло время отправки. См. пример, здесь первый Timing Clock внедрился между статус-байтом сообщения Note On и байтом данных, а следующий — между байтами данных сообщения Pitch Wheel Change. Устройство должно обрабатывать эту ситуацию без проблем. В данном случае после получения статус-байта Note On принимающее устройство ждет два байта данных, первый — с номером ноты, второй — со скоростью нажатия. Но вместо этого он натыкается на статус-байт Timing Clock. Этот байт извлекается из потока, обрабатывается, а затем устройство продолжает ожидать два байта данных сообщения Note On:
Спецификация предлагает еще один способ передачи информации о скорости — так называемые «тики» (Timing Tick). Один тик — это статус-байт 0xF9, который передается от ведущего устройства к ведомому устройству каждые 10 мс (то есть 100 раз в секунду). Скорость этого потока не зависит от темпа, но и не содержит абсолютного времени. Ведомое устройство самостоятельно определяет, сколько тиков приходится на четверть, по своим внутренним часам.
Управляющие команды
При нажатии кнопки Play на ведущем устройстве, ведомому устройству посылается команда Start (статус-байт 0xFA), которая переводит его в режим готовности к воспроизведению. Кроме того, эта команда указывает, что воспроизведение должно начаться с самого начала композиции. Затем, как только поступит первый Timing Clock, ведомое устройство должно начать воспроизведение. Спецификация не определяет паузу между поступлением сообщений Start и следующего за ним Timing Clock. Теоретически, Timing Clock может прийти немедленно, но на практике большинство мастер-устройств выдерживают паузу в 1 мс для того, чтобы принимающее устройство могло подготовиться к воспроизведению.
Требование ожидать первый Timing Clock действует только в том случае, если устройство находится в режиме внешней синхронизации, то есть является ведомым. Если устройство работает от внутренних часов, то оно может стартовать при получении сообщения Start немедленно.
Команда Stop (статус-байт 0xFC) останавливает воспроизведение. Спецификация требует, чтобы сигналы MIDI Clock продолжали поступать и после остановки, что дает возможность ведомому устройству постоянно отслеживать текущий темп (например, для отображения его на передней панели).
Для того, чтобы начать воспроизведение с произвольного места, используется сообщение Song Position Pointer (SPP, статус-байт 0xF2), в котором посылается число MIDI-битов (MIDI Beat), прошедших от начала композиции. Один MIDI-бит равен шести сигналам Timing Clock, т.е. шестнадцатой ноте. Таким, образом, SPP имеет точность позиционирования до шестнадцатой. Если, например, SPP равен 48, то воспроизведение начнется с 48-й по счету шестнадцатой, то есть с первой четверти третьего такта (при размере 4/4). Сообщение SPP имеет высокое разрешение, содержит два байта данных (пара MSB:LSB), следовательно, позволяет указать позицию от 0 до 16383 MIDI-битов, что при размере 4/4 соответствует 1024 тактам от начала композиции.
Сообщение SPP не должно передаваться во время воспроизведения. В противном случае ведомое устройство может не успеть вовремя переместиться к новой точке и потеряет при этом несколько сообщений Timing Clock. Обычно SPP передается при перемотке вперед или назад в секвенсоре при остановленном воспроизведении.
Для того, чтобы воспроизведение началось с точки, заданной сообщением SPP, либо от последней точки остановки, используется команда Continue (статус-байт 0xFB). При ее получении устройство приводится в режим готовности, а следующее сообщение Timing Clock служит сигналом начать воспроизведение. Команда Start для этой цели не подходит, поскольку она начинает воспроизведение с начала композиции.
Существует также возможность выбора композиции (или паттерна) посредством MIDI. Для этого используется сообщение Song Select (категория System Common, статус-байт 0xF3). Оно содержит один байт данных — номер композиции (от 0 до 127). Вы можете, например, запрограммировать в секвенсоре и в ритм-машине несколько композиций. Если секвенсор является мастером, то при выборе одной из них секвенсор посылает ритм-машине сообщение Song Select — и она готова к воспроизведению композиции с тем же номером. При получении Song Select ведомое устройство устанавливает позицию воспроизведения в начало композиции. Для выбора другой позиции устройство-мастер должно передать SPP.
System Exclusive messages
Стандартом MIDI определены основные и наиболее характерные параметры большинства устройств. Управление дополнительными возможностями определенного устройства возможно с помощью т.н. «незарегистрированных параметров» (NRPN). Но наиболее гибким способом использовать все заложенные в устройство возможности, являются т.н. «системные эксклюзивные сообщения» (SysEx). Каждый производитель может определять собственные сообщения SysEx, даже для определенной модели.
Кроме того, обнаружилось, что некоторое количество команд, не предусмотренных стандартом, используются в разных устройствах одинаковым образом, поэтому их также можно стандартизировать. Например, общая громкость звучания (Master Volume) и панорама (Master Pan).
Также, возникла потребность расширения первоначальной спецификации дополнительными протоколами (первое такое расширение, MIDI Time Code, появилось в 1987 году). Но практически все статус-байты на тот момент были заняты, поэтому единственным способом расширения оказались сообщения SysEx.
Таким образом, помимо сообщений SysEx определенных производителей (Manufacturer Specific SysEx), существуют и универсальные (Universal SysEx). К ним относятся все расширения протокола, а также общие команды для управления устройствами, не отраженные в голосовых сообщениях.
Для того, чтобы сопоставить SysEx с определенным производителем, в заголовке сообщения передается его идентификатор (Manufacturer ID). Получив чужой идентификатор, устройство просто сообщение. Выдачей идентификаторов занимаются организации MMA и JMSC.
Общая структура сообщения SysEx такова: сначала идет статус-байт 0xF0, затем идентификатор производителя, затем какое-то количество байт данных, и признак завершения — байт EOX (End Of Exclusive, 0xF7):
Каждый производитель применяет собственный формат и волен использовать в сообщении любое число байт данных.
Сообщение SysEx содержит только байты данных (не считая начального 0xF0), поэтому появление какого-либо статус-байта (отличного от категории Real Time) будет также означать конец SysEx. Т.е., строго говоря, завершающий байт EOX не обязателен. Например, Yamaha DX 7 не передает EOX, поэтому с теми устройствами, которые ожидают его в обязательном порядке, могут возникнуть проблемы.
Идентификаторы производителей находятся в диапазоне от 0x01 до 0x7C (от 1 до 124), по 31 идентификатору на регион мира:
- с 0x01 по 0x1F — для американских производителей,
- с 0x20 по 0x3F — для европейских,
- с 0x40 по 0x5F — для японских,
- с 0x60 по 0x7C — для производителей из остальных регионов.
Оставшиеся три значения (0x7D, 0x7E и 0x7F) зарезервированы:
- 0x7D является некоммерческим идентификатором (Non-Commercial ID), применяется при разработке и тестировании оборудования и не должен использоваться в устройствах, поставляемых на рынок.
- 0x7E и 0x7F идентифицируют две группы универсальных сообщений SysEx: Universal Non-Real Time (сообщения, не критичные к времени передачи) и сообщения Universal Real Time (соответственно, критичные, т.е. требующие приоритета при передаче).
31 производитель на регион — это очень мало, и практически сразу все идентификаторы были заняты. Поэтому, нулевой идентификатор (0x00) был зарезервирован в качестве префикса, за которым передаются два байта, пара MSB:LSB, содержащие расширенный номер производителя, от 1 до 16383 (первым передается LSB):
Таблица ID производителей. (ссылка)
Выделенные однажды идентификаторы остаются за производителем навсегда, даже если он прекращает торговую деятельность или ликвидируется, поскольку выпущенные приборы могут быть использоваться неограниченное время.
Эксклюзивные сообщения (как и все системные) посылаются без указания номера канала, и их получает каждое устройство MIDI-системы. При передаче специфических SysEx это не проблема, но для передачи универсального SysEx определенному устройству системы нужны дополнительные меры.
Для идентификации устройства в системе используется т.н. «номер устройства» (Device ID) — байт данных, следующий за идентификатором производителя. Каждому устройству можно назначить свой номер от 0 до 127 (обычно, покопавшись в настройках). Если в сообщении SysEx будет передан Device ID, не совпадающий с выбранным номером, устройство проигнорирует сообщение. Это похоже на прием по определенному MIDI-каналу, только «каналов» здесь 128. Для отправки широковещательных SysEx-сообщений (то есть предназначенных всем устройствам системы) используется Device ID с номером 127 (0x7F).
Есть три способа передачи сообщений SysEx:
Первый — прямая передача, которая инициируется вручную на передающем устройстве. При этом достаточно односторонней связи, то есть соединения MIDI-выхода передающего устройства с MIDI-входом принимающего. Для контроля успешного приема в конец сообщения может добавляться контрольная сумма.
Второй способ состоит в том, что принимающее устройство сначала посылает запрос передающему, а затем ожидает от него данные. При этом требуется взаимная коммутация устройств двумя MIDI-кабелями.
Третий способ также основан на запросе к передающему устройству и также требует двусторонней связи. При этом данные разбиваются на небольшие пакеты, которые могут передаваться без подтверждения приема или с подтверждением. В последнем случае используется так называемый механизм «рукопожатий» (Handshaking). После получения каждого пакета приемник сообщает передатчику результат — успешно получен пакет или нет. В случае ошибки приема, передатчик посылает пакет заново.
SysEx производителей
Сообщения SysEx производителей можно разделить на две основные группы: большие блоки данных (Bulk Dump) и изменения настроек инструмента (Parameter Changes).
Сообщения Bulk Dump применяются для сохранения (и последующего восстановления) настроек отдельного патча или банка патчей, обновления операционной системы устройства и других задач, требующих большого объема передаваемой информации.
Сообщения типа Parameter Changes используются для настройки параметров встроенных процессоров эффектов, фильтров, паттернов арпеджиатора и т. п. На некоторых инструментах Yamaha, например, посредством таких сообщений можно управлять даже выключением питания.
Сообщения SysEx, как и все остальные, можно записывать в секвенсор. Проще всего это делать в реальном времени с помощью органов управления инструмента. При воспроизведении данные SysEx будут переданы обратно в тон-генератор, и все нужные установки параметров окажутся загруженными автоматически.
Существует целый класс компьютерных программ, которые называются редакторами MIDI-устройств. Они позволяют выполнить настройку инструмента удобным и наглядным способом — с помощью нарисованных на экране кнопок, слайдеров и других органов управления, а затем передать всю эту информацию для записи в секвенсор. Для сохранения, архивирования и последующей загрузки настроек пэтчей и целых банков применяются программы-библиотекари, которые часто выполняют и функции редакторов устройств.
Производителям рекомендовано публиковать формат своих сообщений SysEx, чтобы пользователи могли получить наибольшую отдачу от инструмента. Обычно формат прилагается к руководству пользователя. Другим производителям разрешается свободно его использовать, но только производитель, который является автором формата SysEx-сообщения, может вносить в него какие-либо изменения.
Обычно сообщение состоит из заголовка, команды, числа передаваемых байт, собственно данных и байта завершения EOX:
Заголовок состоит из статус-байта 0xF0, идентификатора производителя и номера устройства в системе (Device ID). Многие производители используют также номер модели (Model ID) — ведь зачастую сообщение SysEx имеет смысл только для какого-либо конкретного прибора. Так, например, для звукового модуля Roland JV 1080 этот номер равен 0x6A. Если сообщение с таким номером поступит в другое устройство фирмы Roland (например, в автономную систему записи VS 2480), то оно будет проигнорировано.
Число передаваемых байт указывается, как правило, только в том случае, если сообщение имеет переменную длину. Данные могут делиться на пакеты; общий их размер может колебаться от одного байта до нескольких килобайт. Перед завершающим байтом иногда передается контрольная сумма, алгоритм вычисления которой у каждого производителя свой.
Ничего более конкретного сказать нельзя — сколько моделей, столько форматов. В качестве примера, команда копирования паттерна арпеджиатора из постоянной в перезаписываемую память в звуковом модуле E-mu Proteus 2000:
Универсальные SysEx
На рисунке показана структура универсальных сообщений SysEx. После статус-байта 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:
Сообщения категории Generic Handshaking используются при пересылке данных между устройствами, и отражают состояние передачи. Например, при ошибке принимающее устройство сообщает передающему: "последний пакет прошел неудачно, передай его еще раз". При этом требуется двухстороннее соединение устройств. Сообщения Generic Handshaking могут включаться в SysEx, специфичные для производителей, или использоваться в форме универсальных SysEx. Структура Сообщения Generic Handshaking:
В таком виде "рукопожатия" используются в протоколе Sample Dump Standard и MIDI File Dump (последний позволяет передавать файлы любого формата по MIDI-кабелю).
Сообщение Ack (Acknowledged, Sub ID равен 0x7F) посылается после успешного приема каждого пакета и означает — "последний пакет принят, можно передавать следующий". Номер полученного пакета указывается перед байтом EOX. Сообщение NAK (Not Acknowledged, 0x7E) означает ошибку приема и требует повторной пересылки пакета. Если приемник хочет, чтобы передатчик прекратил посылать пакеты, он отправляет ему сообщение Cancel (0x7D). Сообщение Wait (0x7C) говорит передатчику "сделай паузу". Приемник посылает это сообщение, если ему нужно выполнить длительную операцию, например, сохранить полученную порцию данных на дискету. Как только операция будет завершена, приемник посылает одно из трех предыдущих сообщений: для пересылки следующего пакета, для повтора последнего, либо для отмены передачи. После отправки последнего пакета передатчик посылает приемнику сообщение EOF (End Of File, 0x7B).
Категория General Information (иногда называемая Inquiry Messages) позволяет одному устройству (или программе) получить информацию о другом. Одна из сторон запрашивает информацию о подключенном устройстве, которое в ответ отправляет свои данные: "Такая-то модель такого-то производителя и т. п.". Команда запроса называется Identity Request (Sub ID 2 равен 0x01), команда ответа — Identity Reply (0x02). Пример команды запроса, которая посылается всем устройствам системы:
Структура ответа. По байту Device ID можно определить, с какого устройства системы пришел ответ. В ответе содержится идентификатор производителя, номер модельного ряда (family code), номер модели, а также версия операционной системы:
В основном команды опроса посылают программные редакторы/библиотекари, чтобы определить, с каким устройством им предстоит работать.
Категория Device Control состоит из двух сообщений: Master Volume (Sub ID 2 равен 0x01) и Master Pan (0x02), оба появились в 1992 году. Предназначены они для управления громкостью и панорамой на мастер-выходе устройства, в отличие от сообщений MIDI Volume и Pan, которые применяются для настройки отдельного канала. Оба сообщения — высокой точности (содержат пару MSB:LSB). Пример использования Master Volume:
