Структура midi сообщения

[vopros-otvet]

Здесь есть знающие люди, которые могут мне рассказать про миди сообщение?

Я затеялся писать програмку, переающую из последовательного порта миди сообщения с синтезатора (скорости согласованы).

Но вот столкнулся с проблеммой программной. Пишу на VB и не пойму какой тип данных мне нужно указывать в функции передачи сообщения.

Помогите, пожалуйста.

[BCluster]

ну миди сообщение это 3 байта, тип данных unsigned char (как это в васике я хз). можете как массив из 3 чаров передавать в фукнцию. А можно и просто как одно число...

[Dmitry Dubrovenko]

А кто-нибудь изучал структуру MIDI-файлов?

[vopros-otvet]

Нет, но на сайте майкрософт есть инфо. Гугл в помощь)))

Для начала бы не мешало всю подсистему миди интегрировать в программу... А потом уже миди файлами заниматься...

К сожалению, на .Net НэТу полной поддержки миди разработки. Нужно самому сидеть шариться по виндовым хедерам, понимать DWORDы эти, структуры виндовые... Ужас. Мне мак ось в этом плане по душе, - немного там проще все. Хоть я и не программер...

[Dmitry Dubrovenko]

Гугл в помощь

А то я не знал.
Кое-что уже нашёл, но хотелось бы, конечно, пообщаться с тем, кто реально что-то делал.

Для начала бы не мешало всю подсистему миди интегрировать в программу

Ну, это - кому, как. Я не собираюсь (пока, во всяком случае) писАть программу-секвенсор. Мне надо именно миди-файлы обрабатывать (преобразовывать).


А вот ещё вопрос по непосредственно самому протоколу MIDI. Как я знаю, в некоторых случаях, для команды Note-On, допускается передача одного статусного байта с последующей передачи множества байтов данных.
Так вот, это допускается только для Note-On, или для других команд тоже?
Какова максимальная задержка (и допукается ли вообще) между передачей отдельных байтов?
Кстати, для выяснения последнего пункта, была попытка написания проги, которая бы могла посылать отдельные байты. Но что-то не нашли в Винде такой возможности. Только команду целиком.

[vopros-otvet]

Да, Верно. Для Note On и Note Off допускается передача одного статусного байта. То же самое для сообщений контроллеров. Задержка в передаче упакованных сообщений (не отдельных байтов), но без статусного байта, не имеет значения. Побайтово передавать миди сообщения никак нельзя, т.к. миди сообщение - пакет, содержащий три параметра, которые никак нельзя разделять. (для взятие ноты, например, - это статус, нота и ее велосити, насколько я помню). Чтобы передать байты по-отдельности, нужно, чтобы подсистема миди зависала в промежутке между передачами))) Не надо забывать, что существует такое понятие, как бод рейт в 31250 бод/сек. Теоретически допускается задержка в 1/31250-ю секунды... Когда я собирал преобразователь COM/USB, я конечно же принимал сообщения побайтово в порте, отфильтровывая все ненужное (ну вчастности байт индикации соединения). А сами сообщения приходили строго последовательно побайтово.

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

Для чего вам кстати нужно побайтово передавать сообщение?

[Dmitry Dubrovenko]

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

Побайтово передавать миди сообщения никак нельзя, т.к. миди сообщение - пакет, содержащий три параметра, которые никак нельзя разделять.

Одно взаимоисключает другое.
Собственно нужны не догадки, а точная информация.
А знание данного момента нужно во многих случаях. Например, для изготовления миди-микшера.

для того, чтобы обрабатывать миди информацию в файле лучше всего пользоваться виндовыми функциями из библиотеки winmm.

Да, нафига мне виндовые библиотеки, если можно просто взять, и обработать файл побайтно?
Я не прав?

[vopros-otvet]

ЫЫЫ))) Ладно. Хотите конкретики... Будет вам конкретика...
Во-первых одно НЕ взаимоисключает другое. МИДИ сообщение - это тип данных, состоящий из 4-х БАЙТ информации - DWORD (unsigned char) (именно поэтому он называется УПАКОВАННЫМ СООБЩЕНИЕМ).

Просто направить в порт три байта подряд не получится, - вся информация передается ЧЕРЕЗ ВИНДОВЫЕ БИБЛИОТЕКИ, а ФУНКЦИИ в них (например функция передачи короткого миди сообщения) запрашивают СТРОГО ОПРЕДЕЛЕННЫЕ параметры и ТИПЫ ДАННЫХ, такие как структуры миди тайминг, миди аут порт, миди ин порт, миди сообщение и т.п. Обойти эти библиотеки, - значит написать новую мультимедиа библиотеку и заработать на этом кучу денег))))

