MIDI-контроллер своими руками (помогите оценить возможность реализации)

Один товарищ обратился с вопросом: «А можно ли сделать самодельный MIDI-контроллер?»
Мне идея показалась интересной, но, прежде чем потратить на нее кучу денег, хотел бы услышать ваши мнения по этому поводу. Спасибо!

Итак, задача:
MIDI-контроллер, грубо говоря, коробочка с крутилками/вертелками и кнопочками, подключаемая к ПК по USB, прикидывающаяся MIDI-устройством и отдаящая MIDI-инструкции при кручении/верчении ее элементов управления.
Вот пример заводского образца:


Тут на самом деле все просто, есть уже даже подобные решения и схемы, например, вот.

Ну и схема:


И вроде все просто и понятно, V-USB для реализации MIDI over USB, кнопочки и переменные резюки в стандартном включении.

В чем затык?
Проблема в том, что у нашей железки должно быть гораздо больше элементов управления, а именно:
  1. 16 энкодеров (именно энкодеров, переменные резисторы не подходят, по причине невозможност поменять их значения программно)
  2. 30 кнопок (+-)
  3. 1 фейдер (переменный резистор ползункового типа)
  4. Экран для вывода информации
  5. По 1 светодиоду минимум для каждого элемента управления, для индикации его работы (итого около 50)

Значит будем использовать мультиплексирование.
Я так понимаю, ни у одного МК прерываний и ног не хватит, чтобы напрямую через прерывания отловить все изменения на всех кнопках и энкодерах? Значит кнопки и энкодеры мы будем сканировать. Как я понимаю, на каждый энкодер 2 сигнала, на кнопку — 1, итого 62.
— Если использовать принцип матричной клавиатуры, то потребуется 8x8 = 16 GPIO?
— Теперь индикация, тоже динамическая. Тут 7x7 = 14 GPIO?
— 7 GPIO на экранчик (имею ввиду классический текстовый 20x4 символов, хотя, если совсем не будет хватать ног или чего-то, то можно экранчику прикрепить отдельный МК и управлять им по I2C или UART).
— 2(3) GPIO — USB
Итого получается 40+, аха за рамки обычной 40-ножки мы вышли, а значит придется использовать что-то более многоногое.

В общем, пока список вопросов примерно следующий:
  1. Справится ли обычная AVR-ка на 16 мегагерцах с поставленной задачей? (опрашивать все элементы управления, индицировать их работу, получать и передавать данные по USB в ПК)
  2. Кто какой МК посоветует для решения данной задачи? Причем не обязательно AVR, в принципе есть желание поковыряться с STM32, там как раз есть многоногие камни со скоростью выше 16 MHz и аппаратным USB. Тогда можно будет сделать еще больше индикации: не по 1 светодиоду на каждый энкодер, а по несколько, чтобы отображать позицию (как на заводском образце с картинки).
  3. Может по мультиплексированию кто что посоветует? Может есть смысл использовать сдвиговые регистры?
  4. Еще какие-то мысли? Любые идеи приветствуются!

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

В любом случае всем спасибо за помощь! Если проект пойдет — обязательно поделюсь наработками!

