Тонкости протокола MIDI

[Gregory]

Ну, например, давно интересует такой вопрос:
есть ли какой-нибудь лимит на задержку между двумя байтами?
Что-то никак не могу найти вразумительного ответа.

 

[Rst7]

Теоретически он там не нужен. Потому что начало сообщения (не байта, а именно MIDI-сообщения) четко определяется по установленному старшему биту.

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

 

[Gregory]

Теоретически он там не нужен

Естественно, он только снижает пропускную способность и так не очень быстрого MIDI, но вопрос не об этом.
Оговорено ли это где-то в документации?

передавал готовое сообщение стык в стык

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

 

[Rst7]

Оговорено ли это где-то в документации?

Нет.

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

Ну это если совсем колбаса прет, то да. В реальной жизни паузы встречаются приличные.

 

[mrf]

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

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

это зачем? разве что при sysex bulk, но это оговаривается производителем инструмента. в остальном миди это непрерывный жесткий реалтайм.

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

 

[Alex Longard]

@Gregory, задержка между байтами программно несуществует, есть только структура Delta_timing которая описывает когда какое событие посылать.
на форуме Purebasic.info недавно скидывал либу HP_midifile для работы с миди, и там есть пример как несинхронно передаются по отдельности ноты и sys сообщения.

 

[Rst7]

это зачем?

Это для того, чтобы в случае ошибки в канале (пропуск стартового бита) быстрее обратно фреймовая (в смысле UART'a) синхронизация восстановилась.

 

[Gregory]

это зачем?

В принципе, уже сказали.
Хочу только добавить, что это - стандартное "правило хорошего тона" для УАРТа.
И опять же, как уже сказали, в реальной жизни, для МИДИ, оно выполняется практически всегда "автоматом".

на форуме Purebasic.info недавно скидывал либу HP_midifile

Это я и спрашивал.
Но только это - более высокий уровень, чем протокол МИДИ.

 

[dugdum®]

подкину на вентилятор.
говорят, тут 2.0 анонсировали
ссыль

 

[mrf]

@Rst7, мне очень интересно, при каких обстоятельствах вы сталкивались с пропуском стартбита? даже на 6n138 по схеме из гугла все работает. а если поставить дешманский современный оптрон - вообще целостность сигналов идеальная.
@Gregory, правило такое первый раз слышу.

в реальной жизни, для МИДИ, оно выполняется практически всегда "автоматом".

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

 

[Alex Longard]

@dugdum®, тссссс, только MPE начали реализовывать)))) Куда еще Midi 2.0))))

@mrf, железо оно и в Африке железо, все равно работа по приеме-передаче организуется программно и тут только заморочки и глюки железа могут вносить какие-то косяки. А апи хоть от микроволновки))))

ЗЫ: У друга кстати микроволновка с блютусом для управления со смарта и кучей непонятных опций, мы три часа долбались пока смогли найти где поменять мелодию для сигнала готовности))))
Техника ***** **** *****....!!!

 

[Rst7]

при каких обстоятельствах вы сталкивались с пропуском стартбита?

А Вы никогда в логах не видели, что приходит байт не с одним битом ошибки (ну от ожидаемого значения), а полностью разломанный?

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

Ну раз Вы тут ссылаетесь на "драйвер управления промышленным оборудованием", то давайте тогда обсудим обычную практику включения в режим передачи, скажем, драйвера RS485 (имеется в виду - драйвер линии передачи, микросхема) до начала собственно посылки? Посмотрите на стандарт MODBUS, подумайте, зачем там паузы в 3.5 символа между пакетами.
[DOUBLEPOST=1547971307][/DOUBLEPOST]

перечитал на 3 раза, не вижу кто и где это сказал?

Я сказал. Любая пауза в передаче на длительность более 1 символа починит фреймовую синхронизацию. Такое в реальной жизни в MIDI постоянно.
[DOUBLEPOST=1547971343][/DOUBLEPOST]

Ну это если совсем колбаса прет, то да. В реальной жизни паузы встречаются приличные.

 

[Alex Longard]

@Rst7, а как замерить задержку = при передаче миди-контроллер - порт?

Я вижу только вариант с низкоуровневым таймером проца, так как виндовая GetTickCount() возвращает какие-то неточные значения.

Я с потоковым миди еще не сталкивался, спецификацию скачал только по хранению в мидифайлах.

 

[Rst7]

а как замерить задержку = при передаче миди-контроллер - порт?

Мне не совсем понятно, какую задержку Вы хотите измерить?
[DOUBLEPOST=1547979013][/DOUBLEPOST]А вообще, если надо достаточно точно измерить время внутри винды, то функции QueryPerformanceCounter/QueryPerformanceFrequency Вам в помощь.

 

[Gregory]

виндовая GetTickCount()

Коллеги!
Очень прошу не зафлуживать тему.
Обсуждаем только "непонятные места" Musical Instrument Digital Interface.
И не файлы, и не верхние уровни.
Надеюсь на понимание.

 

[mrf]

А Вы никогда в логах не видели, что приходит байт не с одним битом ошибки (ну от ожидаемого значения), а полностью разломанный?

