Forum: Mikrocontroller und Digitale Elektronik USB-AUDIO-MIDI-Controller in eigener Elektronik benutzen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Reinhard (Gast)


Angehängte Dateien:

Lesenswert?

Gleich vorweg: Ich kenne mich weder mit USB noch mit RasPI, Arduino oder 
AVR genauer aus und brauche etwas Unterstützung:

Ich würde gerne solche USB-Controller mit Reglern und Tastern zum 
Steuern von Pseudoanalogwerten und Schalterzuständen nutzen. Die 
externen Knöpfe sollen Potentionmeter und andere Eingabepanels ersetzen.

Warum das Ganze?

Ich möchte Steuereinheiten bauen und auch weitergeben, die ich flexibel 
zusammenstellen kann, ohne zu große Änderungen an Software oder gar 
Umbauten an Hardware zu haben.

Diese Geräte sind zwar für Musik gedacht, erfüllen aber diesen Zweck, da 
in unterschiedlichen Ausführeung 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,- 
besonders bei Tastersystemen mit optischer Rückmeldung und sind auch nur 
in Sonderanfertigung und großen Stückzahlen erhältlich

Die neueren Geräte dieser Klasse haben aber kein einfach auzuwertendes 
MIDI, sondern einen USB Ausgang. Leider ist aber USB nicht so mein 
Fachgebiet. Ich bin eher Analog-Elektroniker und Mechaniker.


Ich habe unterschiedliche Quellen durchgesehen, um mich zu informieren. 
Hier z.B. wurde so etwas bereits diskutiert:
Beitrag "Analoge Orgel mit USB-MIDI steuern"

Leider ist der thread zu Musik-/Orgellastig geworden und obendrein 
totgequatscht.

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.

Die Frage ist, wie geht man da vor: 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.

von Reinhard (Gast)


Lesenswert?

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:

VUSB ist offenbar nur ein device (kein host):
https://bitbucket.org/horo/v-usb-midi/src/default/

USB-MIDI-host:
http://www.hobbytronics.co.uk/usb-host-midi
Der wird aber nicht mehr produziert, passt 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 machbar mit wenig Controllertechnik wenigstens 
einen Kanal anzuschließen. Die Lösung müsste nur so verändert werden, 
dass die Daten parallel oder sehr viel schneller herauskommen.

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 Verhandlung. 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.

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 Treiber auf 
diesem System?

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?

Kann der Raspi mehrere USB Devices über einen HUB verwalten?

von bronko (Gast)


Lesenswert?

Hi.

Dein Vorhaben sollte mit einem RPi gut machbar sein. MIDI-Controller in 
RPi einstecken und dann im Terminal mit 'lsusb' anzeigen lassen. 
'aconnect' und 'aseqdump' helfen die Daten anzuzeigen, bzw. 
weiterzuleiten. Du könntest sie z.B. dann über UART ausgeben. Viele 
MIDI-Controller haben noch einen MIDI-Buchse; da hast du dann direkt 
schon UART.

Bei mehreren MIDI-Controllern brauchst du vermutlich ein Powered-Hub. 
Die max. Anzahl für USB liegt glaube bei 127 Geräten.

Gruß

von Thomas Z. (usbman)


Lesenswert?

Reinhard schrieb:
> Die neueren Geräte dieser Klasse haben aber kein einfach auzuwertendes
> MIDI, sondern einen USB Ausgang. Leider ist aber USB nicht so mein
> Fachgebiet. Ich bin eher Analog-Elektroniker und Mechaniker.

Da geht es schon los. Was für Anschlüsse haben die Geräte? Sind das 
Hosts oder Devices oder vielleicht sogar OTG?

Wenn du ferige HW mit USB Anschluss hast must du nehmen was da kommt. 
Nur wenn du die USB Hardware selbst baust kannst du andere Varianten 
implementieren.

Also wenn es USB Midi sein soll dann sind deine Tastaturen vermutlich 
Devices
Wenn die Dinger als eigenständige Controller ohne PC funktionieren 
sollen muss ein Midi Host implementiert werden. Keine triviale Sache.

Deine 2us sind Käse USB Midi ist Bulk das bedeutet 64 Byte pro Paket = 
16 Midibefehle. Bei Fullspeed und freiem Bus passen so etwa 16 Pakete in 
eine ms. Das wären als 256 Midibefehle pro MS. Das muss erst Mal 
verarbeitet werden. In der Realität wird das viel langsamer ablaufen. 
Denk daran Midi war  31kbaud

Bulk heißt übrigens auch das Software USB nicht geht da dort nur 
lowspeed funktioniert.

Thomas

von Rolf M. (rmagnus)


Lesenswert?

Reinhard schrieb:
> Als Zusammenfassung kann festgehalten werden:
>
> - Es muss ein MIDI-host

USB-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.

Ja, das muss man definitiv beachten. Ich habe hier z.B. ein Novation 
Launchpad der ersten Generation, das nicht class compliant ist. Bei der 
zweiten Generation ist das wohl anders.

> - Das Empfangsgerät muss die USB-Clients verwalten können und
> auseinander halten können

Sofern du mehrere gleichzeitig anschließen willst, ja. Und es muss dann 
auch USB-Hubs unterstützen, damit man überhaupt mehrere Geräte 
anschließen kann. Ich habe hier einen STM32, der als USB-MIDI-Host 
arbeitet, aber mangels Hub-Unterstützung nur ein Gerät kann.

Reinhard schrieb:
> 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.

Auf dem Raspi läuft Linux. Das unterstützt USB-MIDI. An die 
MIDI-Nachrichten kommt man auf die gleiche Weise ran, wie auf einem PC, 
wo Linux drauf läuft, z.B. direkt per ALSA 
(https://www.alsa-project.org/alsa-doc/alsa-lib/rawmidi.html) oder auch 
über Jack (https://jackaudio.org/api/group__MIDIAPI.html).

> 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?

Was genau meinst du mit "auf eigene Ports zu lenken"?

> Kann der Raspi mehrere USB Devices über einen HUB verwalten?

Ja.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Noch ein paar Ansätze:
Wenn ich dich richtig verstanden habe willst du eine Box bauen die als 
Host funktioniert und an die du mehrere USB Midi devices anschließen 
willst.
Ich gehe mal nicht davon aus dass diese Box ein Windows oder Linux PC 
sein soll sondern was kleineres. Dann bleibt nur ein EPC  auf dem Linux 
läuft,  weil du sicher keinen Class Compilant Host  selbst 
implementieren willst. Ein RPi ist da ein guter Start. Das ist relativ 
einfach.jedoch was machst du mit den Daten auf deiner Box?
Da brauchte es dann Applikationen. Kannst du sowas schreiben?
Du brauchst zumindest Software um deine Midi Controller zu programmieren 
Sysex?

Thomas

: Bearbeitet durch User
von Joe F. (easylife)


Lesenswert?

Was um Himmels Willen hast du vor?
16 solche Controller?
Ich bin mir sicher es gibt eine bessere und günstigere Lösung für einen 
Haufen beleuchteter Taster anstatt eine Lagerhalle voller 
Musikcontroller aufzukaufen... Dein Argument 'leicht zu ersetzen' teile 
ich nicht, in der Regel kommt nach 1-2 Jahren das Nachfolgemodell 
heraus.

von Martin H. (horo)


Lesenswert?

Anschauen, bzw. Weiterverarbeiten von USB-Midi geht einfach, siehe mein 
simples Testprogramm:

https://bitbucket.org/horo/v-usb-midi/src/default/V-USB-MIDI-ATtiny85/midimon.c

Sollte auch auf dem Raspi gehen, habe es dort aber noch nicht probiert, 
eventuell das Device anpassen (/dev/midi1).

von Reinhard (Gast)


Lesenswert?

bronko schrieb:
> Dein Vorhaben sollte mit einem RPi gut machbar sein. MIDI-Controller in
> RPi einstecken und dann im Terminal mit 'lsusb' anzeigen lassen.
Hast du da reale Erfahrungen?

> 'aconnect' und 'aseqdump' helfen die Daten anzuzeigen, bzw.
> weiterzuleiten.
Wohin kann man die Daten weiterleiten? USB MIDI DAten haben ein eigenes 
Format und Protokoll. Ich brauche also eine Zwischenschicht in der ich 
mit C oder C++ die Daten abgreifen, aufarbeiten und filtern kann. Ich 
habe ja konkrete Bedürfniss hinsichtlich des Schaltens von Pins. Z.B. 
soll ein Knopf als Taster wirken, der andere als tastender Schalteter. 
Ich nehme an, ich muss dann auch dem Controller noch ein MIDI-Signal 
senden, damit er seine LED an macht - das kriege ich aber schon raus.

Meine Frage ist:

RasPI funktioniert mit (eben rcherchiert) mit einem RasBIAN System, 
offenbar ein Debian-Linux. Dafür müsste man Compiler und alles bekommen. 
Damit bräuchte ich eigentlich keine Herstellertreiber, um die Geräte zu 
sehen. Allerdings liefern die immer Treiber mit, damit ihre Geräte auch 
arbeiten. Ich nehme an, dass dort ein eigenes herstellerspezifisches 
Datenformat kommt, dass deren Treiber erst in Linux übersetzt.

Kann das jemand bestätigen?

> Du könntest sie z.B. dann über UART ausgeben.
Wie schnell ist die UART? 230k wohl maximal, das wäre dann viel zu 
langsam. Ich muss schon direkt auf diese Stiftleiste.

> Viele
> MIDI-Controller haben noch einen MIDI-Buchse
Nein, kein einziger moderner Controller hat noch ein MIDI-Trio.

> Bei mehreren MIDI-Controllern brauchst du vermutlich ein Powered-Hub.
Das wäre kein PRoblem, ich sorge mich eher um den traffic.

> Die max. Anzahl für USB liegt glaube bei 127 Geräten.
Das ist klar, aber wie erkennt das System mehrfach denselben Controller? 
Ich kenne die PRoblematik von I2C, SPI und UART Wandeln, in denen der 
FTDI sitzt. Da kann man oft nur einen verwenden und muss abstecken, weil 
das OS die nicht auseinander halten kann, obwohl sie in verschiedenen 
Buchsen sitzen.

von Reinhard (Gast)


Lesenswert?

Thomas Z. schrieb:
> Wenn ich dich richtig verstanden habe willst du eine Box bauen die als
> Host funktioniert und an die du mehrere USB Midi devices anschließen
> willst.
Eine Box oder mehrere kleine Platinen als Kanäle.

> Ich gehe Mal nicht davon aus dass diese Box ein Windows oder Linux PC
> sein soll sondern was kleineres
Raspi wäre ok. Ein größerer Rechner eher nicht. Es geht auch um die 
Kosten. RasPI mit freiem Linux macht 40,- Das wäre sehr gut. Alternative 
Tablet zu 250,- und ein Interface von Tablet auf GPIO zu was weiß ich. 
Schlecht.

Thomas Z. schrieb:
> was machst du mit den Daten auf deiner Box?
> Da brauchte es dann Applikationen.
Anwendungen habe ich. Programmieren in C kann ich auch. Ich brauche 
eigentlich nur Steuersignale auf elektrischen Pins 3,3V mit 16 Bit, oder 
8Bit mit doppelter Rate. Ideal 1Mbps insgesamt. Man soll z.B. ein Gerät 
auch schnell abschalten können. Ist keine Sicherheitsfunktion (non wire 
wäre ok) aber es soll halt schnell gehen.

von Reinhard (Gast)


Lesenswert?

Ich habe auch wegen Arduino geschaut:

https://github.com/FortySevenEffects/arduino_midi_library

Der ist aber eher langsamer, wenn auch HW-näher.(?)
Die Frage wäre, ob der dann 16 Controller verarbeiten kann.

Rolf M. schrieb:
> Ich habe hier einen STM32, der als USB-MIDI-Host
> arbeitet, aber mangels Hub-Unterstützung nur ein Gerät kann.
Selbst entwickelt? Ist das public?

Wäre auch machbar, wenn man einfach für jeden MIDI-Controller einen 
nimmt und die alle verkettet, also seriell verknüpft. Jeder STM32 erhält 
einen seriellen Eingang und kann seine eigenen Daten über FIFOs 
einmischen durch Multiplexing. Der letzte dekodiert dann das MIDI und 
setzt die IOs.
Durch die Anstöpselung der MIDI-Controller könnte man sogar einen 
Wichtigsten definineren, nämlich den letzten in der Kette.

von Thomas Z. (usbman)


Lesenswert?

Reinhard schrieb:
> Allerdings liefern die immer Treiber mit, damit ihre Geräte auch
> arbeiten. Ich nehme an, dass dort ein eigenes herstellerspezifisches
> Datenformat kommt, dass deren Treiber erst in Linux übersetzt.

Warum wohl? Weil kein OS wirklich alle Midi Class spezifischen Dinge 
unterstützt.
Jedes OS ob Win OSX oder Linux bildet immer nur eine Teilmenge ab. Das 
ist bei einfachen Devices auch kein Problem wird aber bei komplexen 
Maschinen ziemlich eklig. Die Hersteller bietenTreiber als Workarround 
um Ihre Maschinen besser abbilden zu können. Been there done that.

Reinhard schrieb:
> Das ist klar, aber wie erkennt das System mehrfach denselben Controller?

Genau wie andere Geräte auch über die Position im USB Baum und 
alternativ über Strings / Treiber.

Frag dich doch Mal selbst warum es sowas nicht zu kaufen gibt?
Ein Grund ist wohl das Musiker in der Regel kein Geld haben, und wenn 
Sie Geld haben wird vorher das neueste Keyboard gekauft. Studios 
brauchen das nicht die haben Ihre eigene Infrastruktur die heutzutage 
LAN basierend ist.

Thomas

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Reinhard schrieb:
> Wäre auch machbar, wenn man einfach für jeden MIDI-Controller einen
> nimmt und die alle verkettet, also seriell verknüpft. Jeder STM32 erhält
> einen seriellen Eingang und kann seine eigenen Daten über FIFOs
> einmischen durch Multiplexing. Der letzte dekodiert dann das MIDI und
> setzt die IOs.
> Durch die Anstöpselung der MIDI-Controller könnte man sogar einen
> Wichtigsten definineren, nämlich den letzten in der Kette.

Das ist doch kompletter Quatsch wie soll das gehen? Oben schreibst du 
sonst dass seriell viel zu langsam ist.
Du musst dich schon entscheiden ob du einen richtigen Usbhost willst an 
den du deine Midi Devices anstecken kannst oder ob du eine Box willst 
die Midi dekodiert und irgend welche Aktionen auslösen kann. Das sind 
komplett unterschiedliche Dinge.
Und sag jetzt bitte nicht das du die CID aus der Midi Spec benutzen 
willst um damit deine 16 Midicontroller abzubilden.

Thomas

von Rolf M. (rmagnus)


Lesenswert?

Reinhard schrieb:
> Wohin kann man die Daten weiterleiten? USB MIDI DAten haben ein eigenes
> Format und Protokoll. Ich brauche also eine Zwischenschicht in der ich
> mit C oder C++ die Daten abgreifen, aufarbeiten und filtern kann.

Schau dir meine Links zu ALSA und Jack an. So greift man unter Linux in 
C auf MIDI-Geräte zu.

> Ich nehme an, ich muss dann auch dem Controller noch ein MIDI-Signal
> senden, damit er seine LED an macht - das kriege ich aber schon raus.

Ja, das ist in der Regel nicht besonders schwierig. Man sendet meist 
einfach die gleiche MIDI-Nachricht hin, die man beim Drücken der Taste 
bekommt, und die LED geht an. Für manche Controller gibt's auch 
offizielle oder teils auch von Benutzern zusammengetragene 
MIDI-Belegungs-Tabellen.

>> Du könntest sie z.B. dann über UART ausgeben.
> Wie schnell ist die UART? 230k wohl maximal, das wäre dann viel zu
> langsam.

Warum? Wieviele Tausend Tasten sollen denn quasi gleichzeitig gedrückt 
werden können?

>> Viele
>> MIDI-Controller haben noch einen MIDI-Buchse
> Nein, kein einziger moderner Controller hat noch ein MIDI-Trio.

Kein Trio, aber zumindest mal in+out hat z.B. das Launchpad Pro, nur 
halt nicht über den klassischen DIN-Stecker, sondern per Klinke, weil es 
zu flach ist.

>> Bei mehreren MIDI-Controllern brauchst du vermutlich ein Powered-Hub.
> Das wäre kein PRoblem, ich sorge mich eher um den traffic.

Auch hier wieder die Frage:  Wieviele Tausend Tasten sollen denn 
gleichzeitig gedrückt werden können?

>> Die max. Anzahl für USB liegt glaube bei 127 Geräten.
> Das ist klar, aber wie erkennt das System mehrfach denselben Controller?
> Ich kenne die PRoblematik von I2C, SPI und UART Wandeln, in denen der
> FTDI sitzt. Da kann man oft nur einen verwenden und muss abstecken, weil
> das OS die nicht auseinander halten kann, obwohl sie in verschiedenen
> Buchsen sitzen.

Man kann unter Linux über entsprechende udev-Rules eine feste Zuordnung 
von USB-Port zum Gerät einrichten.

Reinhard schrieb:
> Rolf M. schrieb:
>> Ich habe hier einen STM32, der als USB-MIDI-Host
>> arbeitet, aber mangels Hub-Unterstützung nur ein Gerät kann.
> Selbst entwickelt? Ist das public?

Den USB-MIDI-Teil habe ich nicht selbst entwickelt, sondern aus dem 
"Dekrispator" übernommen - sollte per Google zu finden sein.

Thomas Z. schrieb:
> Reinhard schrieb:
>> Allerdings liefern die immer Treiber mit, damit ihre Geräte auch
>> arbeiten. Ich nehme an, dass dort ein eigenes herstellerspezifisches
>> Datenformat kommt, dass deren Treiber erst in Linux übersetzt.
>
> Warum wohl? Weil kein OS wirklich alle Midi Class spezifischen Dinge
> unterstützt.

Was soll denn das sein, das da nicht unterstützt wird? Hab ich noch nie 
erlebt. Class Compliant USB-MIDI ist eigentlich auch ziemlich simpel.
Siehe Spec: https://www.usb.org/sites/default/files/midi10.pdf

von Thomas Z. (usbman)


Lesenswert?

Rolf M. schrieb:
> Was soll denn das sein, das da nicht unterstützt wird? Hab ich noch nie
> erlebt. Class Compliant USB-MIDI ist eigentlich auch ziemlich simpel.
> Siehe Spec: https://www.usb.org/sites/default/files/midi10.pdf

OK ein paar Beispiele:
1 Windows usbmidi verliert ab und an bei bestimmten Konstellationen 
Bytes bei Sysex Übertragung.
2. OSX kommt nicht damit klar wenn man kein Endpointsharing macht sprich 
Midi Buchsen auf unterschiedliche Endpoints legt. Win kann das perfekt. 
Das verhindert z.b in den meisten Fällen den Sysex Bug
3. Alle OS haben (hatten) Probleme wenn Midi Element Deskriptoren 
erscheinen.

Generell kann es kompliziert werden die Topologie über OS Grenzen immer 
gleich abzubilden

Thomas

von Rolf M. (rmagnus)


Lesenswert?

Ok, so tief hab ich da doch nicht reingeschaut. Ich dachte auch, du 
meintest eher fehlende Funktionen, aber das klingt ja eher nach Bugs in 
den Implementierungen.

von Thomas Z. (usbman)


Lesenswert?

Wie ich ja oben geschrieben habe bei einfachen Devices ist das kein 
Problem. Es wird erst eklig wenn man komplexe Funktionen baut. Das ist 
vermutlich sogar der Hauptgrund  warum die meisten Midi Topologien eher 
einfach gestrickt sind. Die Spec würde da mehr hergeben.
Ich hab in der Vergangenheit sogar mal ein Device gebaut was für OSX und 
Win unterschiedliche Deskriptorsätze hatte und  automatisch erkennen 
konnte ob das Teil unter OSX oder Win läuft. Damit könnte ich in beiden 
Fällen mit einer FW arbeiten.

Ehrlicherweise muß ich gestehen, dass wir unter Linux nicht viel 
getestet haben da das kein Zielmarkt war.
Andere Fehler hab ich gar nicht beschrieben weil nicht mehr relevant (XP 
/OS9)

Thomas

von Reinhard (Gast)


Lesenswert?

Thomas Z. schrieb:
> Das ist doch kompletter Quatsch wie soll das gehen? Oben schreibst du
> sonst dass seriell viel zu langsam ist.
Die auslesenden Microcontroller seriell verschalten, war gemeint, wenn 
es nur einer werden sollte, je USB Kanal. Die müssen ja nicht wie MIDI 
mit 31k arbeiten sondern können mit MHz gekoppelt werden.

Rolf M. schrieb:
> Auch hier wieder die Frage:  Wieviele Tausend Tasten sollen denn
> gleichzeitig gedrückt werden können?
Es gibt Anforderungen, was "sofort" ist. Die liegen im Bereich unter 1ms 
mit allen Abarbeitungen im Zielsystem. Real gedrück werden können z.B. 3 
Tasten wie beim Windows auch CTRL, CONFIG / SHIFT und eine 
Funktionstaste.
Das sollte alles im Bereich von 100us je Taste sein.

Rolf M. schrieb:
> aber zumindest mal in+out hat z.B. das Launchpad Pro, nur
> halt nicht über den klassischen DIN-Stecker, sondern per Klinke, weil es
> zu flach ist.
Das wäre nicht übel, einen mit normalem MIDI zu haben. Auf den Fotos 
beim Thomann z.B: sehe ich keine derartige Buchse und auch in der SPEC 
ist kein "normales" MIDI genannt. "5-Pol-DIN MIDI" ist ausdrücklich auf 
Nein. Auch auf der Novation-Seite ist nichts dazu gesagt (???)

Habe versucht, bei Thoman mal solche Controlle mit MIDI zu finden, 
allerdings ohne Erfolg. Es werden überhaupt nur 19 gelistet und die sind 
anderer Natur.

von Joe F. (easylife)


Lesenswert?

100us... vollkommen unrealistisch. USB MIDI und auch HID haben Latenzen 
von mindestens 1ms, eher bis zu 5ms.
Wenn du es schaffst deinen Finger mit 100km/h auf eine Taste knallen zu 
lassen, dann kommt der Event erst an, wenn der Finger nach 1ms schon 
27mm tief im Gerät steckt. Schlimm?
Wenn der Hersteller eine Tastenentprellung implementiert hat, kommt noch 
extra Zeit dazu.
Und abgesehen davon, bekommt deine Applikation auch nicht alle 100us die 
Gelegenheit überhaupt irgend etwas zu tun.

: Bearbeitet durch User
Beitrag #6055870 wurde vom Autor gelöscht.
von Thomas Z. (usbman)


Lesenswert?

Reinhard schrieb:
> Die auslesenden Microcontroller seriell verschalten, war gemeint, wenn
> es nur einer werden sollte, je USB Kanal. Die müssen ja nicht wie MIDI
> mit 31k arbeiten sondern können mit MHz gekoppelt werden.

Von was redest du? Deine USB Kanäle sind wohl die 16 Hosts? Mit MHz 
gekoppelt soso....

Dann lass mich das mal klarstellen:
Du schreibst dass du keine Ahnung von USB hast willst aber auf den STM32 
einen
class Compilant USB Midi Host implementieren. Das ganze dann 16 mal. 
Dein Host wird dann die Daten seriell gemultiplext an einen 
Hauptcontroller schicken. Vermutlich bekommt jeder deiner Hosts einen 
Timeslot zugeteilt damit du die Zuordnung zu den Hosts herstellen 
kannst? Dieser Hauptcontroller dekodiert die Daten dann und macht 
irgendwas damit?
Hab ich das soweit verstanden? Dann mach mal. Kannst ja erst mal mit 
einem deiner USB Kanäle anfangen.
Ich würde an deiner Stelle mal anfangen kleinere Brötchen zu backen.

Thomas

von Reinhard (Gast)


Lesenswert?

Thomas Z. schrieb:
> Von was redest du? Deine USB Kanäle sind wohl die 16 Hosts? Mit MHz
> gekoppelt soso....
Diese Idee kam auf für den Fall, dass es nicht möglich ist, 16 
USB-Geräte oder mehr mit einem Microcontroller / Chip oder womit auch 
immer zu hosten. Es müssen ja auch noch mehr Dinge an USB dran, wie 
Maus, Tastatur, IF-Kabel etc. Man muss sehen, wie man die HUBs aufteilt 
und ob es möglich ist, mehrere Geräte über einen HUB zu fahren.

Die Lösung "serielle Verbindung" sähe wiederum so aus, dass jeder 
einzelne dieser Microcontroller (z.B. eben der aus dem link der 
englischen Seite) einen einzigen MIDI-Controller bedient und diese 
Informationen an den nächsten Nachbarn weitergibt, wie bei einer Daisy 
Chain. Die 16 Microcontroller könnten mit z.B. 1 MHz seriell über 
jeweils einen Pin mit einander reden. Ich habe so auch schon 2x2 
Controller quer miteinader reden lassen, um sie zu synchen.

von Reinhard (Gast)


Lesenswert?

Joe F. schrieb:
> 100us... vollkommen unrealistisch. USB MIDI und auch HID haben Latenzen
> von mindestens 1ms, eher bis zu 5ms.
Die sind eingerechnet, daher sollte es nicht noch weitere Verzögerungen 
geben, weil 16 Controller mit der angedachten Rate von 100us auch 
nochmals 1,6sec aufwerfen würden, wie man leicht nachrechen kann. Wenn 
das etwas überschritten wird, wäre es wohl kein Problem. Ich kann auch 
mit 3ms leben, wenn dann garantiert ist, dass alle Controller gepollt, 
alle Daten erfasst und übermittelt sind.

Joe F. schrieb:
> Wenn der Hersteller eine Tastenentprellung implementiert hat, kommt noch
> extra Zeit dazu.
Eben. Das wäre dann noch herauszubekommen, wie sehr das verzögert ist. 
Ich nehme an, dass sich das in Grenzen halten sollte, wenn man die 
Funktion ins Auge fasst, nämlich Musikspuren rythmisch an und 
abzuschalten. Ich kann mir denken, dass das sehr genau passieren muss.

Ich werde jetzt versuchen, solch einen preiswerten Chip-Bausatz 
aufzutreiben und schauen, was damit geht.

Zusätzlich werde ich auch dem nachgehen, da gibt es auch ein 
USB-Projekt.
https://www.pjrc.com/store/teensy40.html

Scheint über ein Kabel auch HUBs bedienen zu können.

von Rolf M. (rmagnus)


Angehängte Dateien:

Lesenswert?

Reinhard schrieb:
> Es gibt Anforderungen, was "sofort" ist. Die liegen im Bereich unter 1ms
> mit allen Abarbeitungen im Zielsystem.

Kein Mensch kann auch nur annähernd so schnell auf irgendein Ereignis 
reagieren und eine Taste drücken. Da vergehen selbst im allerbesten Fall 
etliche Hundert Millisekunden. Welchen Sinn hat es da, innerhalb einer 
Millisekunde drauf reagieren zu wollen? Ich halte die Anforderung für 
überzogen.

> Real gedrück werden können z.B. 3
> Tasten wie beim Windows auch CTRL, CONFIG / SHIFT und eine
> Funktionstaste.
> Das sollte alles im Bereich von 100us je Taste sein.

Auch hier halte ich das für total überzogen. So genau gleichzeitig kann 
niemand die 3 Tasten drücken.

> Das wäre nicht übel, einen mit normalem MIDI zu haben.

Du weißt aber, dass bei MIDI eine typische 3-Byte-Nachricht wie Note-on 
schon alleine eine knappe Millisekunde braucht, um über die Leitung zu 
gehen, noch ohne Latenzen in Software, Entprellung und sonstigem? Da 
wird das nix mit 100 µs je Taste.


> Auf den Fotos beim Thomann z.B: sehe ich keine derartige Buchse

Kunststück. Bei dem gibt's das Launchpad Pro gar nicht. Schau mal z.B. 
bei MusicStore.

> und auch in der SPEC ist kein "normales" MIDI genannt. "5-Pol-DIN MIDI"
> ist ausdrücklich auf Nein.

Ich wiederhole nochmal den entscheidenden Teil:

>> sondern per *Klinke*

> Auch auf der Novation-Seite ist nichts dazu gesagt (???)

Im Anhang ein Auszug aus dem Handbuch, das ich dort gefunden habe. 
Übrigens hab ich dabei gesehen, dass es für das Ding sogar einen 
"Programmer's Reference Guide" gibt.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Reinhard schrieb:
> Es müssen ja auch noch mehr Dinge an USB dran, wie Maus, Tastatur,
> IF-Kabel etc. Man muss sehen, wie man die HUBs aufteilt und ob es
> möglich ist, mehrere Geräte über einen HUB zu fahren.

Wieso Maus? Kommt da auch noch ein Bildschirm dran? Vielleicht schreibst 
du mal was deine Box denn so alles machen muss.

Du willst also doch einen PC haben. Deine Idee mit Mikrocontrollern als 
Host kann nicht funktionieren. Für Hubs muss im Host die Hub Class 
eingebaut werden für Maus und Tastatur die HID class.
Außerdem gebe ich zu bedenken dass viele Microcontroller nur Fullspeed 
können. Wenn du damit Hubs ansteuert teilen sich die 12 Mbit Bandbreite 
auf alle untergeordneten Controller auf. Also nix mit 100us.

Ich würde also mindestens einen Raspi mit Linux nehmen. Dort hast du 
zumindest USB Hispeed  und Dank Linux Unterstützung für die gängigen USB 
Klassen. Dir kannst du dann Hubs anschließen bis das 127 Gerätelimit 
erreicht ist.

Thomas

von Joe F. (easylife)


Lesenswert?

Thomas Z. schrieb:
> Vielleicht schreibst
> du mal was deine Box denn so alles machen muss.

+1

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Lesenswert?

Joe F. schrieb:
> 100us... vollkommen unrealistisch. USB MIDI und auch HID haben Latenzen
> von mindestens 1ms, eher bis zu 5ms.

Die Latenzen sind nicht zu unterschätzen. Je nach MODE des 
USB-Controllers und Puffereinstellungen kann das schon recht viel 
werden. Das fängt schon mit der Kommunikation mit dem Chip oder Core an. 
Hinzu kommen noch Effekte in Treibern in den OS. Da kommen auch gerne 
mal 8ms ... 10ms hoch.

Für alle kurzen Nachrichten sind ungepufferte Verbindungen einfach 
schneller. Solche Bediengeräte laufen daher auch eher über I2C, SPI oder 
CAN.

Trotzdem:

Das Standard-MIDI müsste in dem Fall von nur wenigen Tasten noch das 
Beste sein. Bei Keyboards sieht es schon anders aus und für Musik aus 
dem PC mit mehreren Spuren geht das gar nicht, besonders nicht, wenn 
noch einfache USB-MIDI-Kabel mit im Spiel sind. Da hat man die Nachteil 
von Latenz und geringer Bandbreite.

Die Lösung wäre aber sehr einfach, wenn MIDI-Schnittstellen über normale 
UARTs und deren Geschwindigkeiten gefahren werden könnten und mal 
wenigstens über 230k rauskämen.

Rolf M. schrieb:
> Du weißt aber, dass bei MIDI eine typische 3-Byte-Nachricht wie Note-on
> schon alleine eine knappe Millisekunde braucht, um über die Leitung zu
> gehen, noch ohne Latenzen in Software, Entprellung und sonstigem?
Ich habe bei einigen Systemen (Win-PC, Treiber, gut ausgelasteter 
USB-Bus) schon bis zu 100ms beobachten müssen, bis ein Tastendrucjk auf 
einem Masterkeyboard zu einem Klang geführt hat.

Daher habe ich damals über alternativen nachgedacht: Siehe rechte 
Spalte.

von Joe F. (easylife)


Lesenswert?

Dazu kommt noch, dass zumindest das FL Studio Gerät velocity sensitive 
Pads hat. Meist sind das resistive Kraftaufnehmer, die mit ADCs 
abgetastet werden...

von Audiomann (Gast)


Lesenswert?

Jürgen S. schrieb:
> Die Lösung wäre aber sehr einfach, wenn MIDI-Schnittstellen über normale
> UARTs und deren Geschwindigkeiten gefahren werden könnten und mal
> wenigstens über 230k rauskämen.

Eine Nachfrage zu der Tabelle: Woher kommen der overhead und die 240MBit 
Bandbreite bei USB2? Das müsste doch doppelt so hoch- und somit die 
halbe Latenz sein?

Joe F. schrieb:
> Dazu kommt noch, dass zumindest das FL Studio Gerät velocity sensitive
> Pads hat. Meist sind das resistive Kraftaufnehmer, die mit ADCs
> abgetastet werden...

Welche Abtastraten haben solche Geräte? Ich meine, wieviel Daten kommen 
da schon?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.