Update 1:
Поизучал MIDIbox (за ссыль спасибо bigdigital), они там вообще не парясь абсолютно все считывают через 74hc165 и выводят через hc595. И ничего у них не тормозит!
Единственное, что меня смутило: автор проекта перешел с STM32F103RE(B) на LPC1769, сам он мотивировал это вот как:
In the year 2011 I evaluated current microcontroller solutions again and switched to LPC1769 since it offers more features for almost the same price.
Дескать функций у него больше, за ту же цену… (еще на страницах пробегало гораздо более странное утверждение, что STM паять сложнее, чем LPC «LPC doesn't require SMD soldering and therefore is more DIY friendly!», я как понял потому, что они используют готовый модуль LPCEXPRESSO) Хм… Но я почему-то совершенно не хочу LPC…

Update 2:
На данный момент склоняюсь к варианту — «не изобретать велосипед». То есть по ссылке www.ucapps.de ребята уже разработали прошивку, которую назвали MIOS. Чем писать свою, адекватнее, наверное, использовать их (возможно с какими-то допилами). Но это накладывает ограничения как раз на железо. Чтобы не перепиливать все капитально, делать нужно по их схеме. Это схема главного блока, к которой подключаются модули дополнительные — блок-схема. Хотя модули — это громко сказано. Модули ввода — это просто платки с кучей сдвиговых регистров на вход, а модули вывода — соответственно на выход. Плюс еще модули экранов — так вот это вообще не модули, а просто сами экраны.
Да, как альтернативный вариант: заморочиться и полностью написать что-то свое. Тогда уже можно будет разгуляться и сделать всякое вкусное, вроде круглых индикаторов со спаркфана (хотя они для нашего бюджета неоправдано дороги 300 рублей, а надо 16 штук, это перебор).
Вопрос стоит так: а стоит ли изобретать велосипед?
  • +1
  • 22 января 2012, 22:18
  • JustACat

Комментарии (119)

RSS свернуть / развернуть
Теперь индикация, тоже динамическая. Тут 7x7 = 14 GPIO?
Как по мне, так сдвиговые регистры тут самое то.
Если использовать принцип матричной клавиатуры, то потребуется 8x8 = 16 GPIO?
тут тоже я б мультиплексор поставил.
Справится ли обычная AVR-ка на 16 мегагерцах с поставленной задачей? (опрашивать все элементы управления, индицировать их работу, получать и передавать данные по USB в ПК)
Ну сама по себе справится без проблем, а вот как там с V-USB и сколько она ресурсов отнимет, не знаю.
0
Ну сама по себе справится без проблем, а вот как там с V-USB и сколько она ресурсов отнимет, не знаю.
Много отнимает, очень много… Это меня и беспокоит… Причем при этом мы в итоге получаем самую медленную реализацию USB (которая на некоторых современных хостах вообще отказывается определяться).
Поэтому сам я пока склоняюсь к STM32 с аппаратным USB (да, AVR-ки с усб тоже есть, но их достать мне куда сложне, да и зачем?).

Про сдвиговые регистры можно поподробнее? То есть существуют ведь варианты, например, тупо ставим в цепочку подряд 7 сдвиговых регистров на 8 ног каждый, получаем 56 ног из 3 — это 1 вариант, другой вариант: 2 свдиговых регистра (по 8 ног) + 4 (например) ноги динамически, итого 7 ног тратим, 4*2*8 = 64 получаем.

Я как раз реализовывал тут недавно проект с бегущей строкой (есть тут статья), там для светодиодов использовался такой вариант: сдвиговые регистры на строку, их там было 12 (x8=96) и 8 строк динамически. Там скорости хватило, но там не было никаких USB при этом… Данные брал с SD карты. А вот USB, как мне кажется, как раз решает…
0
Про сдвиговые регистры можно поподробнее? То есть существуют ведь варианты, например, тупо ставим в цепочку подряд 7 сдвиговых регистров на 8 ног каждый, получаем 56 ног из 3 — это 1 вариант, другой вариант: 2 свдиговых регистра (по 8 ног) + 4 (например) ноги динамически, итого 7 ног тратим, 4*2*8 = 64 получаем.

Ну первый вариант мне однозначно ближе… зачем парится из-за уменьшения количества копеечных регистров? Цепочкой — как-то оно легче. Хотя, смотрите сами.
0
Ммм, ну опять же скорость опроса — это раз, ну и удобство разводки опять же, хотя тут я могу ошибаться, может с цепочкой свиг-регистров оно и проще будет…
0
Да скорости с головой будет, даже заметно не будет. Некоторые по сдвиг регистрах умудрялись даже и яркость десятков светодиодов ШИМом регулировать.
0
цепочка регистров однозначно справится. Данные можно толкать по SPI с DMA, если делать на STM32. Тогда еще и куча ресурсов остается свободными. У меня по такому принципу панель управления работает. Обрабатывает 48 кнопок и 56 светиков и 5 семисегментников.
0
Отлично, спасибо за подтверждение — очень прибавляет веры :)
0
Я бы посоветовал посмотреть, как вариант, port extender-ы I2C или SPI (на вскидку 16-разрядные PCF7475 — I2C, MCP23016/MCP23S16 I2C/SPI соответственно). По сравнению со сдвиговыми регистрами они имеют возможность самостоятельно детектить прерывания. Ну и экранчик лучше сразу делать I2C или SPI, можно на том же експандере, а кнопки организовать в матрицу, тогда пары портов хватит на все кнопки. Как вариант для индикации можно использовать графический дисплей со встроенным SPI (такой режим есть у очень многих контроллеров, на глаз — минимум у половины). Такой дисплей часто стоит дешевле, чем текстовый, например вот. На атмегу такое цеплять может быть несколько накладно по памяти, а на STM-ку — без проблем.
0
На данный момент склоняюсь к варианту — «не изобретать велосипед». То есть по ссылке www.ucapps.de ребята уже разработали прошивку, которую назвали MIOS. Чем писать свою, адекватнее, наверное, использовать их (возможно с какими-то допилами). Но это накладывает ограничения как раз на железо. Чтобы не перепиливать все капитально, делать нужно по их схеме. Это схема главного блока, к которой подключаются модули дополнительные — блок-схема. Хотя модули — это громко сказано. Модули ввода — это просто платки с кучей сдвиговых регистров на вход, а модули вывода — соответственно на выход. Плюс еще модули экранов — так вот это вообще не модули, а просто сами экраны.
Да, как альтернативный вариант: заморочиться и полностью написать что-то свое. Тогда уже можно будет разгуляться и сделать всякое вкусное, вроде круглых индикаторов со спаркфана (хотя они для нашего бюджета неоправдано дороги 300 рублей, а надо 16 штук, это перебор).
Вопрос стоит так: а стоит ли изобретать велосипед?
0
Понятное дело, что выбор за вами. Я просто постарался дать дополнительную информацию/варианты решения.
0
Это конечно, и за это вам отдельное спасибо! :)
0
Чтобы не перепиливать все капитально, делать нужно по их схеме.
А вот это не обязательно. Назначение пинов в линейке регистров в проектах прописывается в дефайнах. В своем прототипе натыкал кнопок да энкодеров как попало, подправил файлик и в путь. Это в проекте MIDIbox LC. MIOS — не просто прошивка, это некое подобие оси. Т.е. программатором грузишь загрузчик, по MIDI (на PIC платформе, на STM может быть можно и через USB, не знаю точно) заливаешь саму MIOS, которая во всех проектах одна и та же, потом, опять таки по MIDI, заливаешь нужный проект. Чтобы поменять проект, например с MIDIbox LC на MIDIbox 64, достаточно перезалить сам проект, ось остается на месте. Это из того, что я пробовал.
0
Назначение пинов в линейке регистров в проектах прописывается в дефайнах.
GPIO да, но всякие аппаратные SPI — они же на определенных пинах…

С мидибокс конечно еще разбираться и разбираться! Но это лучше, чем когда приходится разбираться на пустом месте.
0
Дефайны описаны в формате «Регистр №, Пин №»
Вот фрагмент, описывающий энкодеры:
MIOS_ENC_PIN_TABLE
	;; encoders 1-16
	;;        SR  Pin  Mode
	ENC_ENTRY 13,  0,  MIOS_ENC_MODE_NON_DETENTED	; V-Pot 1
	ENC_ENTRY 13,  2,  MIOS_ENC_MODE_NON_DETENTED	; V-Pot 2
	ENC_ENTRY 13,  4,  MIOS_ENC_MODE_NON_DETENTED	; V-Pot 3
	ENC_ENTRY 13,  6,  MIOS_ENC_MODE_NON_DETENTED	; V-Pot 4
	ENC_ENTRY 14,  0,  MIOS_ENC_MODE_NON_DETENTED	; V-Pot 5
	ENC_ENTRY 14,  2,  MIOS_ENC_MODE_NON_DETENTED	; V-Pot 6
	ENC_ENTRY 14,  4,  MIOS_ENC_MODE_NON_DETENTED	; V-Pot 7
	ENC_ENTRY 14,  6,  MIOS_ENC_MODE_NON_DETENTED	; V-Pot 8

	ENC_ENTRY 15,  0,  MIOS_ENC_MODE_NON_DETENTED	; Jog-Wheel
	ENC_EOT
 

Это, конечно, касается распределения периферии по регистрам, но если вам хочется поменять назначение ног самого камня, то это изменяется в исходниках самой MIOS. Вот только зачем изменять само ядро, когда оно в имеющемся виде решает практически все задачи. Эти ноги на регистры ввода, эти ноги на регистры вывода, эти — LCD, эти — аналоговый ввод, эти — MIDI порт. Тут менять что либо не вижу смысла. А обвес кнопками, индикацией и т.п. можете разрабатывать как Вам нужно. Тут уже все гибко.
0
Так, что-то я тут смотрю и вижу, что энкодеры напрямую к ногам, а как же сдвиговые регистры?.. Или в PIC они без регистров сдвиговых делали? Хотя это все детали, согласен.
0
Это не ноги контроллера, это ноги регистров. SR — номер регистра в цепочке, PIN — разряд регистра.
0
А слона-то я и не заметил :) Затупил да :)
0
В догонку — если поизобретать хочется, то изобретайте. Это хороший опыт. Но Вас ждет хороший геморрой с глюками, придется тщательно изучить протокол MIDI (вопрос — понадобится ли Вам именно этот опыт в дальнейшей практике?), полезут ошибки, допущенные на ранних стадиях проектирования. А Вашего товарища могут закидать помидорами, когда на дискотеке это чудо глюкнет.
Если нужно просто собрать рабочее устройство — используйте наработки MIDIBox. Причем вовсе не обязательно сдирать все один к одному, почитайте исходники — там все неплохо конфигурируется.
Обратите внимание на проект Traktorizer www.midibox.org/dokuwiki/doku.php?id=traktorizer_by_mte Исходник он правда просто так не дает, но мне это обошлось ровно в 1 евро, а поизучать там есть что, тем более что он реализован на С. Это неплохой пример, как совместить сишный проект с асмовой осью.
0
Поизобретать, не то чтобы хочется, по крайней мере писать с ноля то, что уже работает — не вижу смысла.
Но у человечка, который это все хочет получить, есть некие специфические запросы, в которых я не уверен — есть они в мидибокс или нет (например, ему понравилась идея иметь сенсорный экран небольшой, как элемент управления каким-то определенным параметром)… Я попробую его сюда самого подключить, он у вас поспрашивает, вы ведь не против?
0
Сам болею этой тематикой, так что чем смогу — помогу.
0
Я делал MIDIBox64. Использовался он для управления светом на концерте (в связке с DMXControl). Сейчас еще переделал его в простенькую DMX-консоль на подобии этого: www.midibox.org/dokuwiki/doku.php?id=midiboxdmx
0
Вместо енкодеров лучше использовать резисторы переменные, и дешевле будет и проще мультиплекстровать. Кнопки на 74HC165 садятся и опрашиваются. Вообще стоит постмотреть на проект www.ucapps.de/ там и AIN(analog input) DIN(digital input).
0
От переменных резисторов отказались по простой причине: необходима обратная установка, то есть с ПК приходит сигнал — мол вот на 5 крутилке сейчас значение 25. Переменные резисторы бывают моторизованные да, но стоят жутко дорого…
За ссылочку спасибо, будем посмотреть!
0
Тогда Вам еще и шкалу нужно для каждого переменника? о_О
0
В идеале да, что-то такое: www.ucapps.de/midibox16e.html
Но если это совсем не будет выходить, то можно будет и без нее — выводя шкалу на экранчик именно по тому энкодеру, значение которого в данный момент регулируется.
Либо использовать пару крупных экуранов и на них выводить значения всех энкодеров. Примерно как тут: www.ucapps.de/midibox_seq.html
0
Как по мне, вариант со светодиодами интересней, да и информативней. Разве что паять из запаритесь да и дырки сверлить…
0
Вот-вот :) Есть еще одна составляющая: на светодиоды не выведешь название крутилки, то есть название параметра, который эта крутилка в данный момент регулирует
0
IMHO, что-нибудь вот такое для этих целей лучше всего.
0
АААААА(очень громко)! Какое классное кольцо! Вот только ценник… Все-таки буду из SMD-шек лепить.
0
Вот, у меня мысли были точь в точь :)
0
Вот тут, вроде как, почти вдвое дешевле. Специально не искал, случайно на глаза попалось, так что может и еще дешевле есть.
0
Да, надо будет поискать, на повестке дня как раз составление прайса со всеми необходимыми запчастями и вариантами, где и почем их можно взять. Спасиб!
Может и энкодеров на ебаях заказать, хм…
А может кто знает, где в Питере хороших недорогих энкодеров можно найти? ;)
0
Ссылка очень интересная оказалась! Как минимум там много реализованных проектов со схемами для примеру! Спасибо!
0
ну тут я думаю лучше сдвиговые регистры использовать. Или расширители портов. Можно будет значительно сэкономить ножки.
А по поводу софтового ЮСБ есть некоторые сомнения, хватит ли ресурсов или нет. Конечно лучше будет взять АРМ с аппаратным ЮСБ, тогда сразу имеются широкие возможности для добавления фарша.
И по поводу экранчика, можно сразу не мелочиться, а взять цветной небольшой. Они сейчас недорогие. Будет выглядеть модно и молодежно. Например такой www.ebay.com/itm/200554112312?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649. управляется по SPI, тоесть подключить на те же ноги, что и сдвиговые регистры, в итоге экономим ноги.
0
Да, вот и меня софтовый УСБ больше всего смущает… Пока думаю в сторону использования чего-то вроде вот такой вот готовой железки в качестве мозгов: www.ebay.com/itm/STM32F103RBT6-development-board-2-8-TFT-module-true-color-touch-screen-/330618886100?pt=LH_DefaultDomain_0&hash=item4cfa6bd7d4 Стоимость нормальная как раз, и уже есть экранчик.
0
вполне хорошая вещь. Да и АРМ сейчас на коне, есть смысл его изучать. easyelectronics.ru/podklyuchenie-klaviatury-k-mk-po-trem-provodam-na-sdvigovyx-registrax.html вот кстати про подключение кнопок через сдвиговые регистры. Только в статье они не особо удачно выбраны, ниже в комментариях (когда их вернут) писали какие лучше подойдут (с параллельным входом, последовательным выходом и защелкой)
0
Ага, спасибо за ссылочку! Я эти статейки (те, что на ee и на we про мультиплексирование) уже пробегал (ранее, до возникновения данной задачки, хотя не уверен, что все, возможно какие-то пропустил), и конечно буду снова перечитывать и не один раз. Как тут уже с VGA мы заметили, проблема в том, что мультиплексирования для данного вида устройства в любом виде не есть гут… Так что может придется брать более многоногий МК и использовать его ноги по полной без мультиплескирования ввода (вывод конечно однозначно мультиплескировать).
0
В STM32F103RBT6+2.8«TFT:
— i80/16bit на дисплей в режиме 16bit: 21 пин
— SPI на карту памяти и контроллер TouchScreen: 7 пинов
— USB: 3 пина
— кварцы: 4 пина
— 2 кнопки + 2 светодиода: 4 пина
— переменный резистор: 1 пин
Итого: занято 21+7+3+4+4+1 = 40 пинов. А у STM32F103RB всего-то 51 GPIO. Так что в сухом остатке 11 пинов на клаву и средства индикации.
0
AFAIK, не все из этих пинов — GPIO. Кварцы например. Да и не нужно два кварца миди-контроллеру, а на платах обычно предусматривают возможность ненужную периферию оторвать. Кнопки с СИДами — туда же.
К тому же, часть пинов можно мультиплексировать. Шину данных дисплея, например (правда тогда кнопки/диоды от нее придется отвязывать буфером или регистром).
Но лучше все же STM32F102VBT6.
0
Выводы для кварцев в STM32 после RESET выполняют роль обычного GPIO. На них назначена единственная альтернативная функция — выводы кварцев. Альтернативная функция для таких «выводов кварцев» активируется в коде прошивки ПРОГРАММНО и НА ЛЕТУ, а не задаются Fuse-битами, как в AVR.