в логах чего? у меня всякое старье типа mpc1000, electribe, novation.. и мои стм32, лпц. ноты не залипают, не пропускаются. все контролы передаются. прошивки патчи по сисекс грузятся. на персоналке по rs232 работало по несколько суток без сбоев, там собственно в предыдущей версии сбои обусловлены были только неправильной реализацией межпроцессного взаимодействия. касательно кома все также было написано.. ну и как бы вот у меня осцилл и я им все эти новэйшены и корги смотрел и нигде межбайтных промежутков не припоминаю. поэтому и не пойму о чем здесь вообще...
с RS485 не работал, но википедия говорит что он полудуплекс, что полностью объясняет необходимость переключения драйверов и задержки. миди - симплекс.
и кажется мы немного о разных вещах. вы про промежутки между сообщениями или байтами. промежутки намеренные, или сложившиеся? я про то, что я ни в требованиях, ни в чужом коде не видел намеренных промежутков ни между сообщениями ни между байтами сообщений, и реализовав все без них получил рабочее решение.
не осуждаю ваши подходы. мне просто интересно, что мне нужно сделать, чтобы получить мидишный сбой, т.к. в настоящее время я абсолютно уверен в своих схемотехнике и коде.
@Alex_028, не понял ни про микроволновку, ни про глюки железа.

 

[Gregory]

я про то, что я ни в требованиях, ни в чужом коде не видел намеренных промежутков

Опуститесь уже на нижний уровень, наконец.
Вот Вам осциллограмка посылки без "защитных" интервалов:



Пояснять надо?

 

[Rst7]

Пояснять надо?

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

Спойлер

Кстати, в этом смысле в MIDI крайне неудачно выбрано действие на код 0xFF - это системный сброс. Достаточно, чтобы из-за более-менее продолжительной помехи приемник увидел только один старт - и вуаля, девайс сброшен. Лучше бы 0xFF был просто NOP'ом, тогда бы его отлично можно было использовать в качестве паузы для восстановления фреймовой синхронизации. Хотя, конечно, отсутствие хоть какого-то намека на контрольную сумму - это провал из провалов, черти в аду уже давно заготовили котел для таких разработчиков.

 

[Gregory]

Спойлер

производя семплирование в середине стартового бита

Ну, это я так делал, когда софтовый УАРТ реализовывал.
Аппаратный модуль может позволить себе алгоритм посложнее.
Во-первых, несколько выборок.
Во-вторых, какой-нибудь подсчёт уровней, и принятие решения на основе превышения какого-то процента.
Ну а с КС, всё понятно. Было гораздо важнее увеличить пропускную способность, чем обеспечивать правильность пакета.

 

[Rst7]

Спойлер

Аппаратный модуль может позволить себе алгоритм посложнее.

Вы не поверите, но 100% UART'ов, например, в микроконтроллерах (да и 8251/8250/16550/etc то же)- именно такие, как я описал. Ну разве что выборок в середине бывает, скажем, не одна, а три. С обычной скоростью, скажем 16*B, где B - битовая скорость.

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

 

[mrf]

@Gregory, я конкретный вопрос задавал. мне очень интересно, сталкивались ли вы или кто-либо еще с такими отказами МИДИ? и что являлось причиной помех или пропуска стартового бита?

 

[Gregory]

с такими отказами МИДИ?

Так сказали же уже, что в реальной жизни, в МИДИ защитный интервал "автоматически" присутствует.
Ну а вообще с УАРТом, как-то по-молодости пол дня потратил, пока понял, почему посылки идут, а приёмник их не воспринимает. На всю жизнь запомнил.
P.S.: Хотя, можете попробовать на рабочем интерфейсе кабель выдернуть и вставить.


Продолжаем по теме.
Вот сейчас пытаюсь с СисЕксами разобраться.
Что-то окромя начального-конечного байтов, да АйДи Мануфактуре, полный бардак. Например Девайс АйДи должен перед Модель АйДи стоять, или после? Вроде как пишут, что он должен обозначать основной МИДИ-канал устройства, а значение 7Fh - омни, но в то же время видел в мануале, что он может быть 00h - 1Fh.
Опять же алгоритмы упаковки данных.
Пока видел два метода:
1. Тупой последовательный сдвиг 7 байт со вставкой нулей.
2. Первым идёт новый (8-й) байт, содержащий старшие биты всех 7-ми.
И как оно выглядит, когда число байт в блоке не дотягивает до 7-ми?
По второму способу, вроде для отсутствующих байтов, старшие биты пишутся "0".
Для первого, видимо, недостающие в конце последнего получившегося байта биты, тоже заполняются "0".

 

[Gregory]

Народ!
Controller 32, это - когда байты дублируются, или наоборот?

 

[mrf]

если вопрос про CC 32 (0x20) - то младший байт банк селекта. фактически основной, т.к. я не знаю инструментов с >128 банками. старший просто не используется. не совсем поняты цели вопросов. в зависимости от того, делаете ли вы контроллер для какого-либо устройства, или разрабатываете миди управление для своего, ответы будут разными. в любом случае я предлагаю ориентироваться на выпущенные ранее синты, к примеру для меня эталоны это электрайб емх (имеет очень детальное описание внутренней кухни), вальдорф блофелд и вирус ц. если вы делаете общую миди библиотеку, то жестко зашитые сисексы и номера сс это то, что создаст много проблем.

 

[Gregory]

ответы будут разными

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

 

[mrf]

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

 

[Gregory]

если это контроллер для конкретного синта

Вы меня не слушаете.
Не меняется протокол из-за контроллера.

 

[Gregory]

Продолжаю вникать в СисЕксы.
Пока собственно вопросы те же.
Например: Где всё-таки должен находиться Девайсе АйДи, сразу послеМануфактуре АйДи, или после номера модели?
Кстати, некоторые производители (замечен Алесис) Девайсом АйДи как-раз и называют номер модели.

 

[Gregory]

Коллеги!
Никто матбазу не учит что ли?
Ну тогда вопрос на более общую тему: должен ли такой девайс, как MIDI-merger отрабатывать миди-команды Ресет и Актив Сенсинж?