Генерирование сообщений

ЧАСТЬ 2. СООБЩЕНИЯ КАНАЛА

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

В первой части цикла рассказывалось о предпосылках к появлению MIDI, развитии синтезаторов, о процессе подготовки и внедрения спецификации MIDI, расширении протокола за последние двадцать лет. Рассматривались компоненты MIDI, коммутация устройств, основы двоичной и шестнадцатеричной систем счисления. Начато рассмотрение языка MIDI: типов сообщений и принципов их кодирования.

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

Системные сообщения отложим до лучших времен, а сегодня поговорим о сообщениях канала — основном строительном материале языка MIDI.

Напомню, что сообщения канала делятся на два типа: голосовые и сообщения режима канала. Первые связаны со звукообразованием, вторые к этому прямого отношения не имеют, но играют в деле управления MIDI-устройством не последнюю роль.

Голосовое сообщение заставляет тон-генератор произвести какое-либо изменение в звуке (или, собственно, сам звук). Например, если исполнитель нажимает клавишу, в тон-генератор посылается сообщение Note On, на которое тот реагирует воспроизведением ноты. Если исполнитель поворачивает колесо модуляции, тон-генератор изменяет глубину модуляции звучащей ноты.

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

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

В некоторых случаях спецификация однозначно задает такое преобразование. Например, нота с номером 60 должна быть всегда нотой До первой октавы и иметь частоту 261 Гц. Тон-генератор подчиняется. В других случаях спецификация рекомендует, чтобы, например, при динамике 120 уровень на выходе осциллятора снижался на 0,98 дБ от максимального. Наконец, для параметров вроде модуляции никаких рекомендаций не дается — коэффициент модуляции зависит от особенностей внутренней архитектуры инструмента.

Байты данных

Информацию с органов управления можно разделить на два основных вида: логический и числовой. Если, например, педаль имеет только два состояния (нажата или отпущена, On/Off), то это — логическая информация. Если же мы крутим колесо, то каждое его положение представляется одним значением из некоторого диапазона.

Как это закодировать? Для логической информации достаточно, по идее, одного бита. Если бит сброшен (0), то педаль (или кнопка) отпущена, если установлен (1), то нажата. Но минимальной единицей информации в MIDI является байт, в данном случае байт данных. Поэтому придется использовать его целиком, несмотря на то, что реально нужен только один бит.

Для числовой информации один MIDI-байт позволяет закодировать 128 различных значений (от 0 от 127). А если изменения в звуке требуют более тонкой градации? Тогда используются два байта. Диапазон значений, который можно закодировать двумя обычными байтами, составляет 2¹⁶-1, то есть от 0 до 65535. Но в MIDI, как говорилось в предыдущей статье, один бит из байта расходуется по служебной необходимости, поэтому два MIDI-байта дают в наше распоряжение только 14 бит. Но и это уже неплохо: 2¹⁴ дает 16384 различных значений. Для изменений параметров синтеза этого более чем достаточно.

Мы уже говорили, что два байта составляют машинное слово. На рисунке 2 показана схема "MIDI-слова". Старшие биты обоих байтов заняты (сброшены в 0; напомню, что таким образом приемник может всегда отличить байт данных от статус-байта, в котором старший бит установлен в 1). Биты с 0 по 6 составляют младший значащий MIDI-байт (LSB, Least Significant Byte), c 8 по 14 — старший значащий байт (MSB, Most Significant Byte)

Работая с устройствами, удобнее представлять пару MSB:LSB не как одно большое число, а как результат грубой и тонкой настройки. MSB можно представлять в виде линейки с крупным делением шкалы (128 отрезков, рис. 3). Но если поднести к линейке лупу, то мы увидим, что каждый отрезок состоит еще из 128 частей. Можно представить MSB сантиметрами, а LSB — миллиметрами. Зачастую тонкая настройка не нужна даже для тех параметров, которые ее позволяют. Достаточно "сантиметровой линейки". С помощью нее можно оперировать шагами по 128. Установили MSB в 93, получили значение 11904, установили в 94 — получили 12032. Во многих случаях такой точности вполне достаточно.