Упаковывается это сообщение не арифметическими операциями, а бинарными преобразованиями. т.е. сообщение из трех байт 90 2с f1 (написал от понта) пакуется и получается DWORD 0x00f12c90. Если функция типа SendShortMsg(MidiInPort IN, DWORD msg) требует DWORD тип данных, как можно с задержкой передать каждый из трех байтов? Сначала 0xf1 потом 0x2c потом 0x90 чтоли? Вас компьютер не поймет.

А что миди микшер, - простой буффер с открытыми миди портами и выводом в отдельный миди порт...

Что именно вы собираетесь делать с миди файлом, - смотреть на него или все-таки какие-то моменты слушать, анализировать и т.п.? Как это зачем виндовые библиотеки. Без хедера winmm.h нельзя никак обработать миди файл. Или разве что я не понимаю вашей цели.

[Dmitry Dubrovenko]

Или разве что я не понимаю вашей цели.

Абсолютно.
Вы забыли, что MIDI создавался в те времена, когда Билли только-только втюхивал IBM свой первый ДОС, и существует огромное количество устройств, работающих по данному интерфейсу, и которым глубоко фиолетово на виндовые библиотеки.
Я же говорил, что вопрос про непосредственно MIDI-интерфейс, а он представляет из себя обычный UART, по которому байты можно передавать хоть подряд, хоть по одиночке.
Про ограничения Винды я как-раз и говорил, когда рассказывал об обломе с терминалкой. Однако, я не большой специалист по программированию на PC, поэтому глубоко в детали, насколько это возможно, не вдавался.
А миди-файл мне вовсе нет никакой необходимости воспроизводить. Я же сказал, что мне нужно просто считать информацию, и преобразовать в другой вид. Типа такого:

[vopros-otvet]

Я понимаю, что интерфейс сам по себе UART. Только вот по-одиночке байты передавать нельзя. Разве что у вас есть два созданных именно вами устройства и только вы понимаете как она работают. Ну вот к примеру ноль в миди сообщении - это не пустое место, а параметр, кодирующий, в зависимости от положения в сообщении, разные параметры. а чтобы каждый момент времени в UART не заполнялся нолями в отсутствии сообщений на входе, - придумали байт индикации соединения... Там ведь всего 255 значений доступно для кодировки. А параметров ведь так много...

А Winmm.h прийдется пошуршить. В структуре миди файла надо научиться разделять такие структуры как тик, миди тайминг и т.п короткое и длинное миди сообщение. Ясное дело, что можно написать вот так: #define 0x90 NOTE_ON и использовать в проге такую дефиницию для простоты. Но прикол в том, что помимо коротких миди сообщений существуют и другие. И все надо оперативненько различать и сортировать, чтобы сделать аутпут в какой-нить другой файл с другой структурой. Все же заключается еще и в том, чтобы различить паузы, такты, доли. Для этого нужно работать с временными параметрами...

И все равно не понимаю, - как можно увязать преобразование миди файла и UART? Не пойму причем тут одно к другому. Вы спросили за программную обработку миди файла. Я вам и ответил про программные средства, а не про аппаратные.

[Dmitry Dubrovenko]

Вы спросили за программную обработку миди файла.

Это где?
Я спросил сперва про структуру миди-файла, а потом про протокол МИДИ. Я эти вопросы не объединял.

Как-то Вы странно изъясняетесь, или просто протокол МИДИ не знаете?
Про какой ноль Вы говорите? Начнём с того, что пассивное состояние, это - единица, и длиться оно (состояние) может сколь угодно долго. Какие параметры, при этом должны нулями забиваться?
Действительно, существует специальное сообщение Active Sensing, но я ещё не встречал девайса, который его бы использовал. Возможно Вы путаете с Timing Clock?
По-моему, Вы просто понимаете МИДИ исключительно через Маздай, а на самом деле, это абсолютно "самостоятельная жизнь".

А Winmm.h прийдется пошуршить.

Кто такой этот Winmm.h? Зачем он шуршал?
Короче говоря, ничего я из сказанного не понял.
Попробую сам пошерстить инфу, тогда и продолжим разговор.

[vopros-otvet]

Вы спросили за программную обработку миди файла.

Это где?
Я спросил сперва про структуру миди-файла, а потом про протокол МИДИ. Я эти вопросы не объединял.

Как-то Вы странно изъясняетесь, или просто протокол МИДИ не знаете?
Про какой ноль Вы говорите? Начнём с того, что пассивное состояние, это - единица, и длиться оно (состояние) может сколь угодно долго. Какие параметры, при этом должны нулями забиваться?
Действительно, существует специальное сообщение Active Sensing, но я ещё не встречал девайса, который его бы использовал. Возможно Вы путаете с Timing Clock?
По-моему, Вы просто понимаете МИДИ исключительно через Маздай, а на самом деле, это абсолютно "самостоятельная жизнь".

А Winmm.h прийдется пошуршить.

Кто такой этот Winmm.h? Зачем он шуршал?
Короче говоря, ничего я из сказанного не понял.
Попробую сам пошерстить инфу, тогда и продолжим разговор.

1) Да, winmm.h эт я загнул)) я имел ввиду mmsystem.h)) В нем содержаться дефиниции всех структур, типов данных и т.п., используемых подсистемой миди.

2) Я не понимаю почему вы путаете логический ноль и шестнадцатиричный 0x00 (ну или десятичный 0). Скажите мне пожалуйста: что будет если на вход порта не поступает никаких сообщений? Правильно, - программа будет воспринимать это как БАЙТ со значением 0 (NULL) и буффер забъет этими нолями на каждый "тик" порта, пока на вход что-нить не поступит. А сам по себе БАЙТ 0 имеет определенный СМЫСЛ и кодирует определенное ЗНАЧЕНИЕ в миди сообщении. Странно если вы не встречали девайса, использующего Active Sensing. Я писал программу, транслирующую миди сообщения из самодельного UART с измененным бодрейтом (к его входу были подключены клавиши, - синтезатор всмысле). Так вот какой же может быть миди тайминг без включенной кнопочки СТАРТ на синте??? НИКАКОГО. Правильно. Поэтому там и мелькает в промежутках между миди сообщениями актив сенсинг.

Честно, - не говорил бы ничего того, чего не реализовывал бы сам (хоть и давненько уже).

Я не профи программист, но в нужных мне объемах освоил когда-то язык C++ и Basic (всмысле абсолютно все необходимое для написания программ). Мудохался я с подсистемой миди дай бог... Пришлось много чего понять и узнать...

[Dmitry Dubrovenko]

Правильно, - программа будет воспринимать это как БАЙТ со значением 0 (NULL) и буффер забъет этими нолями на каждый "тик" порта, пока на вход что-нить не поступит.

Как уже говорил, не силён в программировании Винды, но почему нельзя сделать ожидание поступления сообщения с порта?
Ну, и возвращаясь собственно к вопросу. Он (вопрос) был про протокол МИДИ, а не про программирование.

Поэтому там и мелькает в промежутках между миди сообщениями актив сенсинг

Вот именно как-раз там мелькает Timing Clock, а вовсе не Active Sensing.
Если не верите, запустите какой-нибудь Сонар, включите там "Передавать сигналы синхронизации", и наблюдайте в МИДИ-Оксе, что будет происходить.

[vopros-otvet]

Странно... Ну да ладно... У меня уже все равно давно нету той клавы,- не проверить. но по-моему я там что-то отключал, чтобы не перегружать програму ненужными сообщениями. А актив сенсинг точно был.

Так стоп.... Недочитался... Мы же с вами вроде об аппаратном миди говорили а не о сонаре и подобных ему секвенсорах... ЕСТЕССТВЕННО если включить данную опцию в программе, будет передаваться сигнал синхронизации. Так сонар НЕ БУДЕТ же передавать актив сенсинг! Какой может быть актив сенсинг, если это секвенсер?

[Dmitry Dubrovenko]

А актив сенсинг точно был.

Возможно, возможно.

Какой может быть актив сенсинг, если это секвенсер?

Да какая разница?
Что, секвенсор не может (теоретически) проверять целостность соединений?
Кто ему запрещает?

[vopros-otvet]

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

А секвенсор сенсинг не использует однозначно...

Вы уж простите, что включился так активно в тему, - мне просто самому очень интерестно это все ))

[Dmitry Dubrovenko]

Ну сенсинг - это не проверка соединения, - это же индикация оного.

А индикация не является проверкой?

А секвенсор сенсинг не использует однозначно...

А это всё чисто от разработчика зависит.

[vopros-otvet]

Сенсинг не является проверкой. Ведь если бы секвенсор проверял соединение, он должен был бы знать дошел ли его сенсинг байт до адресата... А миди - это соединение в одну сторону (отдельно миди ин и отдельно миди аут), поэтому такая проверка состояться не может... Нее, - это однозначно.

[Dmitry Dubrovenko]

Ведь если бы секвенсор проверял соединение, он должен был бы знать дошел ли его сенсинг байт до адресата

Это, как правильно заметили, если бы интерфейс был двунаправленным.
Но "адресат", не получив, скажем, в течение 2х секунд Active Sensing, может начать "орать". Можете называть такой способ проверки "индикацией", но ни для чего другого Active Sensing не используется.

[Dmitry Dubrovenko]

Ну, вроде бы разобрался я с миди-файлами.
Результат здесь.