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.
Angehängte Dateien:
-
usb-controller.jpg
240 KB
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?
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ß
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
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
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
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.
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).
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.
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.
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.
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
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
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
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
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.
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
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.
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.
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
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.
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.
Angehängte Dateien:
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
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
Angehängte Dateien:
-
midi_speed_latency.gif
18 KB
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.
Dazu kommt noch, dass zumindest das FL Studio Gerät velocity sensitive Pads hat. Meist sind das resistive Kraftaufnehmer, die mit ADCs abgetastet werden...
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?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.