Но бывает, параметр нужно задать абсолютно точно. Например, в MIDI предусмотрено до 16384 банков звуков. Команда "выбрать примерно 15-й банк" здесь не пройдет. Нужен точный номер банка, а, следовательно, пара MSB:LSB.

Уровни кодирования

Голосовых сообщений довольно много: это и нажатие/отпускание клавиши, и давление на клавишу после нажатия (послекасание), вращение колес высоты тона и модуляции, нажатие педалей, кнопок, передвижение слайдеров; наконец, сообщения, напрямую задающие параметры синтеза. В общем, почти сотня наберется. А на все про все только семь статус-байтов...

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

Итак, можно выделить два множества сообщений или, иначе, два уровня кодирования. Доступ к первому — прямой, ко второму — только через посредника.

Следующая таблица показывает сообщения первого уровня (рис. 4). Статус-байты даны в двоичном, десятичном и шестнадцатеричном виде. Младшая половина статус-байта (4 бита) содержит номер канала, которому адресовано сообщение. Так, например статус-байты в диапазоне от 10010000 (0x90) до 10011111 (0x9F) означают одно и тоже сообщение Note On, в диапазоне от 11000000 (0xC0) до 11001111 (0xCF) — сообщение Program Change и т. д. То есть, статус-байт, соответствующий одному типу сообщения, может быть представлен в шестнадцати вариантах, в зависимости от номера канала. В MIDI, как и во всем компьютерном мире, отсчет ведется с нуля. При передаче сообщений первый канал кодируется как 0000, второй как 0001, а шестнадцатый — как 1111 (десятичное 15, шестнадцатеричное 0xF).

Основной "целевой группой" MIDI являются инструменты клавишного типа (синтезаторы), поэтому набор наиболее часто употребляемых сообщений вполне обоснован. Это, прежде всего, сообщения о нажатии и отпускании клавиши (Note On / Note Off), сообщения послекасания (Aftertouch Channel / Aftertouch Polyphonic), вращения звуковысотного колеса (Pitch Wheel Change) и смены программы (Program Change).

Статус-байт-посредник получил название Control Change ("изменение управления"). В спецификации все сообщения, вызываемые через этот байт, называются сообщениями типа Control Change, и предполагается, что они "генерируются манипулятором, отличным от клавиатуры". Но, например, колесо питч-бенда — тоже манипулятор, отличный от клавиатуры, однако он к группе Control Change не относится. Музыканты настолько часто им пользуются, что его просто невыгодно помещать во второй уровень. А вот колесо модуляции используется пореже, и там ему самое место. Хотя, повторю, это все в среднем: иногда вы можете руку не снимать с колеса модуляции, а к колесу высоты тона даже не прикоснуться.

Таким образом, "сообщения об изменении управления" — название условное, а функция статус-байта Control Change служебная. Он просто действует как префикс, открывающий путь к другим сообщениям.

Получается такая картина. Если пришел статус байт вида 1100nnnn, то инструмент сразу по нему определяет тип сообщения, — в данном случае это Program Change. Если пришел статус-байт 1011nnnn, то инструмент видит, что это байт-посредник, который о типе сообщения ничего не говорит, а просто уведомляет: сейчас пойдет сообщение второго уровня. Какое именно — смотри байт данных, следующий за посредником. Синтезатор читает этот байт и определяет, что это сообщение колеса модуляции. Положение колеса будет передано в третьем, завершающем байте (см. рис. 7). Таким образом, с помощью статус-байта-посредника и следующего за ним байта данных можно закодировать 128 сообщений.

Эти сообщения показаны в таблице на рис. 5. Их принято называть сообщениями контроллеров, но правильнее было бы называть сообщениями второго уровня. Слово контроллер не очень удачно еще и потому, что под контроллером часто подразумевается физический орган управления — колесо, движок или педаль. Поэтому догадаться о том, что имеется в виду — сообщение типа Control Change или физическое устройство, иногда бывает очень сложно, даже по контексту. Но традиция сложилась, поэтому под словом "контроллер" я буду иметь в виду сообщение второго уровня. А физическое устройство буду называть органом управления.

