Синхронизация MIDI-устройств

MIDI в деталях. Часть 3 — Системные сообщения.

Третья часть цикла статей, подробно рассказывающих о протоколе MIDI.

Системные сообщения немногочисленны, но берут на себя едва ли не основную нагрузку, когда речь идет о тонком управлении устройством, сохранении и восстановлении настроек, передачи специализированной информации или объединении нескольких устройств в MIDI-систему для совместной работы.

Название сообщений, их статус-байты и формат передачи показаны в таблице на рис. 1. Как видно, большая часть сообщений предназначена для синхронизации и управления воспроизведением. Но, как показывает практика, наиболее активно используются системные эксклюзивные сообщения (SysEx), которые скрываются за одним-единственным статус-байтом 0xF0. Они имеют сложную структуру и произвольную длину.

К общесистемной категории (System Common) относятся пять разнородных сообщений. Первое из них, MTC Quarter Frame, появилось в спецификации в 1987 году вместе с первым расширением протокола (MIDI Time Code). Последующие расширения MIDI стали кодироваться в группе SysEx. О другом общесистемном сообщении, Tune Request(статус-байт 0xF6), расскажу сразу же. Оно дает команду синтезатору произвести подстройку звуковых генераторов и, очевидно, имеет смысл только для старых аналоговых инструментов, у которых через некоторое время после включения начинает "съезжать" строй. Естественно, на это сообщение реагируют только те инструменты, у которых есть схема автоподстройки.

Сообщения категории Real Time имеют в MIDI наивысший приоритет, могут вклиниваться между частями других сообщений и состоят из одного статус-байта, без байтов данных. Они применяются для синхронизации и других задач, критичных ко времени.

Все три типа системных сообщений имеют общую черту — они относятся не к отдельному каналу, а ко всем устройствам MIDI-системы (впрочем, сообщения SysEx можно передавать избирательно, но об этом позже).

Синхронизация MIDI-устройств

До тех пор, пока MIDI-система состоит из синтезаторов, звуковых модулей и одного центра управления — секвенсора (программного или аппаратного), вопрос о синхронизации не стоит. И действительно, что тут и с чем синхронизировать? Секвенсор сам себе хозяин, работает от внутренних часов и при нажатии кнопки Play передает устройствам команды управления.

Другое дело, когда в системе появляется источник звука, содержащий встроенный секвенсор (на языке MIDI-спецификации — Rhythm Unit). Чаще всего это ритм-машинка, иногда — рабочая станция, то есть синтезатор с секвенсором в одном корпусе. Эти устройства можно использовать просто как источники звука, записывая всю управляющую информацию в основной секвенсор. Но иногда их собственный секвенсор и записывающие/ воспроизводящие возможности приходятся очень кстати.

Например, можно "набросать" паттерн в ритм-машинке, запустить его на воспроизведение, а на клавиатуре подбирать партию баса, записывая ее в основной секвенсор. Тонкостей этого процесса мы коснемся позже, в статье про организацию MIDI-систем, но уже ясно: в системе одновременно работают два секвенсора, то есть два устройства, имеющие внутренние часы. Нужно сделать так, чтобы устройства стартовали одновременно и работали в одном темпе, то есть синхронизировать их. Очевидно, одни из часов придется выключить, а вторые сделать общими. Иначе говоря, одно из устройств будет мастером (ведущим), генерирующим сигналы "точного времени", а другое — подчиненным (ведомым), слушающим эти сигналы и работающим с мастером "в такт".

Задолго до появления MIDI применялся сигнал, который представлял собой последовательность обычных импульсов. Они передавались определенное число раз за четвертную ноту, например, 48 или 96. Так как музыкальные длительности относительны, то эти импульсы давали не абсолютное (в минутах и секундах), а относительное время. При повышении темпа частота следования импульсов повышалась, при понижении — понижалась. Этого достаточно, чтобы секвенсоры и ритм-машинки играли в одном темпе, абсолютное время им и не важно. Все бы хорошо, но в разных устройствах применялись разные частоты следования импульсов, поэтому иногда требовались дополнительные преобразователи.

Проблема иного рода состоит в синхронизации секвенсоров и ритм-машинок с магнитофонами. Последние представляют собой устройства другой природы, где скорость движения ленты от темпа произведения не зависит. Непосредственно записать импульсы синхронизации на ленту нельзя, поэтому применяется один из двух методов: FSK-преобразование или таймкод SMPTE. Использование FSK будет рассмотрено в статье про построение MIDI-систем. Что же касается SMPTE, то на его базе был разработан протокол MIDI Time Code (MTC), который сегодня является основным при синхронизации секвенсоров с магнитофонами и другим звуковым оборудованием. Но MIDI Time Code — это уже расширение спецификации, поэтому о нем поговорим чуть позже. А сначала остановимся на "родном" методе синхронизации MIDI-устройств, который называется MIDI Clock и является неотъемлемой частью протокола.