Интересующимся предлагаю самостоятельно ознакомиться со схемой модуля MINI-STM32-V3.0 MINI-STM32-V3.0, ссылка на которую была приведена товарищем JustACat.
MINI-STM32-v3.0
0
Чем в таком случае остальные 13 пинов заняты? Не одним же питанием?!
0
Картинка получилась неточная. По запросу могу выслать pdf со схемой этого модуля.
0
На самом деле я тот конкретно модуль привел исключительно для примеру, ткнул пальцем в первый более-менее адекватно стоящий :) То есть естественно сначала я буду оценивать, сколько точно надо будет GPIO, и сколько их есть в том или ином модуле, и только потом брать, если подойдет.

Ну и как я уже оценил по проекту МИДИбокс — выводов много и не потребуется, у них там вся индикация и все кнопки идут через сдвиговые регистры, так что GPIO для этого дела понадобится минимум. Нужно будет только взять камушек лучше с парой аппаратных SPI. Ну и там может даже SDIO получится использовать, карту памяти с пресетами прикрутить…

Отсюда как раз было бы не плохо посмотреть на схему того (и может других) готового модуля, если они у вас есть, так что выложите, пожалуйста, если вам не трудно. (Можно на дропбокс какой-нить или files.mail.ru, не так важно.)
Спасибо!
0
STM32F103 все идут с парой SPI. В качестве стартового варианта, на мой взгляд, стоит посмотреть схему Olimexino. Понятно, что что-то придется допилить, а что-то выбросить, но база там есть, в том числе SD.
0
Ну, в общем, стандартный обвес для подключения всякого разного :) Спасибо, схемку сохранил.
0
Дисплей подключается по SPI и на него уйдет +1 нога от того же SPI, на котором висит тач. Видео тут крутить не надо, а для гуя/индикации SPI более чем. Если сам дисплей аппаратно такое не умеет, ничего не мешает подключить его через експандер или те же сдвиговые регистры. Это, конечно, если самому схему рисовать. Если брать готовое, то, естественно, придется танцевать от того, что есть.
0
Если есть образец этого миди контроллера то имеет смысл вскрыт ьего и посмотреть как нафаршировали, конечно вполне возможно там окажется ASIC какая-нить, но может и более универсальное решение
А вообще 16 энкодеров это больше уже плис, контроллер мне кажется такого не выдержит
0
К сожалению вскрыть нечего :( Если бы оно было, было бы проще конечно…

А вообще 16 энкодеров это больше уже плис, контроллер мне кажется такого не выдержит
Вот это несколько печалит…

Гуру мультиплексирования, отзовитесь! Кто выскажется? Хватит ли, например, 72 мегагерцовой STM-ки, чтобы обработать 16 энкодеров с кнопками и прочим фаршем? Это, наверное, главый вопрос на повестке дня…
0
Не только хватит, она еще и 99% времени в цикле ожидания крутиться будет.
0
Спасибо! Отлегло! В данном случае пусть лучше будет с запасом, задачи ужать в самый маленький МК не стоит! Есть задача уложиться в бюджет, но STMки ведь не фиг и дорогие, как я поглядел…
0
PIC18 на 10MHz 8 штук энкодеров тянет, да еще кучу всякого дополнительно. Внимательно просмотрите вышеприведенную ссылку по Мидибох — там все есть. Проект интересный, сам пытаюсь собрать, на прототипе пару дискотек отработал. Это на Пике. А STM32 — вообще бомба. Главное достоинство этого проекта — серьезные наработки по софту. MIOS — достаточно отлаженное решение. И не нужно изобретать велосипедов.
0
Отлично! За опыт отдельное спасибо! Да, про мидибокс я понял уже, что ребятал серьезно подолши к делу, обязательно буду его изучать!
0
Тут и древнй АТ89С2051 на своих 12мгц справится с энкодерами. Они же человеком будут крутиться и у них там будет не тысячи импульсов на оборот, а максимум десятки.
0
Ммм, вообще да, 12 или 24 импульса вроде на оборот…
0
… если есть время то можно поставить tft+touch screen, на нем можно нарисовать хоть 50 кнопок и энкодеров, ползунков и т.п., красиво и современно, правда на разработку GUI уйдет некоторое время. 16МГц для tft хватит, плюс около 25 пин для tft+touch panel
0
но для мидиконтроллера тачскрин неудобно будет. Для таких дел нужны хорошие тактильные ощущения от реальных кнопок и крутилок.
0
Смотрим www.youtube.com/watch?v=vaiRLpuwDZ0&feature=related
Ничего не стоит на месте.
0
все дело в реализации) это далеко не резистивный тачскрин на 3.5 дюйма)
0
Полностью уйти от хардварных элементов управления — не выйдет. Они нужны именно хардварные :) Иначе бы использовали просто ПК с сенсорным экраном :) Это как предложить человеку вместо синтезатора железного использовать оный на айфоне :) Идея конечно правильная, но тут весь смысл именно в реальных кнопках и крутилках.
0
Светодиодную индикацию — однозначно мультиплексировать. Можно чарлиплексинг, он эффективней матрицы (N ножек позволяют управлять N*(N-1) светодиодами).
С вводом чуть хуже. Большинство вариантов мультиплексирования кнопок могут давать ложный результат при нажатии нескольких кнопок одновременно (это, например, весьма характерный случай для игровых контроллеров). Так что тут есть смысл использовать регистры или многоногий МК.
Если еще и ставить пальцатый экранчик (TFT, возможно без контроллера), то определенно есть смысл делать на основе STM32F102V* (если я не ошибся и LQFP100 кодируется как V). Там есть FSMC для экрана, аппаратный USB для интерфейса и туча GPIO для ввода.

А обработать 16 энкодеров не так уж и сложно. Кто-то (ЕМНИП neiver) уже писал статью по этому поводу, ЕМНИП еще на easyelectronics.ru.
0
  • avatar
  • Vga
  • 22 января 2012, 23:08
Да-да, про чарлиплексинг помню, название больше всего запомнилось :)

Про ввод правильно заметил, тут конечно бы надо, чтобы он на всех элементах одновременно улавливался, ибо это не клавиатура кодового замка, а музыкальный инструмент таки…
Но если совсем без мультиплексирования, даже на 100 ногом ног не хватит, хотя… Хм… 16x2 + 30 = около 60 ног… Может и хватит.

Спасибо, поищу!
0
при мультеплексировании или без разница будет идти на микросекунды, не думаю что они станут критичны. Энкодеры темболее менее критичны ко времени отклика. К примеру прикинуть за какое время получится сосканировать 4 сдвиговых регистра, на которых сидят кнопки. Потом решить как часто это можно делать, чтоб не сильно грузить проц, и какое нужно время отклика, и там, я уверен, получится очень большая частота сканирования, что стока и не надо.
0
Чтож, думаю, копать надо изначально частоту максимальную работы сдвиговых регистров, с какого бы регистра начать только, их же море :) Хотелось бы что-то широкораспространенное и не супер-дорогое… И паябельное (можно и SMD но не шибко микро)…
0
74HC597. Даташит говорит, он умеет частоту 96 мегагерц. www.allcomponents.ru/search.htm?t=part&s=74HC597&m=0
0
Ну если 96 мегагерц О_о
0
Да в любом случае частоты для кнопок Вам с головой, лишь бы контроллер успевал опрашивать, там счет на нс. идет.