Сообщения контроллеров обозначаются в документации как СС#N (сообщение Control Change номер N, в десятичном представлении), например, сообщение колеса модуляции обозначается как CC#1.

Из таблицы видно, что часть сообщений контроллеров не определена (такие сообщения могут использоваться экспериментаторами и производителями для тестирования или отладки оборудования). Восемь последних сообщений (СС#120 — CC#127) являются сообщениями режима канала. Они применяются довольно редко, поэтому выделять им место в ограниченном первом уровне, то есть давать собственный статус-байт, не было смысла.

Можно заметить, что многие сообщения, выполняющие одну и ту же функцию, представлены двумя вариантами: MSB и LSB. Зачем такое разделение, почему не передавать пару MSB:LSB в одном сообщении? Во-первых, это увеличит длину всех сообщений второго уровня: за байтом-посредником придется передавать не два, а три байта. Многим контроллерам это не нужно — они позволяют производить только грубую настройку. Во-вторых, даже для контроллеров высокого разрешения часто можно обойтись грубой настройкой, и передавать LSB нет смысла.

Несмотря на то, что среди сообщений второго уровня есть более 50 свободных (которые пока не определены), разработчикам, видимо, понравилось прятать сообщения за посредниками, и они сделали третий уровень кодирования.

Идея такая: выделить специальное сообщение контроллера, в байте данных которого будет передаваться номер сообщения третьего уровня. Было решено задавать такой номер двумя байтами данных. На деле это означает, что для адресации должна использоваться пара MSB:LSB. Плюс ко всему, сообщения третьего уровня разбили на два типа: зарегистрированные параметры (RPN, Registered Parameter Numbers) и незарегистрированные параметры (NRPN, Non Registered Parameter Numbers). Первые кодируются с помощью пары CC#101:CC#100, вторые — СС#99:CC#98. Таким образом, третий уровень может содержать 16384 зарегистрированных параметров и 16384 незарегистрированных, то есть всего 32768 сообщений. Что ж, на первое время хватит...

Спецификация определяет назначение только для зарегистрированных параметров. В настоящий момент определены пять параметров, которые перечислены в таблице на рис. 6. Организации MMA и JMSC медленно, но верно пополняют этот список.

Незарегистрированные параметры предназначены для свободного использования. Каждый производитель может придумывать свои номера NRPN и использовать их так, как считает нужным. Фирмы Roland и Yamaha первыми приложили к ним руку, что отражено в стандартах GS и XG соответственно. Более подробно об NRPN, используемых в этих стандартах, поговорим в отдельной статье.

Проблема, которая может возникнуть при использовании NRPN, — несовместимость устройств. Так, одно устройство может применять NRPN номер 1 для настройки добротности эквалайзера, а другое — для изменения точки начала петли внутри семпла. Особенно неприятно это при соединении приборов в цепь (посредством разъемов Thru). Тогда потенциально несовместимые NRPN могут передаваться по всей цепи, что приведет к неверной их интерпретации. Многие устройства в этой связи позволяют отключить реакцию на NRPN.

Как получить доступ к сообщению третьего уровня? Для начала нужно задать его номер, используя пару MSB: LSB. Например, для сообщения RPN номер 1 эта пара будет иметь вид 0:1. Следовательно, нужно послать в CC#101 значение 0, а в CC#100 — 1. Таким образом, мы даем знать тон-генератору, какой параметр нас интересует. Для передачи значения параметра есть специально выделенный контроллер высокого разрешения под названием Data Entry (пара MSB:LSB, CC#6:CC#38). Предположим, нам нужно задать параметру RPN номер 1 значение 500. Пара MSB:LSB в этом случае будет иметь вид 3:116 (128 x 3 + 116 = 500). Посылаем в CC#6 значение 3, а в CC#38 — 116. Если какой-либо параметр не требует тонкой настройки, достаточно послать только MSB посредством контроллера CC#6.

Если нужно увеличить или уменьшить на единицу ранее переданное значение параметра, то для этого проще воспользоваться сообщениями Data Increment (СС#96) или Data Decrement (CC#97). Передавать заново пару MSB:LSB не нужно. Байт данных в сообщениях Data Increment/Decrement не используется и должен быть равен нулю. Пример использования контроллеров Data Entry и Data Increment/Decrement приведен далее, в разделе "RPN".

Доступ к параметрам NRPN происходит аналогично, только номер параметра задается парой CC#101:СС#100.

На рис. 7 показана схема передачи сообщений разного уровня, а на рис. 8 — требуемое количество байт.

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

Непрерывные контроллеры (Continuous Controllers) — это такие контроллеры, которые обычно посылаются целой серией и представляют собой поток плавно изменяющихся значений параметра. Например, при перемещении колеса модуляции из положения 100 в положение 200 генерируется множество сообщений Modulation Wheel, каждое сообщение будет передавать текущее положение колеса (в данном случае 100, 101, 102 и т. д.). Поскольку отличие двух соседних значений небольшое, будет складываться ощущение действительно непрерывного изменения глубины модуляции.

Непрерывные контроллеры можно дополнительно разделить на контроллеры высокого и контроллеры низкого разрешения. К первому типу спецификация относит сообщения из диапазона CC#0-CC#63 и CC#98-CC#101 (то есть пары MSB:LSB), ко второму — из диапазона CC#70-CC#95, а также сообщение режима канала Poly Mode Off (CC#126).

На самом деле, часть этих "непрерывных" контроллеров используется для статичной настройки. Например, сообщение Bank Select (выбор банка), в отличие от Modulation Wheel, нет смысла посылать целой серией с последовательно увеличивающимися номерами банков. Обычно банк выбирается один раз, ну иногда меняется по ходу дела. Подобные сообщения правильнее было бы назвать "статичными".

В первом уровне кодирования к сообщениям непрерывного типа относятся два вида послекасания (низкое разрешение) и Pitch Wheel Change (высокое разрешение). Сообщения Note Off, Note On и Program Change можно отнести к статичным, а сообщение Control Change само по себе ни в какую группу не попадает, так как является посредником.

Все зарегистрированные параметры третьего уровня также относятся к статичным.

Контроллеры-переключатели (СС#64-CC#69) могут передавать только два значения: включено или выключено (On/Off). Протокол связывает их с педалями всевозможных типов. Сюда же относится сообщение режима канала Local Control On/Off (CC#122).

Простые команды вообще не передают никакой информации, кроме самой команды. Например, сообщение режима канала All Notes Off (CC#123) просит тон-генератор выключить звучащие ноты. И только.

К простым командам относятся контроллеры CC#96, CC#97, CC#120, CC#121, CC#123, CC#124, CC#125, CC#127.

Рис. 9 подытоживает вышесказанное. Некоторые сообщения (вроде панорамы) однозначно отнести к непрерывным или статичным сложно. Например, панорама (Pan) может выставляться один раз в начале работы, а может меняться непрерывно, для создания эффекта перемещения по стереобазе.

Генерирование сообщений

В названии многих сообщений отражен физический орган управления. Но это не значит, что, например, сообщение Pitch Wheel Change можно генерировать только с помощью звуковысотного колеса. Блоку синтеза внутри тон-генератора абсолютно все равно, какой орган управления используется. Важно то, какой смысл несет в себе сообщение и на какой параметр синтеза влияет. В данном случае изменяется высота тона.

Если вы управляете тон-генератором из секвенсора, то вопрос о генерировании сообщений вообще становится второстепенным. Главное — они записаны и передаются на выход секвенсора при нажатии кнопки Play. Для записи сообщения Pitch Wheel Change вы могли крутить реальное колесо, могли нарисовать график с помощью мыши, а могли вводить в память устройства "голые" цифры.

Современные синтезаторы позволяют управлять массой параметров, но количество органов управления на передней панели, как правило, ограничено. Так что, например, один и тот же слайдер может использоваться для управления разными функциями. Если в данный момент нужно управлять частотой среза фильтра, вы назначаете движок на передачу соответствующего сообщения. В другой ситуации вы можете использовать тот же движок для управления громкостью или панорамой. Одним словом, синтезаторы позволят назначать органы управления на передачу любых сообщений. Если вам удобнее менять глубину модуляции с помощью фейдера, — пожалуйста, назначьте на фейдер сообщение CC#1 (Modulation Wheel).

Естественно, сообщения должны быть совместимы по типу. Так, если педаль представляет собой контроллер-переключатель, то есть имеет только два состояния "нажата/отпущена", то чаще всего нет смысла назначать ее для управления непрерывным сообщением вроде модуляции.

Кроме того, существует возможность переназначения контроллеров. Например, секвенсор можно настроить так, чтобы при приеме сообщений Modulation Wheel они преобразовывались в сообщения Pan. Тогда при вращении колеса модуляции будут записаны сообщения об изменении панорамы. Подобным образом можно настроить и многие тон-генераторы. Например, сообщения послекасания, поступающие на MIDI-вход устройства, могут преобразовываться в сообщения модуляции. Переназначение можно выполнять и на стороне передатчика, когда генерируется сообщение одного типа, но прежде чем попасть на MIDI-выход, оно преобразуется в сообщение другого типа. Одним словом, переназначение дает дополнительную гибкость в управлении MIDI-системой.

Обработка сообщений

Сообщение может поступить напрямую с органа управления, из секвенсора, образоваться как результат переназначения — это не так существенно. После того, как оно поступило в звукообразующую часть тон-генератора, оно должно использоваться по прямому назначению. Так, например, сообщение контроллера CC#10 должно приводить к изменению панорамы, а не высоты тона. В случаях, когда действие контроллера четко не определено, производителю дается свобода выбора. Например, сообщение Foot Pedal может управлять темпом ритм-машинки. Для реализации функций, которых нет среди стандартных сообщений, могут использоваться сообщения типа General Purpose, NRPN или SysEx.

Естественно, не каждое устройство реагирует на все определенные в протоколе сообщения. Обычно в руководстве к устройству содержится так называемая карта MIDI-реализации (MIDI Implementation Chart), которая наглядно показывает, на какие сообщения устройство реагирует, какие может генерировать и т. д. Более подробно о картах реализации поговорим в статье, посвященной устройствам.

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

Кроме того, инструмент запоминает однажды выставленное значение контроллера и использует его до тех пор, пока оно явно не будет изменено или не произойдет принудительный сброс посредством специальных команд. Так, если сдвинуть колесо модуляции из нулевого положения, то модуляция будет применяться к звукам до тех пор, пока не повернуть колесо обратно. Со звуковысотным колесом проще — при отпускании оно обычно возвращается в исходное состояние автоматически.

Тот факт, что устройство "помнит" ранее выставленный контроллер, позволяет избежать многократной передачи пары MSB:LSB. Если происходит постоянная тонкая подстройка в узком диапазоне, то можно один раз передать MSB, а затем — серию из нескольких LSB. Это и удобнее, и время передачи уменьшается.

Многие устройства не реагируют на тонкую подстройку для большинства контроллеров. Это вполне нормально, если производитель считает, что повышенная точность в данном сообщении не нужна. Например, в контроллерах громкости и экспрессии обычно хватает 128 уровней.

Состояние контроллеров-переключателей передается в одном байте, а, следовательно, допускает 128 значений. Возникает вопрос — что считать за On, а что за Off? Спецификация требует, чтобы значения от 0 до 63 рассматривались как Off (выключено), а значения от 64 до 127 — как On (включено). Для совместимости со старыми инструментами рекомендуется всегда посылать Off как 0, а On как 127.

Контроллеры, относящиеся к простым командам, не передают дополнительной информации, и третий байт в сообщении должен быть всегда равен нулю. Приемное устройство должно игнорировать этот байт, даже если по какой-то причине он содержит значение, отличное от нуля.

Поиск по сайту: