DIY arduino и прочее баловство MIDI CC конвертации для контроля динозавров от Korg, Roland, Yamaha

[Vladistone]

Хочу поднять тему обьединяющую вокруг старых синтезаторов и новых технологий с кодированием на уровне IDE, Python, luna, java и т.п. ибо в мировом пространстве давным давно из этого уже сдедали достаточно фирменных коробочек, ну а наш петух клюет только тогда когда на гору рак взгромоздится: универсальный MIDI SysEx СС контроллер DIY
Так же есть определенные кулибины кодинга которые подхватывают насущные идеи и "двигают"... но не всегда поддержки иной раз не хватает, что бы отшлифовать идею или довести ее до коммерческой эксплуатации...
ну а нам - пользователям Ру - иной раз и негде обсудить на просторах рунета не просто - новые девайсы, а возможные проблемы и тупики... но главное - решения, поэтому предлагаю поделиться своим опытом и советами!
Для начала сориентирую что в принципе есть, и чего хотелось бы достичь здесь:
подключение синтезаторов эпохи середины-конца 80-х и новых DIY штучек, озвученные на GIthub и др. прощадках...
(tag #Korg #DSS-1 #DS8 #DW8000 #EX8000 #Yamaha #DX #TX #SY #TG #EX #Roland #D50 #D550 #JD #JP #JX #JV #Juno #Jupiter #Ensoniq #EMU synths и так далее.. . не дальше начала 90-х... или середины...)
то есть те девайсы которые собраны, по-большей части на SysEx MIDI-имплементации и для которых требуется ретрансляция под современные контроллеры или подобные из той же эпохи типа Roland JP8000 - с удобным наглядным интерфейсом крутилок сопелок и пыхтелок... для классического FM, post FM-synth, Additive & wavetable Synth плюс PCM samples
Есть конечно готовые гаджеты типа KIWI PE, Retroaktiv и даже stereooping с подобными DIY элементами, но с учетом того что курсы родной валюты совсем не соотвествуют творческому потенциалу страны и ценникам на б/у инструменты тех лет - то по сути бессмысленность покупки таких железяк очевидна само по себе... А другие направления по специфичным контроллерам уже есть где обсуждать.
Еще прошу ограничится темой без soft editor - этого добра хватает вплоть до lua scripting под Reaper,.. раз уж мы заговорили про железные синты и их upgrade с обучением железа, об опыте внедрения/вживления трансляторов на базе копеечных чипов Arduino (возможно и иным способом), с целью использовать свою собственную мастер клавиатуру или иной доступный универсальный и недорогой MIDI контроллер. Не прибегая к soft трансляторам типа BOME midi translator или внешним гаджетами/посредникам готовых решений типа RK002-MIDI-cord, хотя вот такой MIDI-implant или его аналог для прото-динозавров эпохи аналоговых органов и синтов будет в тему!
список синтов-“динозавров” большой, так же как и список мастер контроллеров у каждого имеется свой, любимый или единственный по каким либо причинам. Предлагаю здесь аккумулировать опыт и знания, «подводные камни» внедрения ЧИПов.
Согласитесь, что это полезно для кругозора каждого, кто вступил на тропу изучения возможностей и «рулежки» sound design с подобными машинами?! Тем более что стоимость б/у инструментов для начинающих эксперементаторов играет немаловажную роль в их доступности на современном рынке муз инструментов, а возможности старых машин (old school, если можно так выразится) не всегда явно видны и нативны для изучения…
Прелесть подобного "железа" еще в том, что если в сети есть service manual-ы, то они довольно подробно описывают все операционные процессы и принципиальные схемы синта с part listing и midi-implementation chart! А внутри всегда есть доступ к элементной базе устаревшей с прошлого века, но до сих пор доступной... не то что новоделы, где все организовано на SMD базе и еще залито компаундом для сокрытия интеллектуальной собственности от DIY-умельцев обратного ре-инжиниринга... но при этом сам девайс продолжает пользоваться комплиентарными протоколами прошлого века, середины 80-х (даже тот же KRONOS... post-OASYS-ной реиновации от Korg ничего революционного, кроме удешевления корпуса и обновления элементной бызы электронных компонентов на базе Intel D510MO с Atom D510 1,66 ГГц и NKS4 не добавил ничего нового в свою MIDI-имплементацию).
Хотя со мной могут поспорить и сказать что CC# собщения там внедрены,.. Да, согласен,.. но они там куцые и в любом случае SysEx остается основной языком общения с этим "железом" для настройки как in так и out переферии...

[Vladistone]

может и сама задача конвертации стандартных CC# сообщений в проприетарные SysEx под конкретный древний девайс является для кого то не несложной и скучной, но поверьте - есть много ньюансов, начиная от
- доступности сервисных схем синтезаторов
- знаний кодиродания и разнообразия языков программирования
- MIDI implementation chart, доступность и ограничения на определенную модель синта,
- сами CC# и SysEx коды имеют разную длину байтов, что иногда не учитывается ни тем кто разрабатывает код, ни тем кто его внедряет или модернизирует на свою машину… не говоря уже что есть элементарные ошибки расшаренного кода по hex и decimal написанию,..
Вот наглядный пример:
- для изменения кода Device ID при адаптации к родственному по модели производителя инструменту можно либо не обратить внимание на это, либо тупо скопировать данные выведенные в десятичном формате туда, где требуется шестьнадцатеричный вид MIDI данных, благодаря тому, что те же MIDI-мониторы выдают это и так и так, в зависимости от надстроек preference…
- иной раз забываешь про ньюансы нумерования channel# (когда интерфейс синта выдает удобочитаемый порядок от 1 до 16, а сам внутри использует кодировку с нуля до 15… и при этом еще есть разночтения IDE MIDI library в зависимости от используемых версий тем, кто писал код когда-то, и тем кто его адаптирует в текущий момент… (пример покажу позже, что бы незаграможлать ответ)
- про длинну смещения SysEx я просто уже не упоминаю, ибо это тема специфичная для каждого производителя, и то что иногда делается «с пол пинка» у одного производителя или модели, натыкаешься на «недопонимание» с другим объектом внедрения…
Поэтому иной раз и требуется взгляд со стороны «бывалых» экспертов в той или иной сфере моделирования и upgrate...

[Vladistone]

Вот мой один из проектов:
Korg EX8000 и DSS-1, на базе хака “Korg DW8000 midi enhancer” от Steve Baines, но судя по истории репозитария Github и отсутствию обратной связи с автором проекта с 2016 возможно, что то пошло не так либо в жизни, либо в предпочтениях и продолжению проекта?.. или развития музыкальных взглядов у человека… а те куцие 6 комментариев на сайте говорят о том, что допиливать этот проект некому, либо каждый борется в одиночку со своим железом и arduino…
Ну так вот что получилось у меня:
EX8000 до установки

4D872EF6-56A1-4838-B1AC-B3D5AD35DA11.jpeg

и после

28D0DD20-4CE9-42D8-8D66-97C0424D3E2D.jpeg

на подготовку, разборку,заливку прошивки, установку и сборку ушло примерно 2 часа и 300₽ с/стоимости комплектующих. Каюсь… на поездку в магазин было потрачено полдня с попутным шопингом arduino nano, и coffe-time…
Придерживался пошаговой инструкции автора и отклонения были лишь в том, что не стал «хоронить» микроконтроллер в черную термоусадочную пленку (прозрачной на тот момент не было у меня), а заизолировал контакты на скотч и посадил жестко на термо пластик сверху на процессор…

Второй модинг для DSS-1 сделал чуть по другому: прилепив плату arduino на плату MIDI сокетов - панель KLM-788 Jack. питание взято с ближних точек к разъему CN26B (pin #5 и #6). Штекер питания для arduino посадил так же на термо-пластик, а arduino уже фиксируется на нем, под 90град./"ребром" к плате KLM-788.

7FEFC273-D5E4-4F6D-BB1B-A79443204142.jpeg

для подключения RX и TX с помощью доп.соединительного штекера сделал разрыв кончика от pin#2 того же сокета CN26B, идущего к основной плате KLM-781 CPU-II - HD63B03X. (нюанс состоит в том, что бы не перепутать куда садить на разрыв конца Tx и Rx: Rx - соединяем c концом идущим к сокету pin#2 CN26B, а Tx - к обрезку идущему к основной плате KLM-781 процессора HD63B03Xб обозначенного на принц.схеме как IC11) См. Часть принцип.схемы:

07C00141-EC75-4BDA-A28F-D4DD20B2E089.jpeg

весь service manual тут
конструкция получилась нагляднее при открывании верхней крышки синта и можно снять для удобства перепрограммирования arduino.
На этот upgrade для DSS-1 потребовалось чуть больше времени из за изучения и изменения кода Device ID (для DW/EX - 0x03, а для DSS-1 - 0x0b),.. всего часа 3 с частичной разборкой задней панели синта и поиска подходящих разьемов для подключения 4-х концов к arduino. Цена с/стоимости таже - 300₽.
Зато какая внуренняя красота?

D3586652-F5AA-49C4-9F7D-B40FB4DD5341.jpeg

DFC322D0-46EC-4D5A-8CD5-51D66CD46C77.jpeg

Сразу «потянуло на подвиги» музыкальные и новые идеи, типа разместить в районе FDD эмулятора пары внешних светодиодов для Rx Tx сигнализации, но это пока отложил в сторону и обдумываю, на предмет излишеств… на этом пока все… буду тестить upgrade, на адекватность приема и отработки CC# данных от Roland JP-8000

296AE714-0BEE-4ED2-9850-D37C60136782.jpeg

[Vladistone]

Первые тесты показали что не все CC# доступны после конвертации в SysEx.
И что бы не гадать на кофейной гуще в поисках причин (soft или hard? монтаж косяки или глюки динозавра DSS-1) - я решил попробывать собрать "автономный tester" для данного CC/SysEx конвертора на базе дешевого USB-MIDI интерфейса с подключением в loop инсталированного arduino. прошу не кидать в меня тухлыми яйцами, а помочь советом т.к. занимаюсь arduino совсем недавно, можно сказать - вчера, и возможно рассуждаю глупо, и наверняка есть более простые и изящные приемы и фитчи для мониторинга MIDI IN и OUT (прошу об этом помощи у бывалых), итак:
разобрав дешевый китайский USB-MIDI интерфейс я обнаружил вот такую картину Z-TEK® UD486 с затертыми поверхностями микросхем:

638AC3AF-801C-44C1-8AAD-6DBB9C5080A8.jpeg

что немного насторожило, т.к. подобное я не видел ранее и не встречал на просторах интернета при обсуждении проблем с допиливанием дешевых китайских USB-MIDI интерфейсов
но пришлось двинутся дальше с тем что есть в наличии, к реализации идеи автономного MIDI подключения Arduino Tx и Rx pin согласно этим рекомендациям и схемке:

cheapo_midi-usb.png

вот что у меня получилось в итоге

IMG_7507.JPG

IMG_7508.JPG

IMG_7509.JPG

ну и сама arduino с контактными разъемами (3-pin идет на +5, GND и Reset - который еще не подключил, а 2-pin - на Tx; Rx)

IMG_7510.JPG

но вот тут меня смущает рекомендованная схема подключения (потому что сразу не заработало как хотелось бы), красным - мои правки:

cheapo_midi-usb (1).png

вопрос к экспертам:
- может быть надо поменять концы Tx - Rx местами?
от arduino Tx - на "In+" данного интерфейса, и соответственно с Rx - на "Out+"?
- а должна ли работать подобная схема вообще? минуя тушку синта?
проверить остальные предположения и сомнения пока не удалось (а именно - правильности составления кода - это раз, а отрабатывает ли USB-MIDI тот обьем конвертации MIDI CC и обратно SysEx для отслеживания на MIDI мониторе? или он вообще - не рабочий?)
какие будут рекомендации товарищи!?

[Skinny]

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

[Vladistone]

Такой вариант удобен, не спорю… в случае постоянного проектирования и перепрошивания одной arduino под разные варианты coding. Но в инсталяции нескольких синтов такие «сопли» лишь будут вносить беспорядок… поэтому «спрятать под капот и забыть» - тоже вариант имеет место быть… вопрос лишь в отладке при запуске модинга. Просто видимо тут сошлись в одно время и точке несколько проблем:
- отсутствие опыта и подготовленной мат.оснастки для экспериментов
- сырой code и желание отследить на MIDI-мониторе работоспособность прошивки
- возможно проблемный MIDI-интерфейс, который не проверил заранее, а как капнул начинку - так еще больше поплохело из за подобной скрытности производителя (как будто изготовили этот интерфейс на top-secret military base)… ну да ладно… других вариантов под вечер воскресенья у меня не было!
А что делать дальше? Я о схеме подключения arduino к данному USB/MIDI:
- логика мне подсказывает что пример описанный выше имеет ошибку (т.к. на стороне MIDI сигнал от «O+» должен идти по идее на RX-pin arduino, а так же: TX-pin д.б. подключен к «I+» интерфейса, а не наоборот, как указано в рекомендации выше).
Или я что-то недопонимаю?
Может быть надо перекинуть TX; RX на соседние pin с знаком «минус»? Ибо на первой картинке не указана маркеровка, а только относительный порядок подключения…

И еще есть ньюансы: т.к. arduino, подключенная до этого в синт все же демонстрирует работоспособность (мигают Rx и Tx светодиоды и есть частичная управляемость синта с внешнего CC# контроллера), а при подключении автономно к непонятному по своей внутренней начинке USB/MIDI - молчит и не реагирует, то причина м.б. не только в коде, а и в интерфейсе или его подключении к arduino! В чем я как раз и сомневаюсь… подтвердите или опровергните мои опасения please

[Vladistone]

Неугомонный Парамоша откинул USB-MIDI интерфейс до выяснения обстоятельств (но вопросы озвученные здесь по Z-TEK® остаются в силе))
И решил собрать мониторинг за деятельностью Arduino с помощью Hairless MIDI to Serial Bridge,.. и через сервисный mini-USB-порт Arduino напрямую подключив его к компу:

Serial Routing.jpeg

вот с такими настройками по умолчанию

serial port setting.jpeg

затем подключил через IP MIDI port 3 - внешний контроллер к компу и его сконфигурил на отправку CC# через IAC 1 (как внутренний MIDI-in port для hairless-midiserial) и далее на mini-USB Arduino (извините за сложности ротации того что "входит и выходит" к Mac - но по сути установка такая (синяя овальная стрелка и красный arduino))):

Arduino.jpg

после чего я в мониторе получаю следующее:

MIDI monitor All.jpeg

но гораздо проще посмотреть на картинку через раздельные окна MIDI IN и OUT на мониторе Pocket MIDIи там же показан роутинг контроллера IP MIDI в компьюторе через шлюзы драйвера IAC 1 и 2

Pocket MIDI routing.jpeg

но как видите - безрезультатно!
MIDI-serial вход c Arduino - Port2 молчит... только происходят всплески Time Clock: 0xF8 и встречаются странные MIDI сигналы Program Change (0xC0 0x00) и MIDI-транспорта STOP (0xFC) (я не стал тянуть с показом и загромождать картинку данных монитора) хотя для наглядности вот она:

MIDI stop.jpeg

MIDI in Port 2 PC.jpeg

Теперь вопрос в студию:
- А правильно ли я настроил serial-MIDI порт? и справлятся ли он с задачей приемки SysEx?
- Или все-таки это баг прошивки Korg DW8000 MIDI Enhancer?
- или подобные "кастыли" для Arduino непримемлемы?
вот что нам сообщает монитор hairless-midiserial (и это меня смущает - что это? подскажите пожалуйста:

Код: Выделить всё

+4487.5 - Warning: got a status byte when we were expecting 1 more data bytes, sending possibly incomplete MIDI message 0xc0

serial MIDI 2.jpeg

первое что нашел на форуме arduino
https://forum.arduino.cc/t/hairless-mid ... yte/243010

[Vladistone]

после беглой регулировки midiserial FlowControl на XON/XOFF
получаю уже что-то вменяемое на мониторе с фильтром по входному MIDI-каналу IAC 2 (или port 2 для Pocket MIDI):

monitor 2.jpeg

а это значит...ммм... что компиляция прошивки или код толком не работает и выдает вместо SysEx - рандомные MIDI "note off"?

pocket MIDI 2.jpeg

- Или надо еще что то подкрутить в настройках Hairless midiserial app?
- Может кто поможет взглянуть экспертно на код преобразования СС2SysEx?

[Skinny]

Если что, скорее всего и код и прочее написаны под миди и там должна быть скорость 31250 бод, не 115200.. Многие чипы последовательных интерфейсов не могут работать на такой частоте по умолчанию, например для китайского клона FTDI был хак что-то там в регистре поправить можно было, и тогда через хэйрлесс он выдавал реальное вполне себе миди..

[Vladistone]

Если что, скорее всего и код и прочее написаны под миди и там должна быть скорость 31250 бод, не 115200.. Многие чипы последовательных интерфейсов не могут работать на такой частоте по умолчанию, например для китайского клона FTDI был хак что-то там в регистре поправить можно было, и тогда через хэйрлесс он выдавал реальное вполне себе миди..

спасибо, попробывал менять бод на ближайщие к 31250 (19200 и 38400) ничего не меняется принципиально
надо копать глубже

[Vladistone]

по итогам мини расследования в поисках решения с использованием software MIDI-serial и Arduino nano (в моем случае ATmega328P CH340)
вердикт неутешительный: в Arduino Uno или Nano последовательный порт не может одновременно использоваться для данных и MIDI!
поэтому требуются дополнительные адаптеры (например или MIDI shield или FT232RL FTDI) либо продолжать моделить свои "костыли"- USB/MIDI интерфейс Z-TEK®, при рассмотрении которого под лупой, сразу нашлись недостачи 3-х элементов на плате (отмечено красным):

638AC3AF-801C-44C1-8AAD-6DBB9C5080A8.jpeg

R8 - отсутсвует и это сразу разрыв сигнальной цепи от оптопары U3 pin#6 (вероятно 6N138) и далее на U2 20-pin (D-вход USB)
R3 - разрыв от U1 14-pin (нет ни данных ни схемы принципиальной! может кто по опыту подскажет где искать ее? или что за номинал)
T1 - отсутсвует из за явного непропая! как и предыдущие SMD-резисторы...
надо искать схему для востановления калеки...

[Skinny]

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

https://i.imgur.com/9tHWVj3.png

Ардуиновский миди шилд кстати схема там примерно такая же, там нет ничего специального, тоже просто оптипара... оптопару можно еще диодную использовать (именно только с ардуиной так), они все быстрые, но слаботочные. Только резистор не 560ом, а где-то порядка 56к нужен в таком случае.. А так вообще любую оптопару реально заставить там работать, кроме медленных, вот на pc123, pc817 и так далее граничная частота указана 80кгц, это мало. Зато все что выше этого, или если там написано скорость передачи данных мегабит и тд - это все работать будет. Да это я к тому что свет клином на 6n137 или 6n138 не сошелся.. Если их нет в наличии или дорого там.

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

[Vladistone]

Мне в обратную сторону (в комп. USB) нужно преобразование… то есть создать петлю миди! Для мониторинга миди-конвертации arduino…
То есть - я отправляю CC# по USB в Arduino и так же хочу возвратить SysEx от Tx обратно в комп по USB для мониторинга того что «входит и выходит» в arduino!

AA9DA272-60CC-42B2-8A2D-596988E0CB43.jpeg

DSS1_Sysex.xls

вероятно надо испозьзовать варианты по наладке последовательного MIDI-монитора

[Skinny]

ну вот, то что я и описывал как раз для того чтобы сделать петлю)

[Vladistone]

Ну битрейт должен быть ровно 31250, ближайшие они уже достаточно далеко чтобы ничего нормального не увидеть...
да столько заморочек, уже проще было сделать входы и выходы миди на ардуине, тем более что там минимум деталей...
https://i.imgur.com/9tHWVj3.png

кстати хочу внести некоторые дополнения к обвязке TX на MIDI
вот тут рекомендуют вставлять инвертор и усиление сигнала для Tx
http://www.tigoe.com/pcomp/img/midi-schem.jpg

ну вот, то что я и описывал как раз для того чтобы сделать петлю)

я так понимаю с помощью MIDI-кабеля? для формирования физической петли путем MIDI OUT to IN?
не совсем понятно, что мы этим добьемся?: т.к. тогда полученный по USB-serial host, MIDI CC# должен одновременно обрабатываться микропроцессором Arduino и соответственно отправляться дальще на MIDI-loop и обратно в микропроцессор и в комп... мне кажется тогда мы точно "посадим" микропроцессор на MIDI-цикл...
Тут вероятно более изящное решение д.б... то что использует отдельный USB-MIDI host для отправки CC# и отдельно USB/MIDI port для приема/получения обработанного сигнала в SysEx... или
Вот тут я наткнулся на идеи использования параллельного трекинга через SPI-протокол... но для меня эти serial-протоколы - темный лес, надо будет погрузиться в ликбез. и в особенности специфики использования softwear-serial для мониторинга трафика midi... так как нет четкого понимания, каким образом одновременно заставить этот MIDI-конвертер работать на arduino и мониторить MIDI программно и аппаратно (одни говорят - Arduino nano и micro - продходят... другие заняли противоположную позицию и говорят что требуется по-серьезней Nano типа Mega или Nano Every с несколькими портами UART?!
в общем: пока каша в голове...
есть мнения еще?

[Skinny]

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

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

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

[Vladistone]

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

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

Мы наверное по разному строим логические рассуждения,... необходимо договориться, что:

• у нас есть уже готовый код и ардуино, готовый конвертировать MIDI СС#2SysEx
  требуется настроить MIDI-монитор (желательно по одному и тому же USB/COM/MIDI port

• либо придется "городить огород" с обеспечением доп.внешнего USB/MIDI интерфейса и доп. MIDI-обвеса для Arduino-конвертера с подключением к этому самому интерфейсу в дуплексном режиме MIDI IN-OUT

или я что то не понимаю?

[Skinny]

нууу чет я хз либо объясняю не очень либо что)

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

теперь выход с усби-интерфейса соединяется со входом ардуины, а ее выход со входом усби интерфейса. ну типа петля.

теперь на компе открывается любой софт типа midi-ox и там два окна, на передачу данных и на получение данных.
передаешь любое ЦЦ, смотришь что вернулось обратно.

сигнал летит по петле, проходит ардуину, изменяется там и возвращается обратно в комп уже в новом виде..

[Vladistone]

нууу чет я хз либо объясняю не очень либо что)

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

теперь выход с усби-интерфейса соединяется со входом ардуины, а ее выход со входом усби интерфейса. ну типа петля.

теперь на компе открывается любой софт типа midi-ox и там два окна, на передачу данных и на получение данных.
передаешь любое ЦЦ, смотришь что вернулось обратно.

сигнал летит по петле, проходит ардуину, изменяется там и возвращается обратно в комп уже в новом виде..

Вот !.. где собака порылась! ))) вся суть и прояснилась после всего вышесказанного...
это издавно называется "проблемой строителей вавилонской башни", когда люди разговаривают вроде на одном языке, но каждый подразумевает и строит логические цепочки по своему, либо кто-то не сверяет свое видение с окружающими (виноватых тут нет, но иногда выходит результат до абсурда!).
Все что вы сказали уже было изначально мной испытано в первом варианте (см картинку "1-вариант") но лишь с попыткой исключения коммутации по MIDI-кабелю (идея и ее реализация вроде и банальная, но мой "затык" произошел из-за бракованного MIDI-конвертера, о котором я писал ранее здесь).
Поэтому пошел по "2 варианту", который тоже не дал результатов из за несоответствия скоростей передачи данных по USB VS MIDI (31250 бод)
и далее понеслась фантазия... (варианты 3 и 4)

Variations.png

Но после моих наводящих вопросов про MIDI-loop, я попытался прояснить картинку, которая у меня нарисовалась в голове:

я так понимаю с помощью MIDI-кабеля? для формирования физической петли путем MIDI OUT to IN?
не совсем понятно, что мы этим добьемся?: т.к. тогда полученный по USB-serial host, MIDI CC# должен одновременно обрабатываться микропроцессором Arduino и соответственно отправляться дальще на MIDI-loop и обратно в микропроцессор и в комп... мне кажется тогда мы точно "посадим" микропроцессор на MIDI-цикл...

но вы проигнорировали это... ну что ж... бывает и такое - когда один обьясняет, без деталей, а второй "рисует у себя в голове" эти MIDI-концы к противоположной (но к «удобной ему») стороне arduino:

Trash MIDI loop.png

[Skinny]

А, ну я наверное не так понял))
Последний-то вариант конечно черт знает что)
Речь о том чтобы и миди слать и работать с ардуиной с компа одновременно с последовательным портом и быть не может, на ардуине всего 1 порт.. ну на младших. И он или для миди будет использоваться, или для подключения к компу. И он дуплексный, но он один. Ну хотя и можно накодить software serial, чтоб было два порта..

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


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

Если этот конвертер все-таки нормальный и живой, подключение его напрямую к ардуине будет так:
на платке конвертера как на фотке здесь: download/file.php?id=1921&mode=view
Если обозначения правильные, O это Output и I это Input. Сигнальный выход миди конвертера, скорее всего O-, кидаешь напрямую на RX вход ардуины, ну можно через резистор типа 1к для защиты от косяков)
Выход ардуины, Tx, в идеале надо два резистора как полагается, как на схемах миди интерфейса для ардуины, резисторы 200 или 220ом, тот резистор который на +5в посажен с него соответственно кидаешь на I+, ну а с самого Tx ардуины через 220к подаешь на I-.
Ну вроде так. Вроде должно работать. Один из резисторов можно не ставить, если нету, но на свой страх и риск.