Из сдвиговых — посмотрите на 74HC595, их полно в дипе и соике, кроме того у них еще кажется и защелки есть…
0
Они еще и в наличии у меня есть ;)
0
так ведь 595 они с параллельным выходом и последовательным входом. Для выхода на диоды пойдут, а на кнопушки нет
0
Дак я про вывод и имел в виду.
0
Тогда 74hc165? Parallel to Serial тоже есть несколько штук…
0
ага. но у них частота чуть ниже. Если программно SPI реализовывать, то нужно будет задержки между тиками ставить небольшие. Но эт не критично, скорости для опроса и так за глаза хватит.
0
Вообще, есть у меня джойстик — Logitech Wingman Extreme 3D Pro (скромностью маркетологи их не страдают, это точно...). В основе — какой-то из CY7C6800x ног на 20, и это на 4 оси, 12 кнопок и Hat (еще 4 кнопки). Схему я правда не снимал, но там явно какое-то мультиплексирование кнопок с диодами, но ложных срабатываний не дает, четко определяет кнопки, даже если все зажать.
Полагаю, впрочем, что схема достаточно проста. Суть в том, что делаем обычную немультиплексированную клавиатуру (т.е. один общий и по одному проводу на кнопку), но вместо кнопки включаем конструкцию из двух встречно-параллельно включенных диодов с кнопкой последовательно с каждым, т.е. на каждую линию будет по две кнопки. Правда, в этом варианте общую линию тоже придется заводить на GPIO. Дальше все довольно просто — общий на 0, остальные подтяжкой к 1, сэмплируем половину кнопок. Затем общий на 1, остальные подтяжкой на 0, сэмплируем вторую половину. Благо STM32 умеют тянуть подтяжкой в обе стороны. Хотя, можно и с односторонней подтяжкой извернуться, только потребуется или еще один вывод и куча резисторов (внешняя подтяжка на GPIO, который и будет задавать ее направление), или большая длительность сканирования (общий на подтяжку вверх, поочередно на одну кнопку выдаем 0, на остальные на Z, по уровню на общем можно определить состояние этой кнопки) — последним методом вроде даже на стандартных квазидвунаправленных GPIO 8051 сканировать можно без дополнительных внешних элементов.
0
Хм, таки да, я все же думаю STM32. У меня тем более пришел STM32F4 дискавери, значит надо его заюзать. Заодно поучиться, он ведь от F3 не должен сильно отличаться, если я правильно понимаю их политику…
0
Ну или на худой конец сделать отдельно отсылание мегой8 и опрос всего остального одной или двумя мега16 и передавать в первую уже переваренную инфу.
0
  • avatar
  • wowa
  • 22 января 2012, 23:37
Да, тоже как вариант, лишь бы ничего не томозило бы… Без опыта трудно судить о таких вещах :) Я когда делал бегущую строку, пока ее не сделал, до последнего думал, что не хватит вычислительных способностей, но елки, хватило же :)
Потому и обратился за советами, чтобы те, кто пробовал, отписался, что выходит, а что нет.
0
В таком варианте, имхо, тормозить не должно, тут грешить можно только на В-ЮСБ, но это уже вопрос к знатокам сей библиотеки. Кстати, да, этажерка из контроллеров это изврат, в промышленном понимании, но для одноразового девайса поможет сэкономить кучу время.
0
Уважаемый, JustACat, у меня есть некоторые наработки на счет MIDI контролера и на ардуно делал и на LPC кстати говоря там как раз на ucapps есть варианты с энкодерами подключенными через регистры не знаю как на счет 30 но десяток точно можно подключить и плюс LPC справиться и с 30. Лежит у меня и STM дискавери можно и на ней попробовать.
Вообщем если что пишите мне на мыло Michaelwork@mail.ru можем подумать вместе.
0
Да, я уже поизучал схемы на ucapps, и там прямо видно, что все абсолютно вводы выводы идут через сдвиговые регистры, и все у них работает без затыков.
Я сейчас в раздумьях: закупить у них плату основного модуля или полностью все самостоятельно собирать… Если закупить у них и подключать все по их схемам, то можно будет использовать MIOS. И вот тут как раз интересно — что она из себя представляет, и подойдет ли она для человека, которому все это я и собираюсь делать.
Замечательно, что хотите помочь! Буду иметь ввиду! Пока из вопросов в основном стоит вопрос выбора платформы. Вроде как решил, что STM, осталось решить какой :) Для подключения кнопок и светиков hc165 и hc595.
0
Можно посмотреть в сторону PCF8574 — Remote 8-bit I/O expander for I2C-bus. Есть у нее такая фишка, как генерирование прерывания при любом изменении лог. уровня на любом из входов. Тогда отпадает необходимость в постоянном опросе энкодеров и кнопок. Читаем состояние входов всех PCF8574 по прерыванию. Проверял — 2 шт. PCF8574 на 2 энкодера + 1 кнопок. Ну и гляжу на наборчик сэмплов от NXP. Тут есть PCA9675 — практически тоже самое но на 16 I/O и I2C до 1 МГц. Итого для 16 энкодеров + 30 кнопок — 8 шт. PCF8574 или 4 шт. PCA9675. А со стороны МК 3 ноги — 2 на I2C, одну на внешнее прывание. Ну и светодиоды можно к таким же микросхемам по той же I2C подключить. Вопрос только в цене…
0
Очипятка: Проверял — 2 шт. PCF8574 на 2 энкодера + 10 кнопок
0
Спасибо за информацию, да, посчитаем цену, посмотрим. Но что-то мне кажется, стоить они будут куда дороже 20 центов за штучку… :( Хотя гляну — вдруг ошибаюсь.
0
Сейчас в разработке контроллер с 8 потенциометрами и 16 кнопками на меге16.
Как обладатель контроллера с энкодерами(m-audio axiom), не стал бы рекомендовать ставить их по весьма простой причине — чтобы изменять значение в более-менее широких пределах, нужно долго крутить, а это не прикольно.
0
Как я уже писал, у резисторов есть нерешаемая проблема: невозможно задать на них значение программно. То есть не получится обратного управления с ПК. А оно нужно.
С другой стороны решение вашей проблемы я вижу такое: программно можно реализовать несколько режимов реакции на энкодер: точный 1 пульс — 1 деление переменной, быстрый 1 пульс — 10(100) делений переменной. Переключать режимы кнопочкой специальной, либо даже хитрее как-то, в зависимости от скорости вращения энкодера, например.
0
Проблема вполне решаемая. MIOS поддерживает моторизированные поты и фейдеры. Оно ядро на PIC — 8 шт. STM-ка, ЕМНИП, может больше. Круто выглядит, когда ручки сами крутятся и фейдеры сами ползают :). СтОят правда они дорого. ALPS моторизированный около 15 баксов, что очень печально, когда хочешь консоль на десяток фейдеров забацать.
0
Дак да, нас именно цена и остановила, а так, конечно было бы круто моторизованные — вообще такой бы вау-эффект был дополнительно!
0
Да вообще-то не дороже выходит, чем эти колечки светодиодные лепить)
0
Дак мы и не собираемся поэтому их лепить ;) Вместо них пара длинных экранов вдоль энкодеров. Дешево и сердито.
0
А что колечки? Если готовые по 9 баксов — то да. А если колечки самому сработать? В Мидибоксе 11 штук 0805 светодиодов на кольцо + энкодер за 2 бакса. До пятнашки не дотягивает. Кроме того на мотофейдеры еще и драйвера лепить нужно. Они простенькие, но их тоже нужно из чего-то слепить. Поэтому, если параметр меняется не только оператором но и программой, то тут экодер + кольцо = самый дешевый вариант.
0
Не уверен, что меня хватит на сработать самому 16 колечек хотя бы по 8 светиков… Заколебусь…
Так что вариант с парой экранов длинных все же предпочтительнее. Да и универсальнее — на экраны можно и названия вывести, и может что-то еще. Но колечки, если красивые — это конечно очень прикольно.
0
Не вижу большой проблемы ссамодельничать их. Вот фрагмент моей разводки.