MIDI Clock

MIDI Clock предназначен для синхронизации тех устройств, внутренняя временная сетка которых выражена в относительных единицах, зависящих от темпа. Типичные варианты: секвенсор и ритм-машинка, два секвенсора, две ритм-машинки. Для синхронизации одно из устройств делается мастером (у него включается функция передачи сообщений MIDI Clock), а другое — подчиненным (переводится в режим внешней синхронизации, который может иметь название "Sync: External Clock", "Sync: MIDI", "Clock: External" и т. п.). В принципе, ведомых устройств может быть несколько.

При этом не требуются специальные разъемы и кабели — сообщения MIDI Clock передаются по обычному MIDI-кабелю и разъему. Причем их вполне можно передавать и одновременно с аранжировкой. Здесь прослеживается аналогия с цифровой звуковой коммутацией, когда синхросигнал внедряется в звуковые данные (self-clock). С инженерной точки зрения это нехорошо, поскольку пропускная способность MIDI и без того ограничена. Но для пользователя удобно — не нужно лишней коммутации и обязательного наличия свободного MIDI-входа (рис. 2).

Для синхронизации по MIDI Clock применяются пять сообщений: позиционное (Song Position Pointer), информация о скорости (Timing Clock) и три команды (Start, Stop, Continue). Позиционное сообщение относится к категории System Common, информация о скорости и команды — к категории Real Time.

Основное сообщение здесь — Timing Clock. Оно состоит только из статус-байта (0xF8) и посылается мастер-устройством 24 раза за четверть. Если, например, текущий темп равен 120 bpm (ударам в минуту), то генерируются 48 сообщений Timing Clock в секунду (120 / 60 * 24), если 180 bpm — 72 сообщения. Поскольку Timing Clock никакой числовой информации не несет, то для определения темпа приемное устройство должно получить как минимум два "клока" и измерить временной интервал между ними.

Известно, что разрешение секвенсоров гораздо больше, чем 24 импульса в четверти (у современных программных секвенсоров оно доходит до 15360 PPQN — Pulse Per Quarter Note). При передаче клока ведомому устройству секвенсор вынужден отбрасывать часть своих внутренних импульсов высокого разрешения. Приемное устройство также может иметь более высокое разрешение, и должно будет добавлять внутренние импульсы между приходящими клоками. Возможна ситуация, когда в мастер-устройстве произойдет плавное изменение темпа в промежутке между MIDI-клоками. Точно его передать на ведомое устройство не получится — в ведомом произойдет скачок темпа (рис. 3). Обычно это не представляет особой проблемы, но лучше такое ограничение иметь в виду.

Сообщения Timing Clock, как и все сообщения группы Real Time, могут вклиниваться между частями других сообщений, если подошло время отправки. Типичный пример представлен на рис. 4. Здесь первый клок внедрился между статус-байтом сообщения Note On и байтом данных, а следующий — между байтами данных сообщения Pitch Wheel Change. Устройство должно обрабатывать эту ситуацию без проблем. В данном случае после получения статус-байта "нажата клавиша" тон-генератор ждет два байта данных, первый — с номером ноты, второй — со скоростью нажатия (см. предыдущую статью). Но вместо этого он натыкается на статус-байт клока. Этот байт извлекается из потока, обрабатывается, а затем устройство продолжает ожидать два байта данных сообщения Note On, как ни в чем не бывало.

Спецификация предлагает еще один способ передачи информации о скорости — так называемые "тики" (Timing Tick). Один тик — это статус-байт 0xF9, который передается от мастера к ведомому устройству каждые 10 мс (то есть 100 раз в секунду). Скорость этого потока не зависит от темпа, но, с другой стороны, и не содержит абсолютного времени, как, например, в MTC. Ведомое устройство должно самостоятельно определить, сколько тиков приходится на четверть, базируясь на своих внутренних часах.

Теперь поговорим об управлении. При нажатии кнопки Play на мастере ведомому устройству посылается команда Start(статус-байт 0xFA), которая переводит его в режим готовности к воспроизведению. Одновременно эта команда выполняет простейшую позиционную функцию — она указывает, что воспроизведение должно начаться с самого начала песни. Затем, как только поступит первый клок, ведомое устройство должно начать воспроизведение. Спецификация не определяет паузу между поступлением сообщений Start и следующего за ним Timing Clock. Теоретически, клок может прийти немедленно. Но на практике большинство мастер-устройств выдерживают паузу в 1 мс для того, чтобы приемник мог подготовиться к воспроизведению.