Хотя если на плате миди конвертера выход организован не то что передача тягает сигнал вниз, а наоборот, поднимает вверх, то есть активный провод не минус а плюс, то такой метод не сработает и надо будет инвертировать сигнал как-то (или забирать с ноги микроконтроллера), а вот при развязке с оптопарой как по правилам должно быть, всё будет работать. Поэтому я и говорил сразу за нормальный вариант - сделать миди входы и выходы на ардуине как по фэншую.. Есть ведь два варианта как создать токовю петлю, дёргать или положительным или отрицательным проводом, хотя по стандарту - вроде как отрицательным, но китайцы могут что угодно.. Оптопаре пофиг, на прямое подключение же влияет..


И да, еще вот вариант, поменять бодрейт на китайских клонах FTDI можно через реестр в системе, уже совсем не помню как но я менял когда-то, на дешевом адаптере usb-ttl за 50р. После этого ближайший ненужный битрейт работал по факту на 31250.
Микрухи типа Ch340 некоторые поддерживают более широкие настройки битрейтов и в том числе если вбить произвольный, например ch341 у меня заводилось на 31250 легко, в RealTerm проге. Только там геморно, надо сначала выбрать битрейт потом активировать порт или чето там, потыкаться короче.

[Vladistone]

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

по USB2MIDI кабелю - я сейчас "уперся рогом", что бы перерисовать схемку и определиться с работоспособностью и дальнейшим подключением (по сути он мне не нужен был и я даже не помнил, как он интерфейсил - "прямо" или "по-диогонали"). Поэтому сделаю свою "первую курсовую работу" по рисованию схем - тогда отпишусь!
Но при более внимательном изучении элементной базы под лупой, проясняются некоторые пикантные детали:

• оптопара - 6N138. и на ней нет ни pulled down R=1k на 7-pin, ни pulled up (или тока-ограничивающего R=470) для +5V между #8 и #6 pin OUT на 20-pin USB-контроллер, который идет через отвалившийся R8
  like this.PNG
  pair.PNG

• И с инвертором NXP 14-pin типа 74HC04 тоже связана история с отсутвием на 5-pin R3 и T1, который идет далее на через R6 220 на "O-"!
  у меня лишь появилась идея и я ее думаю (по аналогии с внедрением этогоCC#2SysEx конвертора внутри Korg DW8000/DSS-1) - подключить TX от arduino минуя оптопару сразу на "хвост" R8 идущий на 4-pin USb-контроллера, т.к. вероятно это и есть UART Rx

• и по свойствам USB переферии компа определяется как PID 0x552D VID 0x4348 можно только понять, что это продукт WCH м.б...

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

[nampuapx]

эээю. Когда то ардуино и миди не ровнялось одно другому. Ардуиновские библиотеки не соответствовали спецификациям миди. Сейчас не знаю

[Walli]

эээю. Когда то ардуино и миди не ровнялось одно другому. Ардуиновские библиотеки не соответствовали спецификациям миди. Сейчас не знаю

Для этого есть библиотека usb-midi

[Vladistone]

эээю. Когда то ардуино и миди не ровнялось одно другому. Ардуиновские библиотеки не соответствовали спецификациям миди. Сейчас не знаю

сам не знал, но судя по наличию экспериментов на том же Github - уже более 10 лет народ юзает и в хвост и в гриву arduino для MIDI
не у всех получается... но прогресс не стоит на месте...

[Vladistone]

в общем сваял я эту схему, (боюсь что закидаете меня гнилыми помидорами, но не обессутьте - делал впервые!) Если что поправте меня...
комментарии к схеме:

• места помеченные серыми кругами с маленкими крестиками "x"- это фактически отсутствующие на плате элементы R3; R8 и T1 - его полярность и ориентация выбраны мной случайно... возможно надо измениить условное обозначение (но пока все что есть = это пустые места для SMD пайки

• цветным размечены планируемое внедрение контактов для arduino, и так же R10 на плате - не существует, это mode согласно вот этим рекомендациям

• У меня тоже есть немало вопросов по схеме:
  - как то странно подключен hex инвертор 74HC04 к питанию через pin#11, хотя м.б. по факту и не он... мне удалось прояснить лишь маркировку производителя NXP L7033 или ...39 или ...38 а вторая строка начинается с URG0735L... а U2 USB-контроллер - затерли основательно...
  - обьясните пожалуйста невежде: необходимость присутсвия здесь инвертора по данной схеме? только для мигания "цветомузыки" светодиодов MIDI IN - MIDI OUT?
  - и мне не удалось найти хотя бы примерный аналог и datasheet для U2 USB контроллера, но хоть есть понимание обвязки каналов UART

теперь остается один риторический вопрос: стоит ли ставить заплатки и какие по номиналу?, или обойти напрямую c Arduino на UART USB-контроллера?

Scheme-it-export-MIDI-4.png

[Skinny]

Насчет инвертора - все из них (по крайней мере популярные, 7404, 40106, 4069) имеют одинаковую распиновку, питание и входы и выходы.

То есть вот начиная по пинам 1 это вход, с него идет выход на 2, 2 и 3 соединено и с 3 на 4 выход, то есть две инверсии, и пошло на светодиод (миди аут).
Так как светодиод не горит, пока не идет передача миди, ну по логике, а перед ним две инверсии (все равно что ничего), значит можно предположить что и обычное состояние выхода микроконтроллера, когда данные не передаются, это низкое, логический ноль. Что с точностью да наоборот, чем на ардуине и большинстве последовательных портов.

Если схема отрисована более-менее правильно, то как сигнал попадает на миди выход?
От плюса питания, через R5, проходит оптопару на подключенном синте например, и возвращается через R6, и идет на отсутствующий транзистор.
Который должен стоять разомкнутый когда никакой передачи не идет, и замкнуть это дело на землю, если появляется сигнал.
Соответственно можно предположить что там должен стоять транзистор NPN, эмиттером на землю, коллектором на R6, и базой в сторону микроконтроллера.

Тогда если мы вывели что в состоянии покоя на выходе МК логический ноль, транзистор стоит закрыт, открывается же когда идет передача, и все ок.
Транзистор может быть да фактически любой, структуры npn, и резистор ему надо для скоростей миди ну что-то в районе 10...30к, это не суть как важно, я бы повешал что-то типа 15..27к и успокоился. Китайцы бы 10к воткнули.


Теперь по входу, резистор с пина 7 на землю оптопары не очень нужен на таких скоростях, он вообще в эмиттерном повторителе может включаться для ускорения его работы, но это и снизит чувствительность в свою очередь.
Подтягивающий вверх 470 ом отсутствует скорее всего потому, что на входе микроконтроллера уже есть встроенный подтягивающий "резистор" (там не резистор конечно а структура на чипе), обычно они в районе 20..50к ну разное бывает. Похоже что оно как-то так и работает. Тогда R8 может быть от нуля до... ну может 1к, может больше, точно не знаю что там на входе МК реально. Я бы в общем 470 ом повесил для начала для теста и посмотрел пошло нет.
Как зеленым проводом нарисовано, тоже в принципе получается что можно было бы, но лучше тоже повешать ограничительный резистор какой-нибудь, может 1к или типа того, просто на всякий, мы даже не знаем толерантен ли вход микроконтроллера к 5в, или он может на 3,3 только например.

[Skinny]

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

Так же смущает слегка все-таки отсутствие подтягивающего резистора (который на схемах подключения 1n138 470 ом, хотя там можно больше ставить), потому что когда я пробовал миди с разными оптопарами, конкретно АТМега и стм32 не заводились со внутренней подтяжкой и внешней оптопарой. Но справедливости ради, конкретно 1n138 не пробовал так.

Еще непонятно как мигает светодиод midi in, ну и не совсем понятно нахрена вообще дополнительный транзистор делать, когда у них на плате аж ШЕСТЬ инвертеров, и сделать просто два подряд, чтобы сигнал не переворачивался, и с этого передавать, проще пареной репы.. Так же и собственно не понятно зачем при наличии нескольких инвертеров на плате, иметь разные полярности сигнала на прием и передачу, если оно так... ну выход с активным высоким уровнем а вход с низким.

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


p.p.s ну все что я говорю основано только на этой схеме и так как не факт что она точно правильная, и не факт что я всё углядел верно, то это все гадание на таро)



======

Насчет миди и ардуины - ну вот ардуина это просто софт, а на деле мы имеем обычный микроконтроллер, который точно так же легко програмируется как и любой другой, на любую частоту и протоколы и что хочешь. И вообще предпочитаю свободную работу с последовательным портом, без использования каких-то левых библиотек с кучей ненужной фигни, просто настроил частоту порта 31250 и вперед, шли в UDR что хочешь. Это делается довольно легко прямо из ардуиновского IDE, он воспринимает весь код нормально, как и то что люди используют прямой доступ к портам общего назначения, ну когда пишешь PORTC или PORTD и тд.

Так то да, конечно есть еще куча библиотек для ардуин для работы с миди, разного рода.

[Vladistone]

Спасибо за обьяснение, @Skinny +100500!
я уточнил схему конвертера и внес корректировки (см ниже)
теперь есть понимание по отсутствию элементов R8; R3 и T1 - китайцы обошли эти элементы цепи с помощью U1 hex инвертора таким образом:

• обход зоны 2: сигнал UART OUT идет на U1 pin #1 - #6 благодаря перемычке A1-A3 и далее на R6 и MIDI OUT-

• обход зоны 1: MIDI IN+ после прохождения R7 и галванической развязки U3, идет на U1 pin #11 - #8 (попутно должен цеплять pin #9 для сигнализации светодиода MIDI IN) и далее на UART IN в U2 USB-конвертера.

НО по какой то причине отсутствует перемычка между pin #9-№10 на U1 (цепь обрывается на выходе Y5 pin #10), и при этом есть наличие странной перемычки между pin #13-#14 по питанию +5V промахнулись китайцы наверное? Или все-таки это не 74HC04 ЧИП? А другой, с нехарактерной распиновкой для инвертируемых пар?

И мне не понятен маневр для подключения U1 pin #11 на R2 - это по видимому Pull Up для выходного конца U3 pin #6 ?
в общем, с учетом планирования работы этого конвертора для Arduino мне непонятна сама необходимость гальванической развязки для Arduino Tx при условии, что MIDI IN будет без питания концов со стороны внешнего источника/оборудования для U3 pin #3 как токовой петли оптопары, в принципе (провода на DIN5 MIDI IN и OUT я удалил - отмечены пунктиром для общего понимания. что бы было...)
если есть разумное обьяснение для этой оптопары - дайте знать?

Scheme-it-export-MIDI-1.png

[Vladistone]

добавил в схему необходимость шунтирования pins 9-10 на hex инверторе U1 и прочие замечания:

Scheme-it-export-MIDI-3.png

Еще смущает рекомендация в наличии R на 220 Om (см рис. ниже)
по моей схеме это просто реализуется с подключением +5V от USB к Arduino на выход O+ рядом с R5 (220 Om).
- а там напряжение питания, возможно будет не более +5V и соответствено при прохождении через ограничивающий резистор R5 220 Om - падение напряжения будет еще больше - около 4,7V... тут явно надо подключать Arduino питание напрямую на pin "+5V" минуя R5?! тогда и смысл в наличии R5 как ограничивающего предохранителя от внешнего MIDI источника к цепи U1 Vcc - теряет смысл...(что от чего предохранять? Arduino цепь Vcc или конвертера U1 цепь Vcc от ошибочной коммутации? - непонятно), либо, то что рекомендовано на рисунке - не было реализовано в оригинальной схеме первоисточника идеи

cheapo_midi-usb (2).png

[Vladistone]

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

"...Я все ловлю на лету, но что конкретно ты имела в виду?"
я не уловил мысли - где логический "0" это активные +5V
и где выход с "активным высоким"?
Можно тыкнуть пальцем? please...

Так же смущает слегка все-таки отсутствие подтягивающего резистора (который на схемах подключения 1n138 470 ом, хотя там можно больше ставить), потому что когда я пробовал миди с разными оптопарами, конкретно АТМега и стм32 не заводились со внутренней подтяжкой и внешней оптопарой. Но справедливости ради, конкретно 1n138 не пробовал так.

Еще непонятно как мигает светодиод midi in, ну и не совсем понятно нахрена вообще дополнительный транзистор делать, когда у них на плате аж ШЕСТЬ инвертеров, и сделать просто два подряд, чтобы сигнал не переворачивался, и с этого передавать, проще пареной репы.. Так же и собственно не понятно зачем при наличии нескольких инвертеров на плате, иметь разные полярности сигнала на прием и передачу, если оно так... ну выход с активным высоким уровнем а вход с низким.

- мне это тоже непонятно, но и опыта с такими поделками нет совсем... надо сначала попробывать "поднять" в текущих условиях аппарат, ну а потом экспериментировать с оптопарой и стабильным приемом с pull up на 470 Om...

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

после моих предыдущих корретировок по USB2MIDI конвертору - все встает на свои места:

• на транзисторе сэкономили, и стали использовать все 6 инверторных пар на полную.

======

Насчет миди и ардуины - ну вот ардуина это просто софт, а на деле мы имеем обычный микроконтроллер, который точно так же легко програмируется как и любой другой, на любую частоту и протоколы и что хочешь. И вообще предпочитаю свободную работу с последовательным портом, без использования каких-то левых библиотек с кучей ненужной фигни, просто настроил частоту порта 31250 и вперед, шли в UDR что хочешь. Это делается довольно легко прямо из ардуиновского IDE, он воспринимает весь код нормально, как и то что люди используют прямой доступ к портам общего назначения, ну когда пишешь PORTC или PORTD и тд.

Так то да, конечно есть еще куча библиотек для ардуин для работы с миди, разного рода.

я уже поглядывал в сторону USB/COM конвертера с RS323-сокетом,... мне тоже интересен этот вариант, но думаю - надо добить сначала этот проект, а потом идти дальше, если время будет! тут то и так в 3-х соснах запутался...

[Skinny]

rs-232 как ком-порт оно не надо, там по 15в напряжения, usb-ttl переходники лучше для домашних дел, там 5в обычные и все соединяется по простому.

НУ вот теперь в общем-то понятно что к чему)
да, подтяжка вверх реализуется с помощью R2 судя по всему, пин 13 повешан на плюс питания (соединяя с пин 14) чтобы вход незадействованного инвертера (13-12) не болтался в воздухе, так и рекомендуется либо на плюс либо на землю сажать незадействованные входы, чтобы они не дёргались от наводок или не становились где-то посередине и не грели весь чип. Когда люди на макетке чето делают то пофиг, а в готовый девайс конечно надо неиспользованные входы всегда куда-то подтягивать..

Перемычка 9-10 тогда по идее должна быть, может под чипом и не видно? Получше прозвонить надо, просто тестером на ноги микрухи, есть ли там контакт..

В остальном все как нарисовано в общем-то и должно работать, но не совсем, R7 (его конец который in+) вешается не на Tx ардуины а на +5в. А вот in- уже надо на tx, через дополнительный резистор 220 ом. Потому что ардуина при работе дёргает свой Tx вниз, соответственно ток пойдет с +5в через R7, оптопару, другой резистор и на Tx ардуины и она его будет тягать на землю.

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

Насчет проверки чисто миди-кабеля, ну этого адаптера усби-миди, я бы посоветовал просто подкинуть для начала O+ на I+, O- на I-, ну просто двумя проводками, потом открыть какой-то софт вроде midi-ox, открыть монитор посылаемых данных и принимаемых, и попробовать послать что угодно, какие-то ноты и прочее, посмотреть вернулись ли они. Если вернулись значит в принципе-то все и работает и перемычку 9-10 не надо, там и так как-то соединено.

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

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

[Skinny]

я не уловил мысли - где логический "0" это активные +5V
и где выход с "активным высоким"?
Можно тыкнуть пальцем? please...

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

А выход микроконтроллера наоборот, получается когда ничего не передаётся, висит на низком уровне, и только в момент передачи дёргается вверх, зажигая и светодиод через два инвертора, и соответственно через инвертор 5-6 дёргает резистор R6 вниз, получается инвертор 5-6 приводит это дело к стандарту, дёргания линии вниз а не вверх. А сам микроконтроллер судя по всему имеет на передачу активный уровень - высокий. На передачу одно, на прием-другое. И это слегка странно, но не то чтобы очень.

[Vladistone]

rs-232 как ком-порт оно не надо, там по 15в напряжения, usb-ttl переходники лучше для домашних дел, там 5в обычные и все соединяется по простому.

НУ вот теперь в общем-то понятно что к чему)
да, подтяжка вверх реализуется с помощью R2 судя по всему, пин 13 повешан на плюс питания (соединяя с пин 14) чтобы вход незадействованного инвертера (13-12) не болтался в воздухе, так и рекомендуется либо на плюс либо на землю сажать незадействованные входы, чтобы они не дёргались от наводок или не становились где-то посередине и не грели весь чип. Когда люди на макетке чето делают то пофиг, а в готовый девайс конечно надо неиспользованные входы всегда куда-то подтягивать..

вот теперь и у меня в голове ясность появилась! спасибо!

Перемычка 9-10 тогда по идее должна быть, может под чипом и не видно? Получше прозвонить надо, просто тестером на ноги микрухи, есть ли там контакт..

так все и звонил с помощью тестера... нет там соединения!

[Vladistone]

В остальном все как нарисовано в общем-то и должно работать, но не совсем, R7 (его конец который in+) вешается не на Tx ардуины а на +5в. А вот in- уже надо на tx, через дополнительный резистор 220 ом. Потому что ардуина при работе дёргает свой Tx вниз, соответственно ток пойдет с +5в через R7, оптопару, другой резистор и на Tx ардуины и она его будет тягать на землю.

Спасибо, это тоже меня вводило в ступор по механике срабатывания токовой петли с одним Tx от Arduino, теперь все встало на свои места и мои вопросы по схеме отпадают при подключениии IN+ на +5V а на IN- Tx Arduino

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

Я так и прорисовал последние корретировки по схеме (просто уже довольно много рисунков... но они уже были еще вчера

Scheme-it-export-MIDI-6.png

осталось только исправить подачу питания и реверс Tx на оптопару 6N138 (и понять - чувствительность оптопары с двумя R7 и R10 по 220 Om мы не потерям?) и добить выход pin-6 через 7404 на UART IN - так как там нерабочая схема выходит без перемычки 9-10 (иначе оставить так то, даже огонек "MIDI IN" не будет маяковать нам об этом!)
Но и смысл гальванической развязки я тут не вижу!... достаточно одного инвертора для буфера и согласования по полярности микросхем Arduino и USB-конвертера...

[Skinny]

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

А гальваническая развязка да если уже вся схема кабеля отрисована то так-то особо и нет смысла))) смысл есть когда питания у двух девайсов раздельные.. очень удобно, точно нет никаких петель. ну по стандарту миди так решили, и хорошо решили..
Видел любительские конструкции на микроконтроллерах где не было никакой развязки вообще, и питание тоже бралось с 5в которые есть на миди разъеме..
Развязка еще дает некоторую такую надежность, типа, у тебя есть два девайса, и если на одном из них питание включено а на другом нет, ничего страшного не случится, ток не пойдет через вход и защитные диоды внутри микросхемы и не будет пытаться запитать всю схему от сигнала и тд, как бывает...
Опять же если вариант именно с транзистором, по типу открытого коллектора (коллектор не приделан никуда, кроме как к резистору 200 ом), то это еще и очень дубовый вариант в плане статики и прочего, выход получается открытый коллектор на обычном кремниевом почти неубиваемом транзисторе, а вход - опять же оптрон, защищенный и двумя резисторами и встречным диодом, то есть тоже практически неубиваемый вход.... нет ни полевиков ни чувствительных каких-то пинов микроконтроллеров, всё дубово и надежно. вот из этих соображений оно всё было сделано, это очень годный интерфейс получается.

[Vladistone]

собрал сегодня схему, происходит следующее:
Первое что подключаем это сокет питания от USB2MIIDI конвертера к Arduino, без подсоединения TxRx сокета:
- у меня сразу загорается LED PWR на Arduino Nano и LED L - показывает наличие постоянных импульсов (подумал сразу на MIDI clock, но фактически - еще TxRx не подсоедены, поэтому не знаю, что это такое ("операционная сигнализация" на " L" Arduino)
вторым этапом подключаем TxRx разьем к Arduino - сразу получаю хороший Hight level на LED MIDI после U1 через инвертор A5-Y5 (Tx Arduino выдает logic "0" как Hight level тем самым "запирая" токовую петлю и следовательно - это воспринимается как отсутсвие сигнала или logic "0"), а инвертируемый импульс на LED MIDI IN и UARD IN USB-конвертера тоже идет Logic "1" (что в принципе Good! Но сбивает с толку кривое подключение через всего один инвертер на LED MIDI IN (его бы похорошему отправить на еще один инвертер - точно так же как реализовали на LED MIDI OUT по цепочке A1-Y1=A2-Y2, и тем более что у китацев осталcя в запасе тот самый последний A6-Y6, который они "бросили" на +5V шунтом Pin 13-14)

like this.PNG

Хотя вот тут я вспомнил что дополнительного R на 470 Om у меня в цепи конвертера нет существует,..
Ну а по факту - Arduino так же сигнализирует своими LED Tx и Rx - что сигнал транслируется так же как ниже-описанный:

решил сразу изменить "правила игры" и запитать Arduino от собственного USB-порта, отлючив при этом питание от конвертера,
Схема заработала! я Вижу отправку сигналов и его возвращение на USB-конвертер, но к сожалению - это 1:1 сигнал (без программной конвертации CC# в SysEx согласно кода:

Код: Выделить всё

// Korg EX/DW-8000 and DSS-1 MIDI Enhancer
// By Steve Baines 2016 mode by Vladistone 2023
// See:
// https://hackaday.io/

#include <MIDI.h>

// Create MIDI interface on main hardware serial port
// (Tx/Rx pins on Arduino board)
MIDI_CREATE_DEFAULT_INSTANCE();


// -----------------------------------------------------------------------------

// This function will be automatically called when a NoteOn is received.
// It must be a void-returning function with the correct parameters,
// see documentation here:
// http://arduinomidilib.fortyseveneffects.com/a00022.html

const int ledPinOut = 13;

// 0 here is 1 on DW-8000 - need to set Param 83 to 1
const int dwChannel = 1;

// Also need to set Param 84 to 2, otherwise SYSEX messages are ignored.

void sendDw8000Param(byte channel, byte paramOffset, byte paramValue7Bit)
{
  const int sysexLen = 8;
  static byte sysexData[sysexLen] = { 
    0xf0,   // 0 Sysex start
    0x42,   // 1 Manufacturer ID: 42, Korg
    0x30,   // 2 Channel 1
    0x0b,   // 3 Device ID: 03, for EX/DW-8000; 0b - for DSS-1
    0x41,   // 4 Message: 41, Parameter change
    0x00,   // 5 Parameter Offset number (which parameter we want to change)
    0x00,   // 6 Parameter value
    0xf7    // 7 Sysex end
  };

  // paramValue7Bit is assumed to run from 0 to 127 in all cases, 
  paramValue7Bit &= 0x7f;


#if(0)
    case 0: // OSC 1 Octave (2b)
    case 1: // OSC 1 Waveform (4b)
    case 2: // OSC 1 Level (5b)
    case 3: // Auto Bend Select (2b)
    case 4: // A. Bend Mode (1b)
    case 5: // A. Bend Time (5b)
    case 6: // A. Bend Intensity (5b)
    case 7: // OSC 2 Octave (2b)
    case 8: // OSC 2 Waveform (4b)
    case 9: // OSC 2 Level (5b)
    case 10: // Interval (3b)
    case 11: // Detune (3b)
    case 12: // Noise Level (5b)
    case 13: // Assign Mode (2b)
    case 14: // Parameter No. Memory (6b)
    case 15: // Cutoff (6b)
    case 16: // Resonance (5b)
    case 17: // Keyboard Tracking (2b)
    case 18: // Polarity (1b)
    case 19: // EG. Intensity (5b)
    case 20: // VCF Attack (5b)
    case 21: // VCF Decay (5b)
    case 22: // VCF Breakpoint (5b)
    case 23: // VCF Slope (5b)
    case 24: // VCF Sustain (5b)
    case 25: // VCF Release (5b)
    case 26: // VCF Velocity Sensitivity (3b)
    case 27: // VCA Attack (5b)
    case 28: // VCA Decay (5b)
    case 29: // VCA Breakpoint (5b)
    case 30: // VCA Slope (5b)
    case 31: // VCA Sustain (5b)
    case 32: // VCA Release (5b)
    case 33: // VCA Velocity Sensitivity (3b)
    case 34: // MG Waveform (2b)
    case 35: // MG Frequency (5b)
    case 36: // MG Delay (5b)
    case 37: // MG OSC (5b)
    case 38: // MG VCF (5b)
    case 39: // Bend OSC (4b)
    case 40: // Bend VCF (1b)
    case 41: // Delay Time (3b)
    case 42: // Delay Factor (4b)
    case 43: // Delay Feedback (4b)
    case 44: // Delay Frequency (5b)
    case 45: // Delay Intensity (5b)
    case 46: // Delay Effect Level (4b)
    case 47: // Portamento (5b)
    case 48: // Aftertouch OSC MG (2b)
    case 49: // Aftertouch VCF (2b)
    case 50: // Aftertouch VCA (2b)
#endif

  // so here we rescale to fit to appropriate bit width for each parameter
  byte paramValueScaled = 0;
  switch (paramOffset)
  {
    case 4: // A. Bend Mode (1b)
    case 18: // Polarity (1b)
    case 40: // Bend VCF (1b)
      paramValueScaled = paramValue7Bit >> 6;
      break;

    case 0: // OSC 1 Octave (2b)
    case 3: // Auto Bend Select (2b)
    case 7: // OSC 2 Octave (2b)
    case 13: // Assign Mode (2b)
    case 17: // Keyboard Tracking (2b)
    case 34: // MG Waveform (2b)
    case 48: // Aftertouch OSC MG (2b)
    case 49: // Aftertouch VCF (2b)
    case 50: // Aftertouch VCA (2b)
      paramValueScaled = paramValue7Bit >> 5;
      break;

    case 10: // Interval (3b)
    case 11: // Detune (3b)
    case 26: // VCF Velocity Sensitivity (3b)
    case 33: // VCA Velocity Sensitivity (3b)
    case 41: // Delay Time (3b)
      paramValueScaled = paramValue7Bit >> 4;
      break;

    case 1: // OSC 1 Waveform (4b)
    case 8: // OSC 2 Waveform (4b)
    case 39: // Bend OSC (4b)
    case 42: // Delay Factor (4b)
    case 43: // Delay Feedback (4b)
    case 46: // Delay Effect Level (4b)
      paramValueScaled = paramValue7Bit >> 3;
      break;

    case 2: // OSC 1 Level (5b)
    case 5: // A. Bend Time (5b)
    case 6: // A. Bend Intensity (5b)
    case 9: // OSC 2 Level (5b)
    case 12: // Noise Level (5b)
    case 16: // Resonance (5b)
    case 19: // EG. Intensity (5b)
    case 20: // VCF Attack (5b)
    case 21: // VCF Decay (5b)
    case 22: // VCF Breakpoint (5b)
    case 23: // VCF Slope (5b)
    case 24: // VCF Sustain (5b)
    case 25: // VCF Release (5b)
    case 27: // VCA Attack (5b)
    case 28: // VCA Decay (5b)
    case 29: // VCA Breakpoint (5b)
    case 30: // VCA Slope (5b)
    case 31: // VCA Sustain (5b)
    case 32: // VCA Release (5b)
    case 35: // MG Frequency (5b)
    case 36: // MG Delay (5b)
    case 37: // MG OSC (5b)
    case 38: // MG VCF (5b)
    case 44: // Delay Frequency (5b)
    case 45: // Delay Intensity (5b)
    case 47: // Portamento (5b)
      paramValueScaled = paramValue7Bit >> 2;
      break;

    case 14: // Parameter No. Memory (6b)
    case 15: // Cutoff (6b)
      paramValueScaled = paramValue7Bit >> 1;
      break;

    default:
    return; // Unknown parameter - ignore
 }
  
  sysexData[2] = 0x30 | (channel & 0x0f); // Set channel number
  sysexData[5] = paramOffset;
  sysexData[6] = paramValueScaled;
  
  MIDI.sendSysEx(sysexLen, sysexData, true);
}



void handleNoteOn(byte channel, byte pitch, byte velocity)
{
    // Do whatever you want when a note is pressed.
    digitalWrite(ledPinOut, HIGH);   // turn the LED on
    MIDI.sendNoteOn(pitch, velocity, channel);
}


void handleNoteOff(byte channel, byte pitch, byte velocity)
{
    // Do something when the note is released.
    // Note that NoteOn messages with 0 velocity are interpreted as NoteOffs.
    digitalWrite(ledPinOut, LOW);    // turn the LED off
    MIDI.sendNoteOff(pitch, velocity, channel);
}


void handleControlChange(byte channel, byte number, byte value)
{
  if (channel != dwChannel)
  { // If CC not sent to DW-8000 channel, then just pass them on
    MIDI.sendControlChange(number, value, channel);
    return;
  }

  // Map from received CC numbers to corresponding DW-8000 Parameter offset numbers
  switch(number)
  {
    //   CC number                    Param. Offset
    //   ||                           ||
    // Mappings to common CCs: (See http://nickfever.com/music/midi-cc-list)
    case  5: sendDw8000Param(channel, 47, value); break; // Portamento Time
    case 70: sendDw8000Param(channel,  1, value); break; // (Sound Variation) OSC1 Waveform
    case 71: sendDw8000Param(channel, 16, value); break; // Resonance
    case 72: sendDw8000Param(channel, 32, value); break; // VCA Release
    case 73: sendDw8000Param(channel, 27, value); break; // VCA Attack
    case 74: sendDw8000Param(channel, 15, value); break; // Cutoff Freq

    // Arbitrary mappings from generic CCs to remaining params
    case 75: sendDw8000Param(channel, 34, value); break; // MG Waveform (2b)
    case 76: sendDw8000Param(channel, 35, value); break; // MG Frequency (5b)
    case 77: sendDw8000Param(channel, 36, value); break; // MG Delay (5b)
    case 78: sendDw8000Param(channel, 37, value); break; // MG OSC (5b)
    case 79: sendDw8000Param(channel, 38, value); break; // MG VCF (5b)

    case 16: sendDw8000Param(channel,  3, value); break; // Auto Bend Select (2b)
    case 17: sendDw8000Param(channel,  4, value); break; // A. Bend Mode (1b)
    case 18: sendDw8000Param(channel,  5, value); break; // A. Bend Time (5b)
    case 19: sendDw8000Param(channel,  6, value); break; // A. Bend Intensity (5b)

    case 20: sendDw8000Param(channel, 20, value); break; // VCF Attack (5b)
    case 21: sendDw8000Param(channel, 21, value); break; // VCF Decay (5b)
    case 22: sendDw8000Param(channel, 22, value); break; // VCF Breakpoint (5b)
    case 23: sendDw8000Param(channel, 23, value); break; // VCF Slope (5b)
    case 24: sendDw8000Param(channel, 24, value); break; // VCF Sustain (5b)
    case 25: sendDw8000Param(channel, 25, value); break; // VCF Release (5b)
    case 26: sendDw8000Param(channel, 26, value); break; // VCF Velocity Sensitivity (3b)
    case 27: sendDw8000Param(channel, 28, value); break; // VCA Decay (5b)
    case 28: sendDw8000Param(channel, 29, value); break; // VCA Breakpoint (5b)
    case 29: sendDw8000Param(channel, 30, value); break; // VCA Slope (5b)
    case 30: sendDw8000Param(channel, 31, value); break; // VCA Sustain (5b)
    case 31: sendDw8000Param(channel, 33, value); break; // VCA Velocity Sensitivity (3b)

    case 85: sendDw8000Param(channel, 41, value); break; // Delay Time (3b)
    case 86: sendDw8000Param(channel, 42, value); break; // Delay Factor (4b)
    case 87: sendDw8000Param(channel, 43, value); break; // Delay Feedback (4b)
    case 88: sendDw8000Param(channel, 44, value); break; // Delay Frequency (5b)
    case 89: sendDw8000Param(channel, 45, value); break; // Delay Intensity (5b)
    case 90: sendDw8000Param(channel, 46, value); break; // Delay Effect Level (4b)
    case 102: sendDw8000Param(channel, 0, value); break; // OSC 1 Octave (2b)
    case 103: sendDw8000Param(channel, 2, value); break; // OSC 1 Level (5b)
    case 104: sendDw8000Param(channel, 7, value); break; // OSC 2 Octave (2b)
    case 105: sendDw8000Param(channel, 8, value); break; // OSC 2 Waveform (4b)
    case 106: sendDw8000Param(channel, 9, value); break; // OSC 2 Level (5b)
    case 107: sendDw8000Param(channel, 10, value); break; // Interval (3b)
    case  94: sendDw8000Param(channel, 11, value); break; // Detune (3b)
    case 109: sendDw8000Param(channel, 12, value); break; // Noise Level (5b)
    case 110: sendDw8000Param(channel, 13, value); break; // Assign Mode (2b)
    case 111: sendDw8000Param(channel, 14, value); break; // Parameter No. Memory (6b)
    case 112: sendDw8000Param(channel, 17, value); break; // Keyboard Tracking (2b)
    case 113: sendDw8000Param(channel, 18, value); break; // Polarity (1b)
    case 114: sendDw8000Param(channel, 19, value); break; // EG. Intensity (5b)
    case 115: sendDw8000Param(channel, 39, value); break; // Bend OSC (4b)
    case 116: sendDw8000Param(channel, 40, value); break; // Bend VCF (1b)
    case 117: sendDw8000Param(channel, 48, value); break; // Aftertouch OSC MG (2b)
    case 118: sendDw8000Param(channel, 49, value); break; // Aftertouch VCF (2b)
    case 119: sendDw8000Param(channel, 50, value); break; // Aftertouch VCA (2b)


#if(0)
CC       Param Offset
102    case 0: // OSC 1 Octave (2b)
70    case 1: // OSC 1 Waveform (4b)
103    case 2: // OSC 1 Level (5b)
16    case 3: // Auto Bend Select (2b)
17    case 4: // A. Bend Mode (1b)
18    case 5: // A. Bend Time (5b)
19    case 6: // A. Bend Intensity (5b)
104    case 7: // OSC 2 Octave (2b)
105    case 8: // OSC 2 Waveform (4b)
106    case 9: // OSC 2 Level (5b)
107    case 10: // Interval (3b)
94    case 11: // Detune (3b)
109    case 12: // Noise Level (5b)
110    case 13: // Assign Mode (2b)
111    case 14: // Parameter No. Memory (6b)
74    case 15: // Cutoff (6b)
71    case 16: // Resonance (5b)
112    case 17: // Keyboard Tracking (2b)
113    case 18: // Polarity (1b)
114    case 19: // EG. Intensity (5b)
20    case 20: // VCF Attack (5b)
21    case 21: // VCF Decay (5b)
22    case 22: // VCF Breakpoint (5b)
23    case 23: // VCF Slope (5b)
24    case 24: // VCF Sustain (5b)
25    case 25: // VCF Release (5b)
26    case 26: // VCF Velocity Sensitivity (3b)
73    case 27: // VCA Attack (5b)
27    case 28: // VCA Decay (5b)
28    case 29: // VCA Breakpoint (5b)
29    case 30: // VCA Slope (5b)
30    case 31: // VCA Sustain (5b)
72    case 32: // VCA Release (5b)
31    case 33: // VCA Velocity Sensitivity (3b)
75    case 34: // MG Waveform (2b)
76    case 35: // MG Frequency (5b)
77    case 36: // MG Delay (5b)
78    case 37: // MG OSC (5b)
79    case 38: // MG VCF (5b)
115    case 39: // Bend OSC (4b)
116    case 40: // Bend VCF (1b)
85    case 41: // Delay Time (3b)
86    case 42: // Delay Factor (4b)
87    case 43: // Delay Feedback (4b)
88    case 44: // Delay Frequency (5b)
89    case 45: // Delay Intensity (5b)
90    case 46: // Delay Effect Level (4b)
 5    case 47: // Portamento (5b)
117    case 48: // Aftertouch OSC MG (2b)
118    case 49: // Aftertouch VCF (2b)
119    case 50: // Aftertouch VCA (2b)
#endif
          
    default:
      // If not explicitly remapped, pass on
      MIDI.sendControlChange(number, value, channel);
      break;      
  }
}

void handleProgramChange(byte channel, byte number)
{
  MIDI.sendProgramChange(number, channel);  
}

void handleAfterTouchChannel(byte channel, byte pressure)
{
  MIDI.sendAfterTouch(pressure, channel);  
}

void handlePitchBend(byte channel, int bend)
{
  MIDI.sendPitchBend(bend, channel);  
}

void handleSystemExclusive(byte* arrayData, unsigned arrayLen)
{
  MIDI.sendSysEx(arrayLen, arrayData, false);
}

// -----------------------------------------------------------------------------

void setup()
{
    // initialize digital pin with LED as an output.
    pinMode(ledPinOut, OUTPUT);
    digitalWrite(ledPinOut, LOW);    // turn the LED off by making the voltage LOW

    // Connect the handleNoteOn function to the library,
    // so it is called upon reception of a NoteOn.
    MIDI.setHandleNoteOn(handleNoteOn);  // Put only the name of the function

    // Do the same for NoteOffs
    MIDI.setHandleNoteOff(handleNoteOff);

    MIDI.setHandleControlChange(handleControlChange);

    MIDI.setHandleProgramChange(handleProgramChange);
    MIDI.setHandleAfterTouchChannel(handleAfterTouchChannel);
    MIDI.setHandlePitchBend(handlePitchBend);
    MIDI.setHandleSystemExclusive(handleSystemExclusive);
    
    // Initiate MIDI communications, listen to all channels
    MIDI.begin(MIDI_CHANNEL_OMNI);
    MIDI.turnThruOff(); // Prevent passthrough
}

void loop()
{
    // Call MIDI.read the fastest you can for real-time performance.
    MIDI.read();

    // There is no need to check if there are messages incoming
    // if they are bound to a Callback function.
    // The attached method will be called automatically
    // when the corresponding message has been received.
}

попытался исправить первое что пришло в голову - MIDI-канал с 0 на 1 (23 строка кода), так как у меня везде по MIDI-мониторам проходит как CC channel 1

Код: Выделить всё

/ 0 here is 1 on DW-8000 - need to set Param 83 to 1
const int dwChannel = 1;

но тоже не привело к оживлению программы и пока это все результаты...
Может при питании Arduino от USB-порта комптютер перехватывает управление Arduino и не дает использовать его TxRx по программному назначению? наврятли...

UPD:
обнаржил еще пару симптомов у USB2MIDI конвертера и Arduino:
- при отключении питания вообще от Arduino, и только соединения TxRx - концов = передача импульсов MIDI все равно происходит (это видно по миганию LED MIDI OUT и IN - но на омпьютер MIDI не возвращаются... я так понимаю это присходит в loop режиме через Arduino Rx2Tx прикольно! но это говорить лишь о галванической связке Rx-Tx и кривой сборке USB2MIDI конвертера
- Arduino получает отдельное USB-питание лишь при контакте железа штекера с розеткой mini-USB, то есть на корпусе USB-розетки уже имеется +5V потенциал, при подключении лишь TxRx сокета. То есть это это Hight level прилетает на землю с Rx-сокета? или ождновременно с Tx тоже через светодиод оптопары?

[Skinny]

Не совсем понял про питание, но вообще если питание не соединено, а сигнальные линии соединены, ну в данном случае выход платы конвертера, и Rx вход ардуины, то при высоком уровне на этом пине, получается так:

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

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

Входы современных микросхем обычно сделаны так:
https://scienceprog.com/wp-content/uplo ... ection.png

соответственно он может запитываться через внутренний защитный D1, если на входе появляется напряжение а сам МК не питается больше ни от чего...


Ну а по поводу когда - это надо смотреть этот код, библиотеки и прочее, но вообще миди канал 0 это на самом деле и есть 1, для нас для людей каналы пронумеровали 1-16, а в реальности в байтах там 0-15..

[Vladistone]

Прошедшая неделя прошла в осваивании кодинга, анализе MIDI implementation chart для Korg DW8000 VS DSS-1 и... хотел сказать адаптировании, но рука не поднимается - переписывании почти всего code, а именно таблицы соотвествия CC#2SysEx в коде, так как оригинальная для DW8000 не соотвествовала SysEx для DSS-1 на 99,9%...
Но на этом приключения не закончились. в итоге оказалось что я "подпалил" рабочий Arduino Nano и это не сразу обнаружилось... ну хоть прояснил ситуацию, и пришлось сливать и проверять обновленный code "на коленках" Arduino UNO. здесь все прояснилась и ясно пока то что код - нерабочий, надо искать баги... Но без USB2MIDI адаптера - это никак не прояснить...

А в этом "слабом звене" у меня до сих пор есть сомнения, озвучиваю:
при текущей схеме изменений и при подключении Arduino у нас сразу загорается LED IN:
- то есть с Tx Arduino находится в покое и приходит "0", это запускает оптопару 6N138 которая подтягивает "0" на контакты R2 и вход инвертора A5-Y5, поэтому на Y5 выдает +5V и из-за перемычки между Y5-A4 идет на LED MIDI IN (как бы неправильно, но как есть! - LED сигналит об отсутсвии сигнала на MIDI IN, а было бы DIN5 и наличие +5V на R10 как стандарт протокола MIDI - то было бы все наоборот - два +5V не давали бы оптопаре запуститься).
Но идем далее по схеме U1 74CH04 - идет повторное инвертирование с A4-Y4 и с pin 8 U1 опять идет "0" на UART IN...

поэтому у меня вопрос - а правильно ли будет работать "обратная половина" инвертора U2? обрабатывая сигнал MIDI IN с Arduino Tx в USB на комп.?
так как по "прямой" схеме данного интерфейса USB-MIDI до MIDI OUT импульсы инвертируются только 1 раз (через A3-Y3 у 74CH04), а в "обратную сторону" ч/з цепочку A5-Y5-A4-Y4 - 2 раза!

или все должно быть с точностью наоборот для работы с Arduino без MIDI-shield и подпиткой +5V на Pin 4 MIDI разьемов DIN5, которые мы удалили?
- может быть, что сигнал с UART OUT неправильно доходит до Arduino Rx в инвертируемом виде, поэтому он ничего не генерит для обработки СС№#2SysEx, но при этом NOTE ON/OFF и СС1; 2 и 7 -исправно исполняются на DSS-1 согласно вот этим стат.данным/specs Korg DSS-1

[Skinny]

Можно проверить для начала просто тестером, когда ардуина не подключена к этому миди-адаптеру, но прошивка залита и работает, но данные не передаются когда, там реально на TX висит 0 или как? Это как бы не нормально если так. Должно около 5в висеть. Может в коде какой-то косяк и порт или пин нормально не инициализируется, может выход подпалённый или что-то....

Две инверсии это все равно что без инверсии с точки зрения полярности сигнала, ну и там есть вариант включения через R8 которого нет, если бы через это место шло, то как раз было бы без инверсии... вроде и логично.

То что на выходе только одна инверсия а на входе две - это я про это и говорил, что у чипа этого адаптера на входе и выходе полярность как бы разная, один active low второй active high, и это странно, но не то чтобы сильно странно, видимо так чип сделан..

[Vladistone]

Можно проверить для начала просто тестером, когда ардуина не подключена к этому миди-адаптеру, но прошивка залита и работает, но данные не передаются когда, там реально на TX висит 0 или как?

- при подключении от USB (без подключения к MIDI интерфейсу) - в покое Arduino выдает на Tx и Rx стабильный HiGH

То что на выходе только одна инверсия а на входе две - это я про это и говорил, что у чипа этого адаптера на входе и выходе полярность как бы разная, один active low второй active high, и это странно, но не то чтобы сильно странно, видимо так чип сделан..

знать бы что это за ЧИП такой и по даташиту пробить - не было б проблем, а так - "гадай на кофейной гуще", Но факт остается тот, что в хорошие то времена (до upgrade) этот USB2MIDI интерфейс не выдавал из MIDI-IN ничего (но могу ошибаться - так как уже мог подзабыть причину его неработоспособности и нахождении в отстойнике как нерабочий). проверить бы заново его...
кстати! отпаял шунт Y5-A4 на U1 (74HC04) - а LED IN - остается гореть - вероятно в жтом месте и был непропай и его контакт был восстановлен после upgrade и постановки шунта там нде должно быть заводское подсоединение...
но по логике вещей - и с оглядкой на подобное оборудование - могли ли китайцы изготовить этот интерфейс на базе "иноходца"? с разными по поведению I/O UART? для чего же они так скрывали жлементную базу от всего мира?

[Skinny]

Ну там микроконтроллер какой-то, и какая в нем прошивка - кто его знает, соответственно поведение его UART будет зависеть от прошивки. По стандарту Active Low, те кто писали код вход могли так и запрограммировать, тем более что с оптопары так и идёт, а выход сделать Active High чтобы обойтись одним лишь транзистором, который всё равно при использовании переворачивает сигнал. То есть в этом есть некоторая логика.. И так можно построить интерфейс без этого инвертора. Потом скорее всего китайцы стали что-то изобретать и засунули таки инвертор туда. А код на МК остался старый, потому что возможно это уже давно Mask ROM для удешевления, и его в принципе не перепрошить.

[SGA]

Пардонте. А есть тут тема про атари панк?
Думаю собрать, но не знаю какой выбрать вариант.

[Vladistone]

Пардонте. А есть тут тема про атари панк?
Думаю собрать, но не знаю какой выбрать вариант.

Безпардонте! А чем можем помочь сеим возможностями arduino и MIDI CC message's?

[SGA]

Это ж очевидно. Разве нет?

[Walli]

У меня не динозавр, но сравнительно свежий Роланд, возможно ли переключать двухкнопочным ардуино нужные пресеты по кругу?
Piano
No.|Name |MSB|LSB|PC
--------------------------------------------
1 |Concert Piano | 0| 68| 1
2 |Ballad Piano | 16| 67| 1
3 |Mellow Piano | 4| 64| 1
4 |Bright Piano | 8| 66| 2
5 |Upright Piano | 16| 64| 1
6 |Mellow Upright | 1| 65| 1
7 |Bright Upright | 1| 66| 1
8 |Rock Piano | 8| 64| 3
9 |Ragtime Piano | 0| 64| 4
10 |Magical Piano | 47| 65| 3
11 |Harpsichord | 0| 67| 7
12 |Harpsi 8'+4' | 8| 67| 7

[Skinny]

Конечно можно. Если вопрос в том как передать по кругу несколько совершенно разных параметров, то можно использовать struct.

Например, в сетапе пишешь

Код: Выделить всё

    struct pres{                  // создали тип данных pres (как шаблон)
        string name;            // типы переменных и их названия могут быть любыми
        int something1;       // я просто показываю что можно хранить одновременно и int и string
        int something2;
        int something3;
    };
    
    pres presets[12];          // сделали массив из 12ти таких шаблонов

    presets[0].name = "ololo";              // заполняем все нужные поля как нам хочется
    presets[0].something1 = 123;
    presets[0].something2 = 234;
    presets[0].something3 = 456;
    
    presets[1].name = "gsom gsom";
    presets[1].something1 = 987;
    presets[1].something2 = 654;
    presets[1].something3 = 321;
    
    ..... и так далее до [11]

Доступ до отдельного значения идёт через точку, понятно..
И важно не забыть что массив начинается с нуля, хотя бы объявляли [12] штук вначале, доступ до элементов будет от [0] до [11].

Можно конечно и слегка по-другому сделать, но мне кажется так нагляднее..

Дальше уже где-то в коде, который будет запускаться при нажатии кнопки, пишем примерно так:

Код: Выделить всё

    static int counter = 0;
    
    Serial.println(presets[counter].name);            // Ну в данном случае мы просто выводим все на экран
    Serial.println(presets[counter].something1);   // Какое сейчас значение переменной counter, те ячейки и будут выводиться
    Serial.println(presets[counter].something2);
    Serial.println(presets[counter].something3);
    
    counter++;
    if(counter > 11) counter = 0;          // следим чтоб не вышло за рамки, прокручивалось только 12 значений от 0 до 11

P.S. Код не чекал, но вроде все правильно))

[Walli]

Спасибо, щас попробую!

[Vladistone]

Всех неугомонных участников форума с наступившим НГ!
Надеюсь у вас все GOOD! и в этом году будет много плюшек и новых "буратин"!
Хочу поделиться тем, что наваял за последнее время, хотя много отвлекался и где то "застрял" на Github в описательном процессе чипирования Arduino в свое железо

Если у кого будут вопросы или предложения по выравниванию моего "корявого машинного перевода" и соответствующего англоязычного текста redme.adoc в качестве пояснительной записки - буду признателен за помошь и постараюсь допилить manual (если он еше будет актуален кому-то... ибо инострацы с Gearspace.com как то не поддержали мою просьбу в поиске носителя языка для адаптации и редакции текста in English, да и бог с ними = флаг им в руки и барабанные палочки

0C302D68-D2CD-41DA-AF40-E11C7B7D5E49.jpeg

после празднования НГ получил посылку с blueSCSI для чипирования в Yamaha EX5R и Kurzweil K2000R - вот сижу гадаю; с какого бока к этим чипам подходить? вроде бы для K2000R есть внятные видео по апгрейду, но они для SCSI2SD и я никак не пойму - чем конфигурить SD для blueSCSI в моем случае... кто подскажет и натолкнет в правильном направлении? help

image.jpg

[SGA]

У Меня Блюскази первой модификации. Подключил на внутренний шлейф винта в Ему Е4к. И вывел наружу. Висит сзади на шлейфе. Питание от блока питания взял. Залил туда несколько образов сидиромов. И толком не использую.

[Vladistone]

У Меня Блюскази первой модификации. Подключил на внутренний шлейф винта в Ему Е4к. И вывел наружу. Висит сзади на шлейфе. Питание от блока питания взял. Залил туда несколько образов сидиромов. И толком не использую.

Если я правильно понял, изучая blueSCSI, то первое что надо сделать:
1. просто скачать любой требуемый image для планируемой работы в качестве HD для тон генератора, или использовать Disk Jockey приложение для формирования списка devices которые потом грузятся на SD-карту простым перетаскиванием.
2. далее эту SD-карту вставляем в слот blueSCSI и все монтируется в яшик.
2.1. загвоздка только в том - что пока я не нашел информацию об необходимом power supply: требуется одновременно и 5V и 12V (как это расписано на плате и практика требует наличие 12V в т.ч.) или для этих микро-устройств достаточно лишь 5V питалова, которое можно без труда дублировать со слота FDD? ( к примеру для курца K2000R - он уже идет без провода на 12V), а в других машинах бывет и еще надо менять сокет или испоьзовать переходники MOLEX/FDD power - этим к примеру озадачен при вскрытии раб. станции Yamaha AW4416, что бы попробывать заменить CD на эмуляцию BlueSCSI2CD (опять же - либо паяльник доставать, так как магазины в эти дни на длинных выходных)
3. Если все сделано правильно и нет конфликтов со SCSI ID и терминацией, то при запуске K2000R он потребует проформатировать созданные/"подключенные" внутренние HD-эмуляцию и вуаля...

пока все зависло на серфинге по данным питалова...
ЗЫ: но судя по вашему фото - 12Vконец отсутсвует,.. значит только 5V требуется?