Правда в железе он реализован не был — переделываться будет. Концепция дизайна, понимаете, меняется постоянно (т.е. сам хрен знаю чего хочу) :)))).
По центру — отверстие под вал энкодера. СИДы — 0805. 11 штук — кольцо + 1, сверху, на индикацию «центра». Хотя можно и другое применение ему найти. Маска обязательна, это меня на том этапе и тормознуло.
Достоинство кольца — легкость считывания и наглядность. Задолбается DJ заглядывать в экранчики и выткать «а минус сколько децибел у меня сейчас низкие?». А название трека на LCD выводить — это еще и хост-программа должна поддерживать. Для VirtualDJ API вроде есть, чтобы фишки контроллеров самому прописать можно было. Но это еще программирование, соответственно баги, да уже не в контроллере, а в самой проге. Опасно это, публика не поймет. Да и зачем дублировать то, что и так хорошо видно на мониторе компа?
0
Мне на самом деле трудно судить — я не але с этим всем… Но товарищ тот обещал подтянуться :)

А по железу — трудновато это будет для меня и вытравить и запаять (на моем счету пока что только с десяток резисторов паяльником криво ито 1206). Для себя бы — да, а тут деньги не мои будут, попорчу сиды, из своего карману отдавать? :) Короче есть риски определенные, когда не для себя делаешь.

Предложу конечно товарищу, а там пусть сам решает :)
0
трудновато это будет для меня и вытравить и запаять
Вот и потренируетесь :) Глаза — боятся, руки — делают. Фоторезистом такая плата делается на-раз. А денег обычные индикаторные СИДы стоят фигню.
0
176 светиков только для энкодеров (+30 на кнопки)… О_о 25 регистров!
Не знаю, не знаю… Для меня это будет подвиг, если я такое совершу… Да и что-то начинает смущать, заработает ли оно…
0
Запаять за вечер можно, ну за два. Главное анод с катодом не перепутать. При нормальной плате и аккуратной сборке — заработает, там не работать нечему.
0
Вдогонку. Хотя, такой проект с кондачка не сделаешь. Проект серьезный. Я свой уже лет 5 до ума довести не могу. Тут и паять и программить нужно. А корпус? А если товарищ Ваш будет сроки назначать — сразу отказывайтесь и делайте потихоньку для себя.
0
Мы с другом тоже задумали сделать MIDI- контроллер. Обрабатывать все будет мега16, горсть сдвиговых регистров, горсть мультиплексоров.
40 переменных резисторов, 25 кнопок, 30 светодиодов. Схему я продумал, где-то валяется, осталось доформулировать ТЗ к программе, и сесть и дописать все :) (Друг — творческая натура, за раз ТЗ не мог написать)) В связи с сессией проект заморозили…
0
Да, я и привел схему в описании — это как бы то, что первое на ум приходит.
Но как я уже сказал, у обычной авр-ки с усб скорее всего будут проблемы…
А если туда навесить еще кроме кнопок и светиков экраны, карту памяти, может еще какие-то плюшки — аврка просто не вытянет усб.
А нам надо именно усб, универсальное устройство, которое подключить можно будет к любому ПК и оно без дров заведется.
Надеюсь, у вас тоже все получится, и вы поделитесь опытом — написав статейку! Буду рад поизучать!
+1
Можно задать тупой вопрос — а что такое MIDI-контроллер? Я музыкант, у меня есть MIDI-клавиатура, позволяющая вводить непосредственно ноты. А что вводит этот MIDI-контроллер-то? Значения ползунков? Это прям в реальном времени надо?
0
Цитирую ответ товарища, из-за которого весь сыр бор:
MIDI — это очень древний способ передачи сигналов со всех этих крутилок вертелок на комп или синтезатор. Медленный и далеко не совершенный, потому что придуман много лет назад для пятипиновых разъемов. К тому же приходилось для передачи обратно использовать второй кабель. В общем геморой, я сильно в это не углублялся. Когда придумали USB стало удобней это все подключать, но стандарт остался, потому что внедрен повсеместно и невозможно уже разом перейти на что-то новое.
Миди клавиатура тоже миди контроллер. Она, например, может передавать разные данные о нажатии клавиш. Высоту тона, силу нажатия, послекасание. Есть много типов этих контроллеров и очень специфичных для передачи разных значений. Кроме кнопок можно использовать джойстики, тачскрины другие сенсоры.
Как-то так. :)
* понятное дело не только на комп или синтезатор, на секвенсоры и любые другие музыкальные устройства.
0
Очень удобно с Sonar-е к конкретным регуляторам и кнопкам привязать MIDI-события и рулить этими параметрами при помощи железных органов управления. Особенно при realtime работе. Попробуйте мышкой вывести несколько фейдеров одновременно :). А железка дает эту возможность.
www.youtube.com/watch?v=IQy9xxHAL04 — обзор одного из
0
Ммм, а вот так вы на своей миди-клавиатуре сможете:

Если да, то я молчу…
0
Как раз такое, при определенной сноровке на миди клаве сработать можно. Тут в основном — Note On/Note off. Миди клава на этих событиях еще и Velocity даст, в отличие от этих консолей. А так — регулируемых параметров я тут особо не заметил, да и большинство миди клав имеют несколько аналоговых контроллеров. Например вот эта: www.youtube.com/watch?v=oy_w5nahz0U
0
Мне на самом деле просто видео понравилось :) А велосити вроде есть на ланчпадах… А может и нету — не в курсе.
Миди клава ноты вкл/выкл даст, а вот быстро переключаться между банками, тут же на лету редактировать не знаю как это на музыкальном — когда несколько звуков в определенной последовательности повторяются. И вообще, можно и удобно — все же не одно и то же.
Хотя есть миди-клавиатуры с кучей вертелок и даже с квадратиками этими сенсорными — биты набивать, но ведь это уже не совсем миди клавиатура, а гораздо больше.
0
Там все NoteON/Off. Банки уже сам аблетон у себя внутри переключает по этим командам. Такое сработать на миди клаве натыкается на главную проблему — сложно запомнить, что на какую клавишу назначил, хоть подписывай :). Но если поставить перед собой цель — то можно.
0
Если поставить перед собой цель:

PS: никаким местом не продвигаю айпады и вообще их не люблю :) А вот девушка — молодец! Если верить тому, что она все это сидя в машине на айпад записала.
0
А можно и не париться вообще и вот так сделать :]



… соглашусь, в живую крутить пластинки приятнее. :]]
0
Как говорилось, из-за меня весь сыр бор :) у меня обратная ситуация. Я хорошо понимаю это с музыкальной точки зрения, но плохо с аппаратной и программной.
Для того, чтобы определиться с конструкцией, хочется понять возможности MIOS. Я прочитал список функций, действительно очень серьезная вещь и стоило бы использовать ее за основу. Хотелось бы определиться с некоторыми важными местами.
Вопросы для тех, кто использовал MIOS или знаком с MIDI спецификацией.

1) Возможно ли получать данные по миди из хоста обратно на контроллер? Если да, то какие? Я знаю, что обратно точно передаются данные записанных в миди нотах. Это функция мониторинга для синтезаторов, чтобы была возможность то, что сыграл в миди вновь услышать на своем синтезаторе. Записываешь дорожку в миди. Воспроизводишь снова и слышишь как на твоем синтезаторе будет играть программа хост уже с помощью посылаемых миди сообщений.
Вопрос сводится к тому, знает ли кто, можно ли получить обратно от хоста информацию об изменении других параметров. Типа громкости, значениях эквалайзера и т.д.

2) можно ли получить с помощью MIDI из хоста информацию о названии изменяемого параметра? Чтобы была возможность на экранчике отобразить что-то вроде Ins1-eqfreq1.
0
  • avatar
  • HRON
  • 26 января 2012, 20:24
Возможно ли получать данные по миди из хоста обратно на контроллер?
Да, если хост их умеет посылать. В противном случае мотофейдеры смысла бы не имели. Как заточить под это тот же сонар я сам еще не разбирался, но ролики по ссылкам подтверждают возможность.
www.youtube.com/watch?v=-el6m8BNeVo
www.youtube.com/watch?v=KjXhrcWSaKU

можно ли получить с помощью MIDI из хоста информацию о названии изменяемого параметра?
О названии параметров должен знать MIDIBox. И отображением на экране занимается он же. Т.е. прикидываем список параметров и присваиваем им № канала/ № контроллера; в проекте прописываем какие железки будут рулить каждый конкретный параметр; настраиваем отображение на дисплее так, как нам нужно. Т.е. отображение изменяемых параметров должно отрабатываться и без подключения к хосту: крутишь ручку — на дисплее отображается изменение параметра. А уже потом на хосте назначаем № канала/ № контроллера соответствующим параметрам.
Судя по желанию «отобразить что-то вроде Ins1-eqfreq1» хотите сделать что-то вроде цифрового микшера? Или, все таки, ди-джейка? Если консоль — внимательно рассмотрите проект MIDIBox LC. Там все это есть.
0
По поводу моторизированных фейдеров вполне логично, согласен. Я работаю в Cubase или Nuendo, там тоже есть эта возможность.

Судя по желанию «отобразить что-то вроде Ins1-eqfreq1» хотите сделать что-то вроде цифрового микшера? Или, все таки, ди-джейка?
скорее микшер. Но в добавок к этому я хочу управлять параметрами VST синтезаторов. Это значительно облегчит работу на этапе создания звука. Хочется реализовать функцию отображения названия параметра, чтобы эта штука была более универсальной. Представьте ситуацию, когда я делаю финальное сведение. Тогда нужно управлять несколькими эффектами и уровнем дорожек. В другом случае я подбираю нужный звук. Тогда мне нужен контроль только за параметрами текущего синтезатора и т.д. Можно много пресетов придумать. Но суть в том, что невозможно каждый раз клеить на энкодеры бумажки с подписями. Поэтому экранчики это вполне выход. Нужно только понять сможет ли он выводить эти данные на экран. Проект MIDIBox LC действительно очень похож. Он в видео управляет кажется не только громкостью треков. Нужно изучить подробней. Но я почти уверен, что это возможно. По крайней названия треков в видео у него присутствовали.
0
Понятное дело, что без дисплеев не обойдешься. Но для беглой оценки установленных уровней параметров светодиодные кольца подходят лучше. Я вообще планирую повесить на каждый энкодер по несколько параметров. Кнопку, встроенную в энкодер, буду использовать для выбора параметра. И вот тут индикация названия параметра просто необходима. Но уровень параметра буду выводить на кольцо.
По крайней названия треков в видео у него присутствовали.
Если хост может послать эти данные — то почему бы не отобразить? Вам нужно четко понять разницу между названиями/значениями параметров и такой информацией, как название трека. Что касается параметров — они в первую очередь хранятся в самом контроллере. Контроллер отображает не те значения параметров, которые хранятся на хосте, а те, которые хранятся в контроллере. В результате контроллер будет отображать изменения параметров даже не будучи подключенным к компу. Если же значение параметра изменяется на хосте, например мы мышкой передвинули виртуальный фейдер, то хост передает контроллеру соответствующее событие, а контроллер корректирует соответствующий параметр у себя в памяти. А вот названия выбранного на хосте трека контроллер знать не может, поэтому хост должен уметь его послать.
0
Я хоть и далек от этого дела, но кажется понимаю, что имеет ввиду HRON — следующая ситуация: мы подключаем нашу железку к хосту, открываем на хосте наш любимый муз-редактор (секвенсор или как там оно), в редакторе открываем наш сохраненный проект, над которым уже работали, и в котором уже была сохранена привязка наших 5 (например) энкодеров каким-то 5 параметрам. И теперь сам фокус: секвенсор отправляет на железку не только идентификаторы этих параметров и значения, а именно их названия, в результате наша железка сама выставляет на этих 5 энкодерах необходимые значения, привязывает идентификаторы параметров, которые каждый из энкодеров будет редактировать и отображает названия этих параметров на экране.
Хотелось бы именно этого.
С другой стороны, если это невозможно, я вижу такое решение: если секвенсор отправляет на железку хотя бы идентификаторы параметров, и если эти идентификаторы унифицированные какие-то мидюшные (а не просто внутренние придуманные секвенсором от 0 до n), то железка сможет по своей внутренней базе сопоставить этим идентификаторам названия. Не так прикольно, как 1 вариант — но приемлемо.
Ну и самый неинтересный, но тоже вариант: секвенсор на хосте вообще ничего не отправляет такого, по чему можно было бы однозначно судить, что за параметр, тогда нам нужно отдельно на самой железке хранить пресеты для каждого трека и дополнительно еще и на железке их перед работой загружать. Тоже ведь вариант, но не удобный.

Ну и собственно вопрос: какие вообще данные может/отправляет секвенсор в железку во время загрузки проекта и после во время работы? (То есть я понимаю, что протокол миди стандартизован, но мы-то с ним так близко еще не работали, да и может секвенсор вопреки стандарту шлет какие-то дополнительные данные, не? А может в МИОС предусмотрены какие-то дополнительные вещи на сей счет?)
0
И теперь сам фокус: секвенсор отправляет на железку не только идентификаторы этих параметров и значения, а именно их названия, в результате наша железка сама выставляет на этих 5 энкодерах необходимые значения, привязывает идентификаторы параметров, которые каждый из энкодеров будет редактировать и отображает названия этих параметров на экране.
Ну это Вы вообще коммунизма хотите :). А теперь вопрос: откуда хосту или контроллеру знать какие контролы софтового синтезатора (их там порою бывает сотни) Вы хотите рулить железом? И в какой последовательности эти контролы на железе нужно расположить? И не задолбаетесь ли Вы их потом разыскивать? Хост не передаст список параметров контроллеру, по крайней мере я о такой возможности не знаю. Поэтому приходится Ваши пожелания по привязке параметров к железкам описывать в проекте контроллера. Но ведь, как правило, набор используемых синтов/обработок довольно определенный, хотя может быть Ваш товарищ экстремальный экспериментатор и любит в каждом новом треке использовать абсолютно новые конфигурации, тут я уже не знаю. В любом случае начало каждого нового проекта в редакторе будет начинаться с довольно нудного процесса привязки виртуальных органов управления к МИДИ-событиям.
Я бы посоветовал обратить внимание на то, как это все реализовано в цифровых консолях. Имеем несколько т.н. слоев (layers), т.е. активен слой №1 — рулим этими, этими и этими параметрами, канал № такой-то, контроллеры с такого-то по такой-то; активен слой №2 — рулим следующим набором параметров через канал №???/Контроллеры №???-№??? и т.д. На каждый энкодер вешаем рулежку двух-трех параметров на слой (обратите внимание — в самых райдерных цифровиках всего по 2-3 энкодера на полосу и кольца в обязательном порядке). Слоев имеем столько, сколько позволит память контроллера, хоть на каждый синт по слою. Названия параметров, естественно, тоже прописываются в контроллер. А уже в секвенсоре привязываем соответствующие контролы к МИДИ событиям, которые генерирует контроллер. Т.е. от контроллера к секвенсору, наоборот к сожалению не выйдет.
Уже по ходу работы секвенсор сообщает контроллеру (конечно если подключен второй МИДИ кабель) об изменениях привязанных параметров если эти изменения произошли по инициативе хоста (мышь, огибающие или автоматизация) и контроллер эти изменения отрабатывает у себя(изменение значений параметров в памяти и изменение индикации)
Итак, 1 — конфигурируем консоль под свои конкретные нужды; 2 — конфигурируем проект на секвенсоре под настройки консоли. По другому, ИМХО, никак.
Ну и хочу напомнить, что загрузить новый проект в МИДИбокс — минутное дело, никакой дополнительной коммутации, MIOS Studio все загружает по МИДИ. Можно хранить файл проекта МИДИбокс вместе с проектом секвенсора.
0
Да, еще одно. Обратная связь от хоста к контроллеру в большей степени зависит и программы-хоста, чем от MIOS. В MIOS можно в обход стандарта принять и обработать информацию о конфигурации контролов, благо дело в МИДИ протоколе предусмотрена передача текстовых строк. Правда писАть эту обработку придется самому. Осталось только найти хост, который эти данные пошлет. Вы сможете что-нибудь дописать к тому же AbletonLIVE или к Cubase? Вряд-ли…
0
Очепятка — следует читать: «зависит от программы-хоста»
0
Вот и замечательно! То есть вы как раз и ответили на интересующие меня вопросы! Теперь ясность достигнута :)
Жаль конечно, что дела обстоят именно так, ну что поделать.
В любом случае спасибо за разъяснения!
конечно если подключен второй МИДИ кабель
Вот это немного озадачило — у нас планируется все по усб передавать, ведь мидибокс это умеет, как я понял, и надеюсь — в обоих направлениях?.. (если я правильно понимаю, при этом по усб как раз эмулируется двунаправленный миди-интерфейс)
0
Это я о классическом MIDI. По USB проходит туда и обратно, так что понимаете Вы правильно :)))
0
Автор, так ты сделал в итоге свой контроллер? Я вот тоже озадачился, есть куча вопросов, тоже рекомендуют сделать на STM8 и STM32. На мидибоксе уже был, нашел то, что похоже на мою задумку, но не нравится мне то что все это на сдвиговых регистрах сделано. В общем, если есть желание поделиться опытом, отпишись (P.S. я — нуб в электронике, но надо ж с чего-то начинать =)
0
На мидибоксе уже был, нашел то, что похоже на мою задумку
Что именно задумали? На базе MIOS можно написать прошивку под любую конфигурацию контроллера, это совсем не сложно. На мой взгляд проще написать свой проект с нуля, чем адаптировать уже готовые.
но не нравится мне то что все это на сдвиговых регистрах сделано.
А Вы видите другой способ расширения портов? Причем сопоставимый по простоте, эффективности и дешевизне? Ног-то у контроллера не бесконечное количество. Я, например, использовал данное решение (подсмотрел я его именно на MIDIBox-e) для управления 24-мя 40 амперными симисторными ключами. 3 платы по 8 ключей, регистры размещены на этих же платах. Три платы соединены последовательно, первая подключена к контроллеру. И все по четырем проводам. Представьте, от какого жгута проводов меня избавило такое решение. Устройство эксплуатируется уже третий год, полет нормальный.
С дизайном, приведенным на MIDIBox-e я не согласен (там те же самые жгуты), разношу регистры непосредственно на платы, на которых размещены органы управления и индикации, а платы соединяю между собой теми же четырьмя проводами.

Самое ценное в MIDIBox — MIOS. Отлаженная, надежная и гибкая платформа. Такого софта для МИДИ-строительства я больше не видел нигде. Поэтому, ИМХО, стоит к этому проекту присмотреться повнимательнее.
0
forum.easyelectronics.ru/viewtopic.php?f=14&t=14752
Вот тут мне каждый по-своему советует как сделать. Хочу сделать контроллер с общим количеством контроллеров около 500 штук.
На регистрах было бы просто, я уже прототип разводил на ардуине и все работало. Другое дело как быстро все будет работать.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.