Замечу, что требование ожидать первый клок действует только в том случае, если устройство находится в режиме внешней синхронизации, то есть является ведомым. Если устройство работает от внутренних часов, то оно может стартовать при получении сообщения Start немедленно, что удобно для простого дистанционного управления.

Команда Stop (статус-байт 0xFC) останавливает воспроизведение. Спецификация требует, чтобы сигналы MIDI Clock продолжали поступать и после остановки, что дает возможность ведомому устройству постоянно отслеживать текущий темп (например, для отображения его на передней панели).

Сообщения Timing Clock несут информацию только о скорости и ничего не говорят о положении. Команда Start немногим улучшает дело — она говорит лишь о том, что воспроизведение нужно всегда начинать с первой доли первого такта. А если нужно начать воспроизведение с произвольного места? Для этого применяется сообщениеSong Position Pointer (SPP, статус-байт 0xF2), в котором посылается число MIDI-битов (MIDI Beat), прошедших от начала песни. Один MIDI-бит равен шести клокам, а, следовательно, шестнадцатой ноте (24 / 4). То есть 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

Существует множество самых разных музыкальных устройств, отличающихся назначением и внутренней архитектурой. Учесть особенность каждого инструмента и внести их в стандарт — задача нереальная, но MIDI к этому и не стремится. Стандартизированы (в виде сообщений канала) только наиболее характерные черты большинства устройств. Необходимая гибкость в управлении достигается с помощью контроллеров General Purpose или незарегистрированных параметров (NRPN, см. предыдущую статью). А наиболее удобным вариантом, позволяющим использовать все заложенные в устройство возможности, являются системные эксклюзивные сообщения (SysEx). Каждый производитель может определять свои собственные сообщения SysEx, даже под конкретное устройство.

Изначально сообщения SysEx предназначались исключительно для производителей, но скоро обнаружилось, что есть целая группа команд, которые используются одинаковым образом и которые неплохо бы внести в стандарт. Типичным примером является общая громкость звучания (Master Volume) и панорама (Master Pan). Кроме того, возникла потребность расширения начальной спецификации дополнительными протоколами (первое такое расширение, MIDI Time Code, появилось в 1987 году). Но практически все статус-байты на тот момент были заняты, поэтому единственным способом расширения оказались сообщения SysEx.

Таким образом, эксклюзивные сообщения были разделены на два типа: предназначенные для производителей (Manufacturer Specific SysEx) и универсальные (Universal SysEx). В последнюю группу вошли все расширения протокола, а также общие команды для управления устройствами, не отраженные в голосовых сообщениях.

Для того, чтобы сопоставить SysEx с конкретным производителем, в заголовке сообщения передается идентификатор производителя (Manufacturer ID). Получив чужой идентификатор, устройство обычно пропускает все сообщение, так как просто не понимает его формат. Выдачей идентификаторов занимаются организации MMA и JMSC.

Общая структура сообщения SysEx такова: сначала идет статус-байт 0xF0, затем идентификатор производителя, затем какое-то количество байт данных, и признак завершения — байт EOX (End Of Exclusive, 0xF7), рис. 5. Каждый производитель применяет собственный формат и волен использовать в сообщении любое число байт данных. В принципе, устройство, для которого предназначено сообщение SysEx, само знает, сколько байт данных содержится в том или ином сообщении. Поэтому EOX нужен, в основном, для тех устройств, которые получили порцию SysEx, им не предназначенную; количество байт данных им неизвестно, поэтому они и ориентируются по ограничивающему байту EOX.

С другой стороны, сообщение 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), применяется при разработке и тестировании оборудования и не должен использоваться в устройствах, поставляемых на рынок. Группу универсальных сообщений SysEx поделили на две части: Universal Non-Real Time (сообщения, не критичные к времени передачи) и Universal Real Time (соответственно, критичные). Первой присвоили идентификатор 0x7E, второй — 0x7F.

Конечно, 31 производитель на регион — это несерьезно, и практически сразу все идентификаторы были заняты. Организации MMA и JMSC это предвидели и зарезервировали нулевой идентификатор (0x00) в качестве префикса, за которым передаются два байта, пара MSB:LSB, содержащие расширенный номер производителя, от 1 до 16383 (первым передается LSB). Сказанное иллюстрирует рисунок 6.

Европа

Япония