USB-MIDI-Controller auswerten und in eigener Elektronik weiternutzen

T

technoreinhard

Registriert
16.08.04
Beiträge
218
Reaktionen
32
Ort
Taunus
Punkte
329
Ich würde gerne USB-Controller zum Steuern von Pseudoanalogwerten und Schalterzuständen nutzen. Die externen Knöpfe sollen Potentionmeter und andere Eingabepanels in Selbstbauelektronik ersetzen. Auch ist Haustechnik angedacht. Warum das Ganze?

Ich möchte eine Steuereinheit haben, die ich flexibel zusammenstellen kann, ohne zu große Änderungen oder gar Umbauten zu haben. Diese Controller sind zwar primär für Musik gedacht, erfüllen aber diesen speziellen Zweck, da in unterschiedlichen Ausführungen verfügbar, leicht zu ersetzen und preisgünstig, weil sie in großer Stückzahl produziert werden.

Außerdem kommt man an solche Funktionen mit beleuchtbaren Tastern und einfacher Programmiermöglichkeit nicht ran, oder man muss selber bauen, was für Kleinserie nicht geht. Industrielle Systeme für HMI kosten gleich 1000,- für Tastersysteme mit Rückmeldung und sind nur in Sonderanfertigung und größeer Stückzahl lieferbar.

Die neueren Geräte haben aber bekanntlich kein einfach auzuwertendes MIDI mehr, sondern einen USB Ausgang. Leider ist USB nicht so mein Fachgebiet. Ich bin außerhalb der Musik eher eher Analog-Elektroniker.

Kennt sich jemand damit aus, wie man das machen könnte?
 
Ich habe dazu unterschiedliche Quellen durchgesehen, um mich zu informieren. Als Zusammenfassung kann festgehalten werden:

- Es muss ein MIDI-host auf einem Zielsystem aufgebaut werden, der USB-MIDI Geräte automatisch erkennen kann.
- Dazu müssen das device (Eingabeinstrument) und der host (Empfangsgerät) "class compliant" sein.
- Das Empfangsgerät muss die USB-Clients verwalten können und auseinander halten können
- Laut Berichte in Musikforen vertragen sich Geräte unterschiedlicher Hersteller nicht immer miteinander
- Geräte sind nicht in beliebiger Zahl kaskadierbar, auch wenn die Bandbreite reichen müsste.

Von Seiten der Hersteller solcher Controller scheint es nur fertige Treiber zu geben, die für Windows/Linux gemacht sind und sich nur auf einem passenden System nutzen lassen. Tablet fiele mir ein, ist aber zu aufwändig und hat keine gute Schnittstelle zu eigener Elektronik

Ich habe das Net durchgeschaut, finde aber nur Sonderanwendungen/Elektronik mit hosts, die zwar solche Controller auslesen können, diese aber nicht in einem auswertbaren Format ausreichender Bandbreite zur Verfügung stellen:

USB-MIDI-host:
http://www.hobbytronics.co.uk/usb-host-midi
Der wird nicht mehr produziert, passt auch nicht für alle Geräte und übersetzt nur auf MIDI. Dasselbe macht dieses Profigerät:
https://kentonuk.com/product/midi-usb-host-mkii/

Hier hat jemand ein solches Keyboard (KORG Nano) auf MIDI übersetzt:
https://github.com/larsks/python-siggen

Es scheint also irgendwie recht einfach(?), oder mit wenig Controllertechnik möglich, wenigstens einen Kanal anzuschließen. Die Lösungen müssten nur so verändert werden, dass die Daten parallel oder sehr viel schneller herauskommen.

Zum Tempo:

USB-MIDI-Geräte senden im Allgemeinen die Daten paketweise, minimal innerhalb eines frames. Die Dauer beträgt laut anderer Quelle mindestens 2us (USB2) bzw. 70us + etwas negitation. Ausgehend von einem langsamen Controller (100us total) könnte ich also in 1ms 10 Kanäle übertragen. Dass die Controller bei Musikanwendungen oft verspätet wahrgenommen werden, liegt an der Windowslatenz von bis zu 8ms. Da ich 16 Controller parallel benutzen möchte, brauche ich entweder einen USB-Hub oder 16 Eingänge. Unabhängig davon sollten die Controller-Daten mit unter 1ms ausgeben werden können. Bei 10 gleichzeitigen Informatioen also wieder in 100us.

Lösung: Ich würde gerne mehrere kleine Adapterplatinen haben, die jeweils einen solchen USB-Controller verwalten können und sie dann parallel senden lassen oder man schafft es, eine ausreichende Rechenkapazität bereitszustellen, um 4x4 solcher Controller fahren zu können.
 
Und ein Rechercheergebnis noch:

Hier hat jemand es geschafft, einen Controller mit RasPI zu benutzen:
https://stimresp.wordpress.com/2016/02/08/using-a-raspberry-pi-as-usb-midi-host/

Der RasPI scheint das mehr oder weniger automatisch können. Leider ist auf der Seite nicht dokumentiert, wie der das macht, dass dann MIDI heraus kommt. Versteht das jemand? Die Codes, die er eingibt, scheinen das nicht ausdrücklich zu forcieren, oder?

Kennt sich zufällig jemand mit dem RasPI aus? Laufen die Original-Treiber auf diesem System? Kann der Raspi mehrere USB Devices über einen HUB verwalten?

Wichtig: Kann man dort an Treiber oder die Applikation heran, um die Daten auf eigene Ports zu lenken und das möglichst sofort und ungebremst in Echtzeit?

Die entscheidende Frage: Hat das jemand mal gemacht, oder einen link oder Tipp für mich, bzw wäre daran interessiert, soetwas zu entwickeln?
 
Yo!
Ich hoffe ich verstehe dein Problem richtig.
Mein Ansatz wäre die Steuerung über ein Smartphone oder Tablet zu regeln. Das ganze per Wlan an einen oder mehrere Arduinos. Vo da aus kannst du alles steuern, inclusive der Klospühlung und Kaffemaschine. ^^
 
Nein, es geht nicht um das Steuern von Irgendwas, sondern eigener Elektronik. Das Adaptermodul muss dort hinein. Ich brauche den Eingangspfad von dem USB-Controller auf echte physikalische Pins. Tablet ist schlecht, weil es keinen verwertbaren Ausgang hat.

Was ich inzwischen herausgefunden habe:

Das angedachte, RasPI funktioniert mit einem Debian-Linux-System als OS. Dafür müsste man Compiler und alles bekommen können um selber zu programmieren und die Daten abzufangen, sodass ich sie auswerten kann. Auch wurde von anderer Seite bestätigt, dass USB-Controller grundsätzlich nach Anstecken automatisch in der device-Liste auftauchen. Das würde bedeute, dass ich keine Treiber vom Hersteller brauche.

Aber:

Die liefern fast immer Treiber für das jeweilige OS mit, damit ihre Geräte auch 100% arbeiten. Ich nehme an, dass dort ein eigenes herstellerspezifisches Datenformat kommt, das deren Treiber erst in normales MIDI übersetzt. Kann das jemand bestätigen?

Die Frage wäre ob, Linux-Versionen der Treiber oder Konfigurationssoftware auch auf diesem Debian laufen.

Wäre nett, wenn sich Leute dazu äußern könnten, die Linux benutzen und / oder einen RaSPI verwenden.
 
Nein, es geht nicht um das Steuern von Irgendwas, sondern eigener Elektronik. Das Adaptermodul muss dort hinein. Ich brauche den Eingangspfad von dem USB-Controller auf echte physikalische Pins. Tablet ist schlecht, weil es keinen verwertbaren Ausgang hat.

Das sollte ohne Probleme machbar sein. Ein Arduino ist ein Microcontroller der eigentlich alles mit denen Signalen machen kann. Je nach Modell hast du viele Digitale und Analoge Pins die du in alle Möglichen Richtungen belegen kannst. Was intern geschieht, codest du selber. Das Tablet wäre nur die Steuereinheit dafür.
Je nach dem wie fit du im coden und löten bist, kannst du dir ganz einfach deinen eigen Controller bauen.

Ich habe damit z.b. meine Audio to Midi Boxen gebastelt, um Midi Latenzen zu umgehen.
Das Audiosignal wird als 4/4 Triggerbefehl abgegriffen, und intern an 24 Midi Outputs verteilt. Jeder Output hat seinen eigen Sequencer mit Shuffle, Swing usw.
Das war der erste Entwurf von dem Sequencer.


Mein Kumpel baut damit für alle seine Synths "Midi over LAN" Schnittstellen, weil er kein bock auf oldschool Midi hat. Egal was du vorhast, damit sollte es auf jeden Fall gehen.
 
Hier ne ausführliche Midi-DIY-Methode mit dem Arduino.

 
Aber:

Die liefern fast immer Treiber für das jeweilige OS mit, damit ihre Geräte auch 100% arbeiten. Ich nehme an, dass dort ein eigenes herstellerspezifisches Datenformat kommt, das deren Treiber erst in normales MIDI übersetzt. Kann das jemand bestätigen?
Einige Controller können aber auch zwischen Class-Compliant (=treiberlos und auch an externer Hardware laufend) und "treiberbetrieben" umgeschaltet werden.
Das ist mir dieser Tage bei meinem alten Edirol PCR-30 aufgefallen.

Wie im anderen Thread gerade geschrieben, wirst Du nicht um Experimente herumkommen.
 
Je nach dem wie fit du im coden und löten bist, kannst du dir ganz einfach deinen eigen Controller bauen.

Nein, nicht eigene Controller bauen. Es geht um den umgekehrten Weg, nämlich vorhandene Controller, die nur USB können, auszulesen.
Wie kommt da "MIDI over LAN" ins Spiel? Dazu müsste man doch einen Controller bauen oder modizifieren?

Ist verstanden worden, was ich möchte?

Ich möchte das Selberbauen eben vermeiden.
 
Je nach dem wie fit du im coden und löten bist, kannst du dir ganz einfach deinen eigen Controller bauen.

Nein, nicht eigene Controller bauen. Es geht um den umgekehrten Weg, nämlich vorhandene Controller, die nur USB können, auszulesen.
Wie kommt da "MIDI over LAN" ins Spiel? Dazu müsste man doch einen Controller bauen oder modizifieren?

Ist verstanden worden, was ich möchte?

Ich möchte das Selberbauen eben vermeiden.

Kann es sein, das du selber nicht wirklich verstehst, was du da machen willst?
Ich habe dir jetzt mehrfach erklärt was ein microkontroller macht.
In der Zeit in der wir hier quatschen, hätte ich dir das Teil 3 mal gebaut.
Les dich doch mal in die Materie ein, bevor du weiter fragen stellst.
 
Ich versuche es dir ein letzes mal Bildlich und in ausführlicher Textform zu erklären. Fragen deinerseits wie "Was hat das mit Midi over Lan zu tun" lassen mich allerdings zweifeln wie sinnvoll dein Vorhaben ist, weil es anscheinend an Basics mangelt.

Stell dir vor du willst eine Box bauen, die ein Midi Signal Aufnimmt, in ein anderes Protokoll umwandelt und über dessen Schnittstelle (in dem Fall LAN) ausgibt. Was musst du tun?
Du liest das MIDI Signal aus (In dem Fall die Clock) übersetzt die gewonnenen Daten und leitest sie weiter.

Merkst du was?
Das ist das Gleiche was du vor hast, daher macht mich deine Frage stutzig.
Es ist doch vollkommen egal, ob ich die Daten analog aus dem Midi Kabel sauge, oder digital aus der USB Leitung. In Beiden Fällen brauche ich einen Controller, der die Daten Aufnimmt, (eventuell übersetzt) und/ oder wie in deinem Fall nur weiterleitet.

Warum habe ich dieses Beispiel von meinem Bekannten erwähnt?
Um aufzuzeigen, das mit einem Arduino Midi Projekte umgesetzt werden können, die extrem Latenz genau sein müssen.

Warum habe ich dir mein Video von dem Sequencer gezeigt?
Um dir zu zeigen, das man damit in wenigen Schritten einen Midi Sequencer bauen kannst.

(Wenn du an dieser Stelle Fragen willst, was das ganze mit deinem Projekt zu tun hat, solltest du das ganze noch mal überdenken..)

-------------------------------------------------------------------------------------------------

Ich erkläre dir jetzt noch mal wie ich das machen würde:

Du klemmst zwischen den Controller und den Empfänger (Ich habe keine Ahnung was es ist und das ist auch völlig egal PC, Synth, etc...) einen Microcontroller (Arduino).Dieser dient als erstmal nur als durchlauf, die Signale werden weitergeleitet.
Jetzt schreibst du jetzt eine winzige Software für den Arduino, die an den digitalen Ports lauscht. Die Software soll alle Daten tracken.

Sobald du jetzt etwas an dem Controller änderst, wird der Befehl nicht nur an den (PC) gesendet, sondern auch von dem Arduino protokolliert.
Was du ab jetzt mit den Daten machst, ist dir vollkommen frei überlassen.
Du kannst jetzt z.b. eine LED an einen Analogen Pin des Arduinos hängen und ihm sagen, das er die LED beleuchten soll, wenn du an dem Controller auf ein Drumpad klopfst o.Ä.

Daher auch am Anfang mein Hinweis auf "Wlan". Das war ein Fingerzeig auf die riesige Plattform die Arduino mitbringt.
Du kannst dem Controller auch sagen, das er ein Signal über Wlan an z.b. deine Kaffeemaschine schicken soll.
Bedeutet du ziehst den Fader 1 über 50% in deiner Küche wird Kaffee gekocht.

Reicht diese Flexibilität für einen Anwendungszweck, oder planst du was mit Raketentechik?

ardu.jpg
 
Dein Bild zeigt leider, dass du immer noch nicht verstanden hast, worum es geht.

Es reicht nicht, dass der Arduino einfach das USB dekodiert und "mitliest"- wie es das als slave tun würde.

Ich habe mich inzwischen mit einem Entwickler unterhalten, der solche Interfaces herstellt und vertreibt. Der hat die Intention bestätigt:

Er muss ein vollständiger USB host sein, d.h. er braucht eine Geräteverwaltung, muss die Controller (die -> MIDI Controller!!!) verwalten (es sollen ja gfs mehrere sein und nicht nur einer) und muss dann selber gegenüber dem MIDI Empfänger aktiver Sender sein. Es soll auch weder über WIFI noch über NET gehen. Diese Ideen komme nicht von mir.
 
Dein Bild zeigt leider, dass du immer noch nicht verstanden hast, worum es geht.

Es reicht nicht, dass der Arduino einfach das USB dekodiert und "mitliest"- wie es das als slave tun würde.

Ich habe mich inzwischen mit einem Entwickler unterhalten, der solche Interfaces herstellt und vertreibt. Der hat die Intention bestätigt:

Er muss ein vollständiger USB host sein, d.h. er braucht eine Geräteverwaltung, muss die Controller (die -> MIDI Controller!!!) verwalten (es sollen ja gfs mehrere sein und nicht nur einer) und muss dann selber gegenüber dem MIDI Empfänger aktiver Sender sein. Es soll auch weder über WIFI noch über NET gehen. Diese Ideen komme nicht von mir.

Alles gut, super.
Ich wünsche dir noch viel Spaß mit deinem Projekt.
 
Schade, dass Leute SO reagieren, nur weil sie sich angepisst fühlen, wenn man ihnen erklärt, dass sie auf dem Holzweg sind.

Für die Mitleser: Das Problem wurde mit einem USB-MIDI-host gelöst, allerdings kann der nicht alles, was gefragt war. Daher wird ein normaler Controller mit MIDI-Ausgang benutzt.

Die Schwierigkeit besteht darin, die angeschlossenen USB-Slaves (oder heißen sie jetzt Clients?) alle zu verwalten was deshalb nicht so 100% klappt weil viele den gleichen FTDI-Chip benutzen und es ein Problem ist, sie aus einander zu halten. Der Verwalter im System MUSS aber genau das tun und sie einzeln ansprechen, weil sie von sich aus so gut wie nichts tun.

Es geht daher nicht, wie von Gel 67478 vorgeschlagen, einfach "mitzuhören". Man muss den aktiv bedienen und fragen und eine Kommunikation aufbauen.

Wer vor einem ähnlichen Problem steht, der sollte sich einen RASPI ansehen. Der hat diesen USB-Block als Treiberschicht im Betriebssystem mit drin und dann ist es auch leicht, das zu programmieren und mehrere Geräte zu verwalten.

Die Lösung mit einem USB-MIDI-HOST geht, kann aber immer nur EIN Gerät "point_to_point", wie man sagt.
 
Ja sowas wie USB oder Bluetooth implementiert man mal nicht eben so... Hat man ein Betriebssystem ist es sicherlich einfacher, da findet sich dann vl. auch eher OperSource, der dann hoffentlich auch noch läuft, wenn er überhaupt jemals vollständig lief XD

Das ist auch nochmal eine andere Welt als AD-Wandler und Midi-Clock. Ich meine, dass bevor man einen USB-Host schreibt man als normalsterblicher wesentlich schneller ist, wenn man die Encoder in eine Zigarrenschachtel baut und Spur A und B auswertet anstatt sich mit USB-Klassen und Treiberarchitekturen rumzuschlagen. Klar, jeden handelsübliche MidiController anbinden zu können ist wesentlich schicker, als eine Zigarrenschachtel :D

Aber das ist nochmal ein etwas anderes technisches Level, als AD-Wandler , Midi Clock, und LED'S die an GPIO Pins hängen. Da einen USB-Monitor zwischen eine bestehende USB-Punkt-zu-Punkt verbindung zu hängen, um da dann DAten abzugreifen, erscheint mir schon etwas abenteuerlich und geht außerdem komplett an dem vorbei, was der TE eingangs "gefordert" hat. USB ist halt kein Bus wie CAN oder Token Ring, wo man einfach mal so Geräte mit rein- bzw. dazwischen hängen kann wie man lustig ist. Ich dachte eigentlich, USB ist grundsätzlich Punkt-Zu-Punkt. (?!)
 
Zuletzt bearbeitet:
Ich hatte übrigens auch mal die Idee für interne Entwicklungszwecke einen MidiController zu verwenden, anstatt die hässliche Büchse, mit siebensegment anzeigen und Encodern über CAN angebunden. Habe das dann aber auch recht flott wieder verworfen, als ich realisiert habe, was für ein Act es ist, einen Midi Host zum laufen zu bekommen. Bzw. ich habe es nicht mal ansatzweise realisiert, bevor ich getürmt bin XD
 

Oft gelesene Themen

Zurück
Oben