Как работает МИДИ энкодер?

dim3740

Active Member
28 Фев 2013
455
77
28
Уфа
Здравствуйте. Итак, не говорим про потенциометры, подключаемые к аналоговым входам. Говорим, про "цифровые крутилки".
По конструкции, думаю, что они все "бесконечные". ОК.

В настройках ПО брендов как правило, можно выбрать тип работы как "абсолютный" или "относительный".

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

При относительном - энкодер выдает "условную +1" вправо, и "-1" влево. И параметр меняется, НЕ сбрасываясь, от некого дефолтного значения.
Условную 1, говорю, потому что с т.з кода наблюдаю 3 стандарта, приведенные на скрине.

энкодер.jpg


Все ли это так? По сути, я не могу сформировать ТЗ, если просто говорят, что "нужен бесконечный энкодер" в МИДИ контроллере. Какие дополнительные вопросы задать заказчику?
 
Коллеги, неужели никто не конструировал нечто с энкодером? Очень нужна подсказка.
 
Сам вопрос непонятен. Какая связь вообще энкодера и Миди CC? Алгоритм работы выбирается в зависимости от решаемой задачи. Встречаются разные подходы где есть энкодеры на устройствах. А физический энкодер он просто шаги отсчитывает в + и в -.
 
Я старался сформировать вопрос как мог))).... Возьмем, к примеру, reaper, т.е. софт. Создадим экшн для плавного управления неким параметром посредством подключенного внешнего МИДИ контроллера. Если на последнем стоит потенциометр выдающий МИДИ значения 0...127, то все обучается и работает адекватно. Если ставим энкодер, то можем (и так нужно), чтоб он "просто шаги отсчитывал". Рипер просит чтоб эти "шаги" были представлены как один из 3- вариантов (см скрин). Но! В виде СС#, а не просто 1 и 0. Я все это сделал и все работает тоже.

Но теперь возьмем некий "железный" приемник МИДИ, скажем синт. У него есть управление неким параметром по МИДИ в виде, скажем, CC# 0...127 . Более того, он прекрасно управляется от многочисленных МИДИ клавиатур, рассматриваемых пока как "МИДИ контроллеры",
с "бесконечными" энкодерами.

Я предположу, что "шаги" - это внутреннее "дело" такой клавиатуры, потому что на МИДИ выход вряд ли пойдут "шаги". Пойдет уже обернутое СС#. Так ли это?

Т.е. получается, что энкодер "кастомного" МИДИ контроллера для рипера должен выдавать "шаги", а брендованный что выдает?

Если бы у меня было нечто, я бы МИДИ монитором посмотрел, но... нет такого ничего.
 
потому что на МИДИ выход вряд ли пойдут "шаги". Пойдет уже обернутое СС#. Так ли это?
конечно. никакой возможности передавать "шаги" в миди протоколе нет. Выдаётся значение контроллера.
А в рипере не разбираюсь )
 
Если выдается значение контроллера, то приемное устройство не сможет "подхватить" относительное изменение параметра и установится равным текущему передатчика. Тогда теряется весь смысл применения энкодеров.
А про передачу "шагов" я не утверждал. Даже не смотря на скрин, понятно, что передаются СС#. Скажем до 63 - это шаг влево, а более - шаг вправо. Т.е. технически, можно создать алгоритм приемного устройства, которые принимает "Шаги" и не сбивается от текущей настройки.

Вопрос: почему такое не делается? Или делается?
 
Если выдается значение контроллера, то приемное устройство не сможет "подхватить" относительное изменение параметра и установится равным текущему передатчика.
Приёмное устройство может отслеживать изменения контроллера и реагировать на него как угодно. В зависимости от задумки создателя. Например, ожидать прохода контроллера через определённое значение, а дальше уже реагировать. В миди протоколе нет никаких требований к реагированию устройств, он просто передаёт данные, медленно и тупо. )
 
Если выдается значение контроллера, то приемное устройство не сможет "подхватить" относительное изменение параметра и установится равным текущему передатчика. Тогда теряется весь смысл применения энкодеров.
А про передачу "шагов" я не утверждал. Даже не смотря на скрин, понятно, что передаются СС#. Скажем до 63 - это шаг влево, а более - шаг вправо. Т.е. технически, можно создать алгоритм приемного устройства, которые принимает "Шаги" и не сбивается от текущей настройки.

Вопрос: почему такое не делается? Или делается?
в вашей картинке по риперу явно описана "конвертация" миди сообщения СС в "шаги" - ведь "+1" и "-1" это явно шаги а 127 и 1 это явно значения СС
 
Пока я ответов ваших не понял. Что значит "как угодно", "задумка создателя"? Есть девайсы и все работает. В части сабжа нет особых разночтений. Пусть описана "конвертация"- я не против))) Вопрос же в другом.

Вот одно предположение: если юзается двунаправленный МИДИ интерфейс (а такой чаще всего), то приемник может передать текущее положение параметра в передатчик, и последний уже начнет формировать абсолютный МИДИ параметр, а не относительный. "жесткий" пот это не позволит, а энкодер - без проблем. И все придет в норму.

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

Вот одно предположение: если юзается двунаправленный МИДИ интерфейс (а такой чаще всего), то приемник может передать текущее положение параметра в передатчик, и последний уже начнет формировать абсолютный МИДИ параметр, а не относительный. "жесткий" пот это не позволит, а энкодер - без проблем. И все придет в норму.

Но это догадки.
что вы не поняли? Миди вход получает миди сообщения, можно хоть миллион раз прислать миди сообщение "значение СС18 равно 127"
Далее -

1 - приходит миди сообщение - СС со значением 127 в рипер
2 - рипер смотрит что на это СС "замаплен" (связан) некий параметр автоматизации например, или другой СС (уже внутри рипера), или тот же СС (но внутри рипера)
3 - рипер берет этот параметр автоматизации\текущее внутреннее значение СС (то - которое вы там рисуете руками на таймлайне) - оно допустим 78. Смотрит на миди сообщение которое прилетело снаружи (см пункт 1) и если то что прилетело _снаружи_ имеет значение 127 то делает декремент - то есть делает 78 - 1 = 77. Если приелетело снаружи 1, то делает инкремент - то есть делает 78 +1 = 79

И я полагаю все это легко проверяется в том же рипере - просто соедините миди входы с миди выходом и шлите себе нужные миди сообщеняи и смотрите что происходит (наверянка в рипере есть соотв скрипт)

PS а ,вы даж не мне отвечали., чего я встрял то ))) Ну в общем, удачи в этом нелегком деле!
 
Последнее редактирование:
  • Like
Реакции: dim3740
В третьем своем посте я написал, что с рипером проблем нет. Фраза звучит так :"Я все это сделал и все работает тоже." Рипер - по сути это "открытий проект" и экшенами можно все сделать.

Меня интересует брендованные девайсы. У них есть MIDI Implementation. Не могли бы вы дать пример в них, где написано, как менять некий параметр так же как в рипере - путем отправки (обернутого в МИДИ формат) инкремента или декремента этого параметра?

Я припоминаю, что в неких мануалах что-то подобное было. Но найти не могу. Если вопрос в корне не верен, то попытайтесь, пжс, объяснить почему. Заранее спасибо за терпение.

К примеру, это может звучать типа data + и data- На одном форуме вопрос рассматривается в контексте NRPN.
К примеру, СС 07 - управление громкостью. Параметр 0...127. Как изменить ВНЕШНЕ на 1 , если не знаем, с каким значением он стоит сейчас? Как просто ДОБАВИТЬ 1? Ведь алгоритмически в этом нет ничего сложного.
 
Последнее редактирование:
В третьем своем посте я написал, что с рипером проблем нет. Фраза звучит так :"Я все это сделал и все работает тоже." Рипер - по сути это "открытий проект" и экшенами можно все сделать.

Меня интересует брендованные девайсы. У них есть MIDI Implementation. Не могли бы вы дать пример в них, где написано, как менять некий параметр так же как в рипере - путем отправки (обернутого в МИДИ формат) инкремента или декремента этого параметра?

Я припоминаю, что в неких мануалах что-то подобное было. Но найти не могу. Если вопрос в корне не верен, то попытайтесь, пжс, объяснить почему. Заранее спасибо за терпение.
я думаю что любая такая реализация будет исключительно специфична для данного конкретного устройства ибо в миди протоколе нет этого, не заложено.
Итого - если вас интересуют какие-то конкретные миди дивайсы - то их и надо раскапывать.
Вы же сами утверждаете что есть "некий" железный приемник который "прекрасно управляется от многочисленных МИДИ клавиатур" , цитирую

"некий "железный" приемник МИДИ, скажем синт. У него есть управление неким параметром по МИДИ в виде, скажем, CC# 0...127 . Более того, он прекрасно управляется от многочисленных МИДИ клавиатур, рассматриваемых пока как "МИДИ контроллеры", с "бесконечными" энкодерами. "

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

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

Ну и чисто косвенно - вряд ли бы рипер предлагал такой набор "костылей" если б был стандарт (путь и негласный)
 
  • Like
Реакции: dugdum®
У них есть MIDI Implementation.
В ней и кроется суть. Изучайте конкретный девайс. Они все разные.
Крайне вероятно что заказчик ждет что любой синт магически заработает с инкрементальным энкодерами (потому что на компе ж работает)
вот вот. Ему губу то придётся закатать. губозакаточную машинку прилагать к контроллеру на энкодерах )
 
Знаете, в сети есть куча проектов МИДИ контроллеров с "внешне" похожими энкодерами. Это делают кому не лень, даже новички. Честно я особо не разбирался, может стоит покопаться и списаться с авторами. Неужели они все заточены на работу как абсолютные? Удивительно)))

Хотя, моя задача ведь так очевидна и насущна! Синхронизация параметров!

Да, даже на моей портастудио приходится двинуть фейдер, что засинхрониться, но... это же фейдер. С ним все понятно.
 
К примеру, это может звучать типа data + и data- На одном форуме вопрос рассматривается в контексте NRPN.
К примеру, СС 07 - управление громкостью. Параметр 0...127. Как изменить ВНЕШНЕ на 1 , если не знаем, с каким значением он стоит сейчас? Как просто ДОБАВИТЬ 1? Ведь алгоритмически в этом нет ничего сложного.
вероятно вы читали про CC96 и CC97 (data increment \ data decrement)
не уверен как это привязать к контроллеру ибо оно меняет (+1 \ -1) значение последнего переданного RPN/NRPN
Единственное что приходит в голову это проверить привязано ли оно (изолированно) все к миди каналам, и тогда можно каждый энкодер передавать на своём миди канале. Хотя стартовое значение все равно же передать надо - и оно собьёт значение в принимающем дивайсе.

Наверное прощще записать миди что выдает подобный контроллер и покурить его чем гадать.
 
  • Like
Реакции: dim3740
ну вообще миди ассоциация говрит нам что такое вне стандарта но "рекомендует делать вот так" (прикрепил пдф)
И кажется там можно указать параметр который менять надо без значения, и потом слать сс96 и сс97 сколько надо раз для изменения.
При этом конечно нет гарантии поддержки со стороны принимающего дивайса - это рекомендация.
 

Вложения

  • rp18.pdf
    rp18.pdf
    31,9 KB · Просмотры: 4
Последнее редактирование:
  • Like
Реакции: dim3740

Сейчас просматривают