Als Musiker mit vielen Vintage-Synths im Studio ärgere ich mich eigentlich seit jeher, dass es keine guten und einfach zu verwendenden MIDI-Patchbays fürs Rack gibt, an denen ich all meine Geräte anbinden kann, und per Webinterface das Routing konfigurieren kann. So ein Projekt soll sich nun in mein Elektronik-Hobby einreihen. Softwareseitig ist MIDI so ziemlich das einfachste, was man verarbeiten kann. Interessanter wird es, wenn ich die Anforderung stelle, 16 MIDI I/Os zu unterstützen.
Ein Blick in die Spezifikation zeigt, dass MIDI auch nur ein serielles Interface mit 31250 baud, 1 start bit, 8 data bits, 1 stop bit ist.
EIN MIDI-Interface an einem z.B. Arduino zu verwenden, ist trivial. Aber was ist mit 16? So viele UART-Interfaces hat selbst ein STM32 nicht zur Verfügung.
Meine erste Idee war, die UARTs zu multiplexen. Da die baudrate ja noch relativ langsam ist, dürfte das gehen, dann habe ich aber diverse I²C/SPI UART-Expander-ICs gefunden, z.B. MAX3100 (SPI->UART), MAX14830 (I²C/SPI -> 4x UART) oder die NXP SC16IS7x2-Reihe (I²C/SPI -> 2x UART).
Der MAX14830 wäre mit seinem 4xUART-Interface natürlich am platzsparendesten, und dank SPI/I²C sollte ich auch vier davon gleichzeitig betreiben können.
Was meint ihr? Kann man so 16 MIDI I/Os zuverlässig einlesen, oder gibts Bedenken?
Einfacher ist es jedoch, einen Pi oder einen kleinen PC oder so zu nehmen, und daran vier FT4232H USB2-Quad-Serial Interfaces zu packen. Dafür gibts fertige Breakout-Boards, an die die Du die MIDI-Logik anschließen kannst.
Das Linux auf dem Pi (oder einem anderen Kleinrechner) kennt die FT4232H Chips und gibt Dir einfach vier /dev/ttyUSB-Interfaces. Achte darauf, dass die Boards EEPROMs haben, damit Du Seriennummern reinprogrammieren kannst, mit denen das Linux die Boards unterscheiden kann.
Damit kannst Du möglich viele Fertigteile (Hard- und Software) verwenden.
Davon vier Stück entweder auf eine ISA-Karte oder an das External Bus Interface eines Atmega 1281, und gut ist. Vorteil: Du hast nur direkte Speicherzugriffe auf die Register und kein SPI- oder I2C Gedöns dazwischen. Das senkt die Latenz deutlichst. Die UARTs sind normale UARTs, wie sie auch in PCs verwendet werden. Dafür gibts jede Menge Treiber und Softwareunterstützung.
Verglichen mit dem Preis von fast 20€ für ein solches Mäxchen wäre die FPGA-Lösung sogar noch billig.
Der MAX14830 wäre mit seinem 4xUART-Interface natürlich am
platzsparendesten, und dank SPI/I²C sollte ich auch vier davon
gleichzeitig betreiben können.
Was meint ihr? Kann man so 16 MIDI I/Os zuverlässig einlesen
Ich sehe da keine Probleme und würde es mir ohne weiteres zutrauen... ;-)
Als Musiker mit vielen Vintage-Synths im Studio ärgere ich mich
eigentlich seit jeher, dass es keine guten und einfach zu verwendenden
MIDI-Patchbays fürs Rack gibt, an denen ich all meine Geräte anbinden
kann, und per Webinterface das Routing konfigurieren kann.
Was heißt das denn GENAU? Willst du konfigurierbar die Verbindungen zwischen dein 16 MIDI-Ports schalten? Dafür reichen Relais, ggf. auch Digitalmultiplexer in einer Matrix. Zeichne mal ein Blockschaltbild.
Meine erste Idee war, die UARTs zu multiplexen. Da die baudrate ja noch
relativ langsam ist, dürfte das gehen, dann habe ich aber diverse
I²C/SPI UART-Expander-ICs gefunden, z.B. MAX3100 (SPI->UART), MAX14830
(I²C/SPI -> 4x UART) oder die NXP SC16IS7x2-Reihe (I²C/SPI -> 2x UART).
Das macht man nur, wenn man einen direkten Zugriff auf die MIDI-Daten braucht. Zum einfachen Durchleiten ist das zuviel Aufwand.
Einfacher ist es jedoch, einen Pi oder einen kleinen PC oder so zu
nehmen, und daran vier FT4232H USB2-Quad-Serial Interfaces zu packen.
Dafür gibts fertige Breakout-Boards, an die die Du die MIDI-Logik
anschließen kannst.
Das Linux auf dem Pi (oder einem anderen Kleinrechner) kennt die FT4232H
Chips und gibt Dir einfach vier /dev/ttyUSB-Interfaces. Achte darauf,
dass die Boards EEPROMs haben, damit Du Seriennummern reinprogrammieren
kannst, mit denen das Linux die Boards unterscheiden kann.
Damit kannst Du möglich viele Fertigteile (Hard- und Software)
verwenden.
Das klingt in der Tat einfacher - darüber habe ich gar nicht nachgedacht, aber Dinge überzukomplizieren, liegt (leider) in meiner Natur :P Der Vorteil eines kleinen Pi (Zero) wäre natürlich, dass jeglicher weiterer Stack, z.B. WiFi/Ethernet, schon vorhanden ist. Die FT4232H-Chips sind allerdings auch nicht gerade günstig. Aber naja, das waren meine vorgeschlagen ICs auch nicht.
Was heißt das denn GENAU? Willst du konfigurierbar die Verbindungen
zwischen dein 16 MIDI-Ports schalten?
Okay, da habe ich mich wohl missverständlich ausgedrückt - sorry! Die Verbindungen sollen nicht nur durchgeschaltet, sondern auch softwareseitig gefiltert und modifiziert werden können. Beispiel: "Leite MIDI Input #2 nach MIDI Ouptut #4, aber nur Oktave 1 bis 2, und transponiere die Noten eine Oktave nach oben".
Aber was ist mit 16? So viele UART-Interfaces hat selbst ein STM32
nicht zur Verfügung.
Muss es denn eine runde Zahl sein? Die STM32F423V und F413V haben immerhin 10 im LQFP100. Man könnte auch 2 (oder mehr) davon koppeln, z.B. per CAN. Renesas hat auch einige uC mit 10 und mehr UARTs.
Wenigstens einer der mich versteht :)
Aber was anderes: wie sieht das mit den Latenzen aus, beim Umweg über USB? USB kennt ja keine einzelnen Zeichen, nur Pakete mit max. 64 Byte.
Schau dir doch mal folgenden Betrag im ucApps-Wiki an. Die Einschränkungen auf den Stimmbereich bzw. Kanal solltest du am jeweiligen Midigerät durchführen.
Ich habe seinerzeit™, auf einer leider nur 8 Port seriellen
Adapterkarte, den Baudratenquarz gegen einen 15 MHz Quarz getauscht.
Dann noch ein paar Optokoppler ueber einen Vorwiderstand an die
seriellen Ausgaenge.
Fettich wars.,,
So einfach geht das heute leider nicht mehr.
Edith:
Jonathan schrieb im Beitrag #7711969:
Okay, da habe ich mich wohl missverständlich ausgedrückt - sorry! Die
Verbindungen sollen nicht nur durchgeschaltet, sondern auch
softwareseitig gefiltert und modifiziert werden können. Beispiel: "Leite
MIDI Input #2 nach MIDI Ouptut #4, aber nur Oktave 1 bis 2, und
transponiere die Noten eine Oktave nach oben".
Das sollte man doch besser der Sequenzersoftware ueberlassen.
Aber was anderes: wie sieht das mit den Latenzen aus, beim Umweg über
USB
Gute Frage, aus persönlicher Erfahrung sind Latenzen im Bereich bis 4-5 ms für mich als Musiker völlig erträglich, und das ist ja doch eine ganz schön lange Zeit. Es gibt ja auch eine Menge USB-MIDI-Geräte und -Interfaces, ich habe die Latenz nie gemessen, aber die sind ja auch über USB(2) angebunden.
Das sollte man doch besser der Sequenzersoftware ueberlassen.
Einige der Geräte, die ich hier habe, haben solche Einstellungen teilweise nicht, und einen Sequencer in der Form gibt es in meinem Setup auch nicht, sowie auch keinen Computer (im Studio zwar schon, aber auf der Bühne nicht). Daher wäre so ein MIDI-Router schon recht praktisch. Es gibt solche Geräte auch im Handel, die allerdings alle nicht so sind, wie ich es gern hätte ;)
Einige der Geräte, die ich hier habe, haben solche Einstellungen
teilweise nicht, und einen Sequencer in der Form gibt es in meinem Setup
auch nicht, sowie auch keinen Computer (im Studio zwar schon, aber auf
der Bühne nicht). Daher wäre so ein MIDI-Router schon recht praktisch.
Es gibt solche Geräte auch im Handel, die allerdings alle nicht so sind,
wie ich es gern hätte ;)
So etwas fuehrte dann seinerzeit™ zu einem Eigenbau.
Gluecklicherweise sind mit der Zeit die verfuegbaren Technologien
besser, aber auch komplexer geworden.
Die TI TIVA-Serie kann z.B. 8 serielle Schnittstellen bedienen.
Wenn das nicht reicht, waere wohl ein "Expander" mit einem FPGA
angezeigt, der u.U. auch gleich die Routingsoftware in einem Softcore
laufen lassen koennte.
Das ist allerdings dann deutlich komplexer.
Als (Routing-)Software wuerde sich wohl ein Forthinterpreter anbieten.
Den koennte man, bedienungstechnisch, noch mit einer GUI etwas aufpeppen. Funktional notwendig ist eine GUI nicht.
Statt eines FPGA mit Softcore bietet sich ggf. auch ein Xilinx Zynq an, auf dem man zusätzlich zu den UARTs im FPGA-Teil noch ein fettes Linux auf dem ARM-Teil laufen lassen kann.
Statt eines FPGA mit Softcore bietet sich ggf. auch ein Xilinx Zynq an,
auf dem man zusätzlich zu den UARTs im FPGA-Teil noch ein fettes Linux
auf dem ARM-Teil laufen lassen kann.
Dieser Vorschlag gilt eben für den Fall, dass sich das Linux-System (und weitere FPGA-Ressourcen) auch noch für andere Zwecke sinnvoll einsetzen lässt, z.B. für einen vielkanaligen, äußerst latenzarmen Netzwerk-MIDI-Adapter.
Einen anderen oben genannten, eher schmalspurigen Ansatz sehe ich wiederum als maßlosen Overkill, nämlich die UARTs auf ISA-Karten zu packen und einen ATmega als Prozessor. Dann hat man nämlich minimale Leistung und Erweiterbarkeit bei maximalem Drahtverhau.
... z.B. für einen vielkanaligen, äußerst latenzarmen
Netzwerk-MIDI-Adapter.
Das schafft man schon leicht mit einem STM32F107 ganz ohne
Linuxwasserkopf.
Einen anderen oben genannten, eher schmalspurigen Ansatz sehe ich
wiederum als maßlosen Overkill, nämlich die UARTs auf ISA-Karten zu
packen und einen ATmega als Prozessor. Dann hat man nämlich minimale
Leistung und Erweiterbarkeit bei maximalem Drahtverhau.
Wenn man Glueck hat, findet man einen Multiportadapter.
Bei den ganz einfach konstruierten, sitzen da mehrere 16C450/550
die jeweils eigene IO-Adressen haben. Plus eine Interruptlogik,
die die Einzelinterrupts latcht, und dem Host auf nur einem
IRQ durchreicht. Der Treiber muss dann die Interruptquelle
ermitteln. Gegenueber SPI und erst recht per I2C angebundener HW
ergeben sich durchaus gute (und recht konstante!) Latenzwerte.
Das eine Latenz von einigen ms nicht sehr stoert ist wohl richtig.
Eine "eiernde" und nicht konstante Latenz, ist aber durchaus
wahrnehmbar und extrem stoerend.
Ein ATMEGA waere aber fuer mich, fuer so ein ISA-Buskonstrukt recht
ungeeignet. Das koennte ein 8051 oder eins seiner Folgederivate
sicher besser. Und womoeglich deutlich schneller.
EIN MIDI-Interface an einem z.B. Arduino zu verwenden, ist trivial. Aber
was ist mit 16? So viele UART-Interfaces hat selbst ein STM32 nicht zur
Verfügung.
Ich würde drei AVR128DB64 verwenden. Die meisten von deren vielen schönen Pins liegen in der konkreten Anwendung dann zwar brach, aber was soll's. Die drei Dinger kosten zusammen z.B. bei Mouser keine 8€.
Jeder trägt mit 6 verfügbaren UARTs zum Erfolg bei, insgesamt hat mal also 18.
Einer kriegt einen Quarz für zuverlässige UART-Kommunikation auch über einen weiten Temperaturbereich verpasst. Der versorgt die beiden anderen dann auch mit dem Quarztakt.
Untereinander kann man sie z.B. mit einem SPI-Ring @16MHz verbinden, auf dem dann so eine Art Token-Ring-Protokoll läuft. Um die Latenz weiter zu senken, könnte man die vielen freien Pins auch für einen parallelen 8 oder 16Bit-Bus in Ringstruktur verwenden. Das triebe allerdings den Aufwand für's Layout erheblich in die Höhe und nur Goldohren kämen wohl auf die Idee, das tatsächlich umzusetzen.
Einen Netzwerk-IC für das Konfig-Web-Gedöhns kann man über SPI anbinden. Hat schliesslich jeder der drei jeweils zwei davon und nur einer wird für den Interconnect-Ring benötigt.
Ein ATMEGA waere aber fuer mich, fuer so ein ISA-Buskonstrukt recht
ungeeignet. Das koennte ein 8051 oder eins seiner Folgederivate
sicher besser. Und womoeglich deutlich schneller.
Einige AVRs haben extra ein 8051-kompatibles External Bus Interface eingebaut. Z.B. Mega 162 (den würd ich jetzt nicht nehmen), Mega 64/128/1280/1281/2560/2561. Da sind Registerzugriffe auf die UARTs wirklich nur Speicherzugriffe. Mit 3.3V UARTs geht z.B. auch ein ATXMEGA128A1U (nur A1U, kein A1 ohne U).
Die Verbindungen sollen nicht nur durchgeschaltet, sondern auch
softwareseitig gefiltert und modifiziert werden können. Beispiel: "Leite
MIDI Input #2 nach MIDI Ouptut #4, aber nur Oktave 1 bis 2, und
transponiere die Noten eine Oktave nach oben".
Es gibt solche Geräte auch im Handel, die allerdings alle nicht so sind,
wie ich es gern hätte.
Das alles konnte/kann das MIDITEMP PMM-88 E (und Geräte der MP-88-Serie) - leider gibt es diese Geräte nicht mehr neu, und gebraucht werden sie auch nicht gerade sehr häufig angeboten...
Aus der Bedienungsanleitung lassen sich evtl. viele brauchbare Features für ein 'Neugerät' ziehen... die Dinger waren (fast) eierlegende Wollmichsäue 😊
Das konnten meines Wissens auch schon die alten Dinger wie Unitor und AMT8 - teils mit programmierbarem Filter und Routing. Ich nehme an, da sass auch nur ein lütter Prozessor drin.
Ich habe sowas schon mal gebaut und einen FPGA damit recycelt. Also 81 Uarts +1 zum steuern auf einem cyclon V. (Mehr Pins waren nicht rausgeführt). Also eine große RS232 Matrix. Das dürfte die Midi Anforderungen gleich mit erfüllen. Also mit FPGA der genug Pins hat lässt sich das problemlos umsetzen. Die Steuerung habe ich dann mit einem Raspberry umgesetzt (hätte aber auch ein esp o.ä. sein können.
Ich hab hier noch so ein unfertiges Projekt liegen für genau sowas, wobei bei mir nicht nur reines Routing, sondern auch ein Mapping von MIDI-Nachrichten erfolgen soll.
Ich habe einen Teensy 4.1 dafür vorgesehen. Der ist zwar von Rechenpower und Speicher her auch deutlich überdimensioniert, hat aber immerhin schon 8 UARTs eingebaut. Außerdem hat er noch USB host und device, und zwar beides gleichzeitig (MIDI-over-USB gibt's für beides schon fertig als Bibliothek, am Host-Port kann man sogar per Hub mehrere Devices gleichzeitig nutzen). Man kann das ganze darüber also auch gleich noch mit dem PC verbinden und mit irgendwelchen Gerätschaften, die kein echtes MIDI haben. Ethernet hat er auch noch. Da könnte man sowas wie OSC (gibt's auch schon eine Bibliothek dafür) oder Ableton Link damit machen. Per OSC konnte ich damit erfolgreich die eingebaute Mischerfunktion von meinem MOTU 16A von einem USB-MIDI-Controller aus ansteuern.
Ich kann das hier empfehlen: Miditech Midiface 16x16.
Selbstbau lohnt nur, wenn man wirklich was Spezielles damit anfangen möchte. Ich brauche MIDI für meinen Synth und da möchte ich in HW bleiben und nicht über SW/FSM oder gar einen MicroController (auch keinen MicroBlaze) gehen und schon gar keine Linux involvieren.
MIDI-Verarbeitung geht auch in sequenziell prozessierender Hardware, wenn man es ein wenig schlau anstellt.
Mit einem FPGA geht es in der Tat sehr einfach. Ich verwende an meinem Synth z.B. Analog-Multiplexer, die mit Faktor 8 getaktet werden und dann auf einen 250 kHz-Eingang gehen. Von denen gibt es 4 womit ich 32 MIDI und 4 DMX an einem 8er Port habe. Das Ganze dann über einen FPGA-Pin um Pins zu sparen. Ich taste dann den Haupt-MUX ab und schalte jedesmal, wenn ein MIDI-Eingang dran ist, den vorgelagerten MUX weiter. Damit kommen die DMX 8x so oft dran, wie die MIDI. Die Überabtastung liegt am Ende im Bereich 16/32 samples pro Bit, reicht also für eine sichere Erkennung und Synchronisiation. Machbar wären Faktor 128 aber ich fahre die auch noch gegen S/PDIF 48 gemuxet. 230k-UARTs kann man auch noch anschließen, die nutzen dann einen DMX mit anderem Skalierungsfaktor.
Auf die Weise habe ich mit wenigen Pins alle Inputs im FPGA.
Einen MIDI-Mixer gibt es natürlich auch. Der multiplext 256 Kanäle auf 256 Ausgänge in gut 300us :-) 128 sind extern (2 x MIDI-S/PDIF mit 64 Kanälen) und die anderen intern für MIDI Echo, Sequenzer und Send Returns, etc.
Wollte ich eigentlich schon längst releasen, aber es finden sich zu wenige Interessenten. Da müsste eine IO-MIDI-Platine gebaut werden und das lohnt nur in Stückzahlen. Aktuell verwende ich mehrere der Arduino-MIDI-Shields, wenn ich DIN-MIDI nutzen will.
FPGA hat er ja schon gesagt, dass ihm das zu kompliziert sei. Wenn man einfach nur 16 UARTs an einem USB haben möchte würde ich persönlich einen FE1.1 USB-Hub (oder FE2.1 siehe LCSC.COM) nehmen, dazu 4x FT4232 (LCSC 8.80$) oder wenn es billiger sein soll zwei CH348. Als HUB-Alternative böte sich noch der USB2514 von TI.
Das alles geht dann an einen RPI bzw. CM4-Modul für die Verarbeitung. Der hat dann die weiteren Schnittstellen.
Aber Achtung bzgl. CH348, auch wenn der Preis lockt: Die 1-Kanal CH340 haben das Problem mit der fehlenden on-Chip Seriennummer, das führt dann zum Anmeldechaos. Besser FT4232 nehmen, die haben das im Griff.
FPGA hat er ja schon gesagt, dass ihm das zu kompliziert sei. Wenn man
einfach nur 16 UARTs an einem USB haben möchte würde ich persönlich
einen FE1.1 USB-Hub (oder FE2.1 siehe LCSC.COM) nehmen, dazu 4x FT4232
(LCSC 8.80$) oder wenn es billiger sein soll zwei CH348. Als
HUB-Alternative böte sich noch der USB2514 von TI.
Das alles geht dann an einen RPI bzw. CM4-Modul für die Verarbeitung.
Der hat dann die weiteren Schnittstellen.
Für ein Einzelstück oder zum Testen würde ich einen fertigen USB 2.0-Hub und solche fertigen Boards wie die hier nehmen.
https://www.amazon.de/dp/B0CT3DJ1QD/
Da ist die Gefahr, Fehler zu machen, am geringsten, und viel billiger als die in Massen gefertigen Chinaboards wird er auch nicht werden.
Das einzige, was er dann noch machen muss, ist ein Adapter von DIN-Buchse auf diese 4-poligen JST Stecker mit Optokoppler dazwischen. Wenn das dann alles so funktioniert, dann kann er davon immer noch eine Leiterplatte machen.
Und er kann auch erstmal mit einem FT4232H anfangen und sich dann schrittweise hocharbeiten.
haben das Problem mit der fehlenden on-Chip Seriennummer,
Wäre im Prinzip auch handhabbar, die UDEV-Rules zum Anlegen der Device-Nodes können statt auf Seriennummer auch auf den "Pfad" matchen, über den das Device angeschlossen ist, also z.B.
Hub1 Port 3 -> Hub2 Port 2 -> CH348 ==> /dev/midi10
Obwohl ich ja trotz aller Historie ein Fan der FTDI-Produkte bin. Die Dinger laufen einfach zuverlässig (was nicht heißen soll, dass der CH348 schlechter sei).
Aber was ist mit 16? So viele UART-Interfaces hat selbst ein STM32 nicht
zur Verfügung.
Etwas viel für einen einzigen µC und mit dem Aufteilen auf mehrere schafft man sich neue Probleme, denn es muss trotzdem alles gelesen, verschickt, überwacht und untereinander koordiniert werden, auch wenn einem die Baudrate hier ziemlich wenig vorkommen sollte. Mit einem STM32H und einer UART-Erweiterung in Hardware könnte das aber vielleicht ganz gut gehen, bei mehreren µControllern bin ich etwas skeptisch, dass einer das alles softwaremäßig fehlerfrei verbinden kann. Ferner bin ich mir nicht ganz sicher, ob man den Aufwand betreiben sollte, einen FPGA extra dafür einzuspannen, aber wer weiß, vielleicht ist es am Ende sogar einfacher als mit einem µC und UART-Erweiterung, vorausgesetzt man kennt sich damit aus.
Wieviel Prozent von deinem "tollen" Design-Vorschlag kannst du denn für
8€ kaufen?
Ich habe völlig unmissverständlich darauf hingewiesen, dass der Zynq-Ansatz nur dann sinnvoll sein kann, wenn die enge Koppelung an einen Embedded-Linux-Rechner einen Vorteil ergibt. Ich habe niemals behauptet, das wäre die billigste Schmalspurlösung.
Für eine ähnliche Applikation mit jedoch nur acht U(S)ARTs und ohne Netzwerk usw. setze ich einen STM32F091 ein. Falls zehn UARTs reichen sollten, käme ansonsten auch ein NXP LPC54xx infrage, insbesondere wenn man auch noch Ethernet verwenden will.
Ferner bin ich
mir nicht ganz sicher, ob man den Aufwand betreiben sollte, einen FPGA
extra dafür einzuspannen, aber wer weiß, vielleicht ist es am Ende sogar
einfacher als mit einem µC und UART-Erweiterung, vorausgesetzt man kennt
sich damit aus.
Naja, mit Vivado kann man sich recht schnell einen Microblaze mit zig UARTs zusammenbasteln.
Naja, mit Vivado kann man sich recht schnell einen Microblaze mit zig
UARTs zusammenbasteln.
Bei dem FPGA-Einsatz sehe ich grundsätzlich zwei mögliche Ansätze – mit oder ohne Softcore – beide Versionen haben ihre Vor- und Nachteile. Bei der Version ohne Microblaze könnte man z.B. seinen Lieblings-µC anbinden, mit dem man sich schon gut auskennt, ohne sich explizit mit einer neuen CPU/MCU auseinandersetzen zu müssen.
der Propeller Microcontroller von Parallax wäre dafür optimal da sich die I/Os beliebig konfigurieren lassen. Der Propeller1 hat 32, der Propeller2 hat 64 I/O.
Aber für ein Einzelstück und Hobbyprojekt ist es egal, ob die
Hardware 10 oder 50 Euro kostet.
Egal? Naja.
Klar, es hat natürlich nicht dieselbe Relevanz wie bei einer Großserie, aber man muss ja auch nicht sinnlos mit dem Geld rumprassen.
Zumal ohne jeden echten Nutzeffekt bei Verwendung von irgendwas "Grösserem". Eher sind im Gegenteil Nachteile bezüglich der erreichbaren Latenzen zu befürchten. Ganz sicher jedenfalls, sobald irgendein Linux auf einem Softcore in's Spiel kommt.
Zumal ohne jeden echten Nutzeffekt bei Verwendung von irgendwas
"Grösserem". Eher sind im Gegenteil Nachteile bezüglich der erreichbaren
Latenzen zu befürchten. Ganz sicher jedenfalls, sobald irgendein Linux
auf einem Softcore in's Spiel kommt.
Seit wann geht es denn in diesem Thread um Linux auf einem Softcore? Das ginge zwar prinzipiell auch auf einem Microblaze, wäre dort aber ziemlich sinnlos, da dafür auf jeden Fall externes RAM benötigt würde und man mit dem BRAM nicht mehr auskäme.
Selbst bei dem Ansatz mit einem Zynq bietet es sich natürlich an, den eigentlichen MIDI-Router komplett in der PL auszuführen und das PS nur noch für die Konfiguration und ggf. das "Netzwerk-MIDI" zu verwenden.
Seit wann geht es denn in diesem Thread um Linux auf einem Softcore?
Ging es nicht. Hatte nur irgendeiner der anderen Blähungs-Lover eingeführt. Das warst aber nicht du.
Selbst bei dem Ansatz mit einem Zynq bietet es sich natürlich an, den
eigentlichen MIDI-Router komplett in der PL auszuführen und das PS nur
noch für die Konfiguration und ggf. das "Netzwerk-MIDI" zu verwenden.
Oder halt auf das ganze aufgeblasene Gedöhns komplett verzichten, was nix besser könnte als die Mini-Lösung mit 3xAVR128DB64, dafür aber in jedem Fall erheblich mehr kosten würde.
Was ist an dieser einfachen Logik zur Wahl eines sinnvollen Designs so schwer zu verstehen?
Nur um die Diskussion in Gang zu halten…
Ich werfe mal RP2040 ein.
6 UARTs: Ohne nachdenken zu müssen.
9 UARTs: Mit ein wenig nachdenken. (sehr wenig!)
Wenn's mehr sein müssen, zwei davon über I²C oder SPI verbunden.
Geht dann allerdings auch gleich richtig ins Geld: 2×1€
Bei fertigen Platinen sogar 2×4€.
Und man hat leider nur vier ARM Kerne. ;-)
Was man schlussendlich braucht, haengt ganz entscheidend davon ab,
was man damit machen will.
So ein 16 Port Multi-UART auf einem FPGA, haette den Vorteil,
dass die Routingsoftware die MIDI-Daten gepuffert und ohne eigenen
Aufwand "hineingeschoben" bekommt, und sich darum nicht kuemmern muss.
Die damit gewonnene "Freizeit" :) hat sie auch dringend noetig,
wenn sie noch Algorithmen auf diese Daten anwenden muss.
Wenn es richtig gut werden soll, wird man diese Algorithmen von einem
Interpreter ausfuehren lassen. So kann man spaeter auch Dinge treiben,
die man beim initialen Entwurf noch gar nicht auf dem Schirm hatte.
Dann koennte man sich ueberlegen, diese Interpreter per MIDi-Kanal
als spezialisierte Softcores auch gleich auf dem FPGA laufen zu lassen.
Die moegliche parallele Instanziierung dieser Softcores ist ja gerade
der Vorteil eines FPGA. (Und eben nicht unbedingt ein Linux laufen
zu lassen. :)
Ausgangspunkt fuer einen solchen Softcore koennte z.B. fuer die
Arithmetik, der 16 bit Emulator in den alten Apples sein.
Angereichert um Befehle die MIDI-Attribute/Events extrahieren und
transformieren.
Der dann am FPGA angeschlossene Controller kann sich dann auf
Trivialfalle, Housekeeping und das Laden und Speichern der
Konfiguration beschraenken.
Gluecklicherweise brauche ich sowas nicht. Das macht der Sequenzer
in einem fuer mich hinreichenden Umfang nebenbei mit.
Nur um die Diskussion in Gang zu halten…
Ich werfe mal RP2040 ein.
6 UARTs: Ohne nachdenken zu müssen.
9 UARTs: Mit ein wenig nachdenken. (sehr wenig!)
Wenn's mehr sein müssen, zwei davon über I²C oder SPI verbunden.
Geht dann allerdings auch gleich richtig ins Geld: 2×1€
Bei fertigen Platinen sogar 2×4€.
Und man hat leider nur vier ARM Kerne. ;-)
Nur um die Diskussion in Gang zu halten…
Ich werfe mal RP2040 ein.
6 UARTs: Ohne nachdenken zu müssen.
9 UARTs: Mit ein wenig nachdenken. (sehr wenig!)
hat er nur zwei UARTs. Die weiteren vier bzw. sieben würdest du dann mit
den GPIOs in Software machen?
Vermutlich würde er es mit den PIOs machen wollen. Allerdings kommen mir die angegebenen Zahlen ein wenig komisch vor. So ein RP2040 hat zwei PIOs, auf jeder davon können vier unabhängige Programme ("state machines") gleichzeitig laufen. Macht also grob 8 UARTs. Dazu kommen die zwei dedizierten UARTs des RP2040. Macht dann also in erster Näherung 10 UARTs.
Etwas problematisch ist die Tatsache, dass die vier Programme einer PIO sich einen gemeinsamen Programmspeicher von nur 32 Instruktionen Umfang teilen müssen. Könnte sein, dass die von Norbert genannte Beschränkung hierher kommt. Ich habe das Konzept nicht bis in's Detail durchdacht. Klar ist aber, dass die Programme für die 4 state machines einer PIO nicht vollständig identisch sein können, da sie ja verschiedene Pins benutzen müssen. Dadurch könnte es tatsächlich eng werden im Programmspeicher.
Bei der Preisbetrachtung der wirklich spottbilligen "nackten" RP2040 darf man übrigens nicht vergessen, dass da immer noch zusätzlich ein QSPI-Flash-IC erforderlich ist. Dadurch wird das preislich schon nicht mehr ganz so attraktiv. Effektiv dürften die Kosten so ungefähr auf demselben Level landen wie die von mir vorgeschlagene Lösung mit 3x AVR128DB64.
Die weiteren vier bzw. sieben würdest du dann mit
den GPIOs in Software machen?
Dein Ansatz würde mich hier interessieren.
Wie du schon sagtest, zwei Hardware UARTs sind ja direkt verfügbar.
Wenn die weiteren UARTs ebenfalls Full-Duplex (Rx/Tx) sein sollen, dann werden für die sieben zusätzlichen UARTs die zwei PIOs komplett genutzt.
Man kann allerdings beliebig viele Tx-UARTs (Limit sind die physikalischen Pins) ansteuern.
Etwas problematisch ist die Tatsache, dass die vier Programme einer PIO
sich einen gemeinsamen Programmspeicher von nur 32 Instruktionen Umfang
teilen müssen. Könnte sein, dass die von Norbert genannte Beschränkung
hierher kommt. Ich habe das Konzept nicht bis in's Detail durchdacht.
Nein, die Beschränkungen liegen woanders.
Klar ist aber, dass die Programme für die 4 state machines einer PIO
nicht vollständig identisch sein können, da sie ja verschiedene Pins
benutzen müssen. Dadurch könnte es tatsächlich eng werden im
Programmspeicher.
Nein, die Statemachines arbeiten pro PIO allesamt mit dem selben (nicht dem gleichen) PIO Asm Code. Da ist am Ende noch reichlich ungenutzter Platz.
Bei der Preisbetrachtung der wirklich spottbilligen "nackten" RP2040
darf man übrigens nicht vergessen, dass da immer noch zusätzlich ein
QSPI-Flash-IC erforderlich ist. Dadurch wird das preislich schon nicht
mehr ganz so attraktiv.
Eine komplette, lauffähige Platine kostet die erwähnten 4€.
Macht also grob 8 UARTs. Dazu kommen die
zwei dedizierten UARTs des RP2040. Macht dann also in erster Näherung 10
UARTs.
Beitrag "8 UART's mit asm_pio PIO DMA / Micropython auf dem PI PICO"
Na ja, wenn man gerne komplette UARTs (Rx UND Tx) hätte, dann kommt man mit diesem einfachen Ansatz nur auf 4 UARTs.
Das geht besser.
Wie gesagt, 2+7 volle UARTs plus beliebig viele Tx UARTs.
Wenn man's also auf die Spitze treiben will:
9 volle UARTs:
(2+7)×2 Tx/Rx Pins:
7 halbe UARTs:
7 Tx Pins
Ach ja, ebenfalls mit Micropython realisiert. Und die Kerne langweilen sich.
Na ja, wenn man gerne komplette UARTs (Rx UND Tx) hätte, dann kommt man
mit diesem einfachen Ansatz nur auf 4 UARTs.
Das geht besser.
Wie gesagt, 2+7 volle UARTs plus beliebig viele Tx UARTs.
Wenn man's also auf die Spitze treiben will:
9 volle UARTs:
(2+7)×2 Tx/Rx Pins:
7 halbe UARTs:
7 Tx Pins
Ach ja, ebenfalls mit Micropython realisiert. Und die Kerne langweilen
sich.
Warum mit diesem Hipster-Kram Micropython? Ist das olle C bzw. C++ jetzt altes Eisen? Zu leistungsfähig?
Das Problem der Soft-UARTs ist der Empfang, Senden geht relativ einfach und mit wenig Rechenleistung, auch bei 16 Kanälen. Mit DMA noch viel einfacher.
Ok, Ees ist ein Compiler und nicht wie beim normalen Python ein Interpreter. Und trotzdem, was ist der große Vorteil davon? Ich seh keinen. Bestenfalls das Python-Programmierer leichter in Mikrocontroller einsteigen können. Was aber eher fragwürdig ist, denn Python ist eine hoch abstrakte Programmiersprache, die hier als hardwarenah gepriesen wird. Schon komisch.
Gibt es belastbare Vergleiche zwischen C und Micropython bezüglich der Leistung?
When a module is imported, MicroPython compiles the code to bytecode which is then executed by the MicroPython virtual machine (VM). The bytecode is stored in RAM. The compiler itself requires RAM, but this becomes available for use when the compilation has completed.
Also ein Byte Code Interpreter auf einem Mikrocontroller. Darauf hat die Welt gewartet!
Gibt es belastbare Vergleiche zwischen C und Micropython bezüglich der
Leistung?
Das ist recht einfach zu beantworten.
Ungenutztes RAM wird nicht rückerstattet.
Ungenutzte Kerne werden nicht rückerstattet.
Ungenutzte CPU-Leistung wird nicht rückerstattet.
Wenn eine gestellte Aufgabe zur Zufriedenheit aller gelöst werden kann, kann man es zur Not auch in INTERCAL programmieren.
Am Ergebnis ändert sich nichts.
Und ja, wenn notwendig programmiere ich auch in Asm,C oder unzähligen anderen…
Meine Frage an den TO: sind die 16 TX/RX zwingend notwenig?
Im Grunde würde ich auch zu einem RP2040 Pico-Board raten, aber die Pins reichen für 16 Duplex-Kanäle nicht aus. Reduziert man auf beispielsweise 10 Kanäle hat man alle Möglichkeiten und einen leistungsfähigen µC.
Verwendet man die PIOs, kann man jeden beliebigen IO-Pin als RxD oder TxD verwenden und auch dynamisch neu zuordenen (multiplex) - je nach dem was besser klingt ;-)
Gibt es belastbare Vergleiche zwischen C und Micropython bezüglich der
Leistung?
Das ist recht einfach zu beantworten.
Ungenutztes RAM wird nicht rückerstattet.
Ungenutzte Kerne werden nicht rückerstattet.
Ungenutzte CPU-Leistung wird nicht rückerstattet.
Wenn eine gestellte Aufgabe zur Zufriedenheit aller gelöst werden kann,
kann man es zur Not auch in INTERCAL programmieren.
Am Ergebnis ändert sich nichts.
Im Grunde würde ich auch zu einem RP2040 Pico-Board raten, aber die Pins
reichen für 16 Duplex-Kanäle nicht aus.
MIDI ist ja normalerweise nicht Duplex.
d.h. 2× MIDI-In, 16×MIDI-Out könnte für viele Anwendungen gut reichen, und würde problemlos in den RP2040 (oder auch STM32 mit genug Pins) passen.
Die INs per HW-UART, die OUTs per Software.
Die Anzahl der OUTs ist relativ egal, alle 32µs ein gpio_put_all/gpio_put_masked...
MIDI ist ja normalerweise nicht Duplex.
d.h. 2× MIDI-In, 16×MIDI-Out könnte für viele Anwendungen gut reichen,
und würde problemlos in den RP2040 (oder auch STM32 mit genug Pins)
passen.
Mit MIDI hatte ich nie zu tun. Musiker wollten ihre Rechnungen immer erst nach erscheinen ihrer LP/CD bezahlen, was einem Zahlungsausfall gleich kam ;-)
Wenn Deine Einschätzungen vom TO geteilt werden, passt der RP2040 wohl richtig gut.
Die moegliche parallele Instanziierung dieser Softcores ist ja gerade
der Vorteil eines FPGA.
Das ist aber hier ziemlicher overkill. Die MIDI-Verarbeitung benötigt eine Reaktionszeit im Bereich der Latenz der Übermittlung, damit das Verschalten das nicht unnötig verlängert. Die Übermittlung eines MIDI-Pakets geht mit gut 30kHz und hat eine Wertfrequenz von 3kH. Bei 16 Kanälen reichen 50kHz Verarbeitungsfrequenz.
Das geht mit einer einzigen Einheit im FPGA und Multiplex. Das packen auch DSPs und MCUs, wenn es nur 16 Ausgänge sein müssen.
Bestenfalls das Python-Programmierer leichter in Mikrocontroller
einsteigen können.
Python oder was Ähnliches hier einzusetzen, sehe ich nicht.
MIDI hat eine sehr begrenzte Befehlssatzstruktur und gefiltert werden da eigentlich nur SYS-EX und fremde System-Infos sowie die kanalweisen Split-Informationen, die verteilt werden müssen. Alles andere ist Layering, also Duplizierung oder Shifting auf andere Oktaven.
Die dazu nötigen Abfragen, um den neuen Kanal zu berechnen oder Shifts sowie Splits zu machen, beschränken sich auf 10-20 "IF"s je MIDI-Controll-Wort und davon kommen im Schnitt nur alle 3-10 MIDI-Bytes solche Worte oder andere Daten, die man untersuchen muss und nicht direkt weiterschiebt.
Im Schnitt sind das < 5 Fragen und vielleicht 3 Speicheraktionen je MIDI-Wort. Ein durchschnittler MC braucht da keine 10 Takte zu. -> 300.000.
Ich würde mit 1 Mio MCU Takten je Kanal rechnen bei maximaler Dichte.
Bei mittlerer Dichte tut es die Hälfte. Aus meiner Sicht kann ein 10 MHz AVR so eine 16er Schalterei leisten.
Das macht der Sequenzer
in einem fuer mich hinreichenden Umfang nebenbei mit.
So ist es.
Bei mir ist es umgedreht: Mein FPGA, das den MIDI-Empfang und das Routing regelt, macht noch die Sequencer mit. Inzwischen sind es 4 mit 32 Spuren, die sich DJ-mäßig wie Schallplatten verhalten. Dazu gibt es Arpeggiatoren und MIDI-Echos und Filter und Replikatoren sowie Vereiniger. Alles in HW programmiert. Da der FPGA noch nicht voll ist, macht er nebenher noch Video.
Verschalten das nicht unnötig verlängert. Die Übermittlung eines
MIDI-Pakets geht mit gut 30kHz
Bitrate.
und hat eine Wertfrequenz von 3kH.
Byterate.
Bei 16
Kanälen reichen 50kHz Verarbeitungsfrequenz.
Naja, aber in den 50kHz muss einiges passieren.
Das geht mit einer einzigen Einheit im FPGA und Multiplex.
Ja, aber . . .
Das packen
auch DSPs und MCUs, wenn es nur 16 Ausgänge sein müssen.
Naja, WELCHE DSPs? Ein 500MHz Blackfin vielleicht. Ein 60 MHz Piccolo? Keine Ahnung. Ein 20 MHz AVR hat bei 16 Soft-UART Kanälen mit 31 kBaud beim Empfangs schon VERDAMMT viel zu tun? Ob das real möglich ist?
Falk B. schrieb:
Bestenfalls das Python-Programmierer leichter in Mikrocontroller
einsteigen können.
Python oder was Ähnliches hier einzusetzen, sehe ich nicht.
Ich auch nicht, es war nur eine spitze Bemerkung auf den Beitrag, daß man ja einen RP2040 mit Micropython nutzen könnte, um die PIOs zu konfigurieren.
Im Schnitt sind das < 5 Fragen und vielleicht 3 Speicheraktionen je
MIDI-Wort. Ein durchschnittler MC braucht da keine 10 Takte zu. ->
300.000.
Ich würde mit 1 Mio MCU Takten je Kanal rechnen bei maximaler Dichte.
Bei mittlerer Dichte tut es die Hälfte. Aus meiner Sicht kann ein 10 MHz
AVR so eine 16er Schalterei leisten.
Eine optimistische Abschätzung, vor allem, wenn der keine 16 UARTs in Hardware hat. Wenn die MIDI-Daten im Speicher liegen, ist es freilich machbar.
Ich kann das hier empfehlen: Miditech Midiface 16x16.
Ich habe mal danach gesucht und
das Midiface ist ein „dummes“ Interface ohne interne Routing- und Filtermöglichkeiten.
Es braucht USB, also kein Stand-Alone-Betrieb.
Okay, da habe ich mich wohl missverständlich ausgedrückt - sorry! Die
Verbindungen sollen nicht nur durchgeschaltet, sondern auch
softwareseitig gefiltert und modifiziert werden können. Beispiel: "Leite
MIDI Input #2 nach MIDI Ouptut #4, aber nur Oktave 1 bis 2, und
transponiere die Noten eine Oktave nach oben".
Das MIDITEMP PMM-88 E ist da schon besser geeignet, aber die Gebrauchtpreise, die ich gesehen habe, sind horrend.
Ein Projekt mit dem rp2040 ist da schon interessanter...
Soooo, ich entschuldige mich für die längere Funkstille - ich habe selbstverständlich mitgelesen und freue mich über die rege Diskussion in diesem Thread, die Anfeindungen mal ausgenommen :)
Mal schauen, ob ich alles beisammen bekomme, da mir jede Nachricht zu zitieren doch etwas zu zeitaufwendig ist, und sich die Vorschläge auch teils wiederholen.
Fertige Geräte á la "MIDITEMP PMM-88 E" oder "Midiface 16x16": das hatte ich auch schon gesehen. Das MIDITEMP ist ein gutes Teil, und wäre wahrscheinlich auch ein Mittel zur Wahl gewesen, wenn ich nicht doch manchmal den Drang hätte, meine Kenntnisse der Elektronik zu verbessern, und mir so etwas selber zu bauen. Ich bin also tatsächlich nicht "nur" an einer Plug&Play-Lösung interessiert, sondern auch an etwas, wo ich noch was lernen kann. Das Midiface ist nur ein "dummes" Interface, wie Matthias schreibt. Da könnte man zwar sicherlich softwaretechnisch dann realisieren, was ich möchte, aber ihr habt auch richtig erkannt, dass ich das ganze ohne Computer einsetzen möchte - also Standalone.
Zur Frage ob ich wirklich 16 I/Os brauche: jein. Momentan nicht, aber ich kann sehen, dass ich mich in 5 Jahren, wenn mein Geldbeutel die Aqcuise weiterer teils unnötig teurer Synthesizer zulässt, ärgere, dass ich nicht mehr zur Verfügung hab. Wobei man auch den Platzmangel, sowie den WAF (wife acceptance factor) berücksichtigen muss (sollte).
Thema FPGA: ich muss zugeben, dass das für mich bislang ein rotes Tuch war, da ich da wirklich so gar keine Berührungspunkte mit gesammelt habe. Aber es ist ja auch nie zu spät. Ich habe mir die Welt der FPGAs mal angesehen, und es hört sich durchaus interessant und lernenswert an, nur glaube ich, dass das ein Fass ohne Boden sein könnte - gerade wenn ich bedenke, dass ich auch noch ca. zehn andere Hobbyprojekte auf dem Tisch liegen habe, die ähnlich behandelt werden wollen.
CH348/T4232: hört sich grundsätzlich gut an. An die Ansprache per USB habe ich noch nicht gedacht. Vorteil wäre eine Form von Unix, und sogar die Möglichkeit, USB-Class-MIDI-Geräte mit einzubinden, ohne das komplizierter handhaben zu müssen. Auch Netzwerk usw. ist dann schon dabei. Ein kleiner Pi + irgenwelche chinesischen Platinen, die oben genannte Treiber einsetzen, könnte also als proof of concept durchaus reichen. Wenn man es softwaretechnisch nicht all zu dumm anstellt, könnte ich damit zumindest mal eine funktionierende Version bauen. Ob der "backend" dann später eben solche USB-Karten ansteuert, oder irgendwie doch mehr low-level arbeitet, ist dem "frontend" dann auch egal.
Ich merke immer wieder, dass selbstverständlich eintausend Wege nach Rom führen, ich dann aber auch manchmal überlegen muss, wie viel ich wirklich selber machen möchte, und wie viel off-the-shelf ich zulasse. Um überhaupt einmal zu gucken, ob sich so eine Lösung für mich durchsetzen wird, tendiere ich tatsächlich erstmal zu einem Pi und zwei CH348-Karten, in der Hoffnung, dass die UDEV-Nodes dann sauber aufgeteilt sind. Und von da an... mal sehen!
Ich bedanke mich bei euch für die zahlreichen Antworten - ich hätte nicht gedacht, dass ich damit ein solches Diskussionspotential entfache. Ich werde mich dennoch mal mit dem Thema FPGA auseinander setzen. Gibt es da irgendwelche Evaluation Boards oder schöne Bücher/Webseiten, die einen da gut einführen?
Ich werde mich dennoch mal mit dem Thema FPGA auseinander setzen. Gibt
es da irgendwelche Evaluation Boards oder schöne Bücher/Webseiten, die
einen da gut einführen?
Viele FPGA-Entwicklungsboards sind maßlos überfrachtet mit allen möglichen Peripheriekomponenten, derer man sich ggf. mühsam entledigen muss, um die Pins frei zu bekommen. Ein äußerst praktikabler Weg besteht darin, sich bei Trenz eines von deren FPGA-Modulen auszusuchen, für die es eine Trägerplatine gibt. Damit kann man schon sehr viel herumprobieren.
Für den Einsatz in der eigenen Hardware steckt man dann eben das FPGA-Modul um.
... hört sich grundsätzlich gut an. An die Ansprache per USB
habe ich noch nicht gedacht.
Vergiss USB schnell wieder. Um ein Zeichen/Byte zu uebertragen,
muss USB das auf eine Mindestpaketgroesse aufblasen.
Deswegen "sammeln" solche seriellen USB-Adapter gerne Zeichen,
bis ein Timeout dann die Sammelei abbricht, und das Paket dann
uebertraegt. Du darfst dir gerne selbst ausrechnen, was es heisst
wenn aus einem Byte ein Paket von 64 Bytes wird.
Ausserdem zerstoert das nebenbei auch jede zeitliche Struktur die
in MIDI-Daten steckt.
Empfehlungen fuer FPGA-Einsteigerboards findest du hier im Forum
mehr als reichlich. Fuer den Anfang wuerde ich mich der Meinung
von Andreas anschliessen. Solche Module gibt es u.a. auch von
Waveshare.
... hört sich grundsätzlich gut an. An die Ansprache per USB
habe ich noch nicht gedacht.
Vergiss USB schnell wieder.
Sehe ich nicht so. Beim FT4232 ist die Standard-Latenz 16ms, lässt sich aber auf 0 runterdrehen. Ja, dann ist sicher einiges an Overhead auf dem USB, aber wen juckt das. Ist ja nicht so, dass der RPI nebenbei noch Primzahlen rechnen müsste. Durch das Linux-System gewinnt er Zugriff auf zahlreiche Software in diesem Bereich.
Ich werde mich dennoch mal mit dem Thema FPGA auseinander setzen. Gibt
es da irgendwelche Evaluation Boards oder schöne Bücher/Webseiten, die
einen da gut einführen?
Wenn jemand noch nie Berührung mit einem FPGA hatte, werden die meisten solcher 'Evaluationsboards' – aufgrund der Fülle an dort verbauter Bauteile und Komplexität – einen erschlagen bzw. total überfordern – natürlich wird man solche Boards schon irgendwie mit einem Beispiel zum Laufen bekommen, ob man von diesen Vorgängen aber auch nur ansatzweise etwas richtig nachhaltig verstanden haben wird, ist eine ganz andere Frage, die meisten geben das Vorhaben u.a. deswegen ganz schnell wieder auf. Am Ende liegen die Platinen dann nutzlos in der Schublade oder werden wieder verkauft. So ganz am Anfang ist es ganz gut, sich erstmal einen kleinen, lötbaren CPLD (z.B. CoolRunner-II in TQFP44 mit 0.8mm) zu nehmen, um damit die ersten Schritte in die Richtung FPGA zu machen, denn wenn man es hier gut verstanden hat, kann man sich als nächstes einem kleinen FPGA nähern. Ich entwerfe gerade eine Evaluationsplatine mit einem FPGA, wo ich explizit auf diesen ganzen Überhang/Überschuss an Peripherie verzichte, aber das wird noch einige Wochen dauern, bis es für jedermann verfügbar ist.
Die meisten Adepten und Halbstarken machen es leider genau umgekehrt – sie bestellen sich irgendeine, fertige Platine mit einem FPGA in BGA mit Hunderten IOs, wo noch andere diverse Peripherie auf einer hochwertigen Multilayerplatine angekoppelt ist, man die Teile nur noch unter Lupe erkennen kann, und versuchen damit zu spielen und die ersten Schritte zu machen. Also am besten am Anfang immer schön den Ball flachhalten und versuchen, das Thema in kleinen Häppchen nach und nach zu verdauen, sonst verschluckt man sich ganz schnell mit einem zu großen Happen – wie komplex die Thematik der FPGAs ist, sieht man auch schon anhand der vielen Datenblätter, die man leider auch durchforsten und studieren muss. Deswegen werden es irgendwelche Hardware-, Register- und Datenblattphobiker niemals schaffen, hier Fuß zu fassen; und das ist auch gut und gerecht so, finde ich.
Eine optimistische Abschätzung, vor allem, wenn der keine 16 UARTs in
Hardware hat.
Man braucht keine UARTs in HW. Ich habe vor 25 Jahren mal einen HC08 mit 8 UART-Funktionen bestückt: Einfach mit 5-facher Rate per Interrupt einen Port mit 8 Bit absampeln und bei Erkennen einer 0 anfangen zu zählen, jedesmal hochzählen und nach 50 Takten einen Marker setzen. Dann eine Routine asynchron auf Marker checken die 50 samples verarbeiten, Bits per Mehrheitsentscheid isolieren und das Wort zusammenbauen. Das funktionierte für isoliert arbeitende Kanäle, die eigene Quarze und damit eigene Frequenzen hatten.
Aber wie gesagt, ab einer gewissen Kanalzahl lohnt einfach ein FPGA. Es braucht einen einzigen Verarbeiter den man multiplext.
Wenn jemand noch nie Berührung mit einem FPGA hatte, werden die meisten
solcher 'Evaluationsboards' – aufgrund der Fülle an dort verbauter
Bauteile und Komplexität – einen erschlagen bzw. total überfordern
Man wird schon mit so einem Board anfangen müssen, um was zum Lernen und zum Testen zu haben und dann, wenn man mit FPGAs fit ist, ein kleines Modul kaufen, um damit real zu arbeiten und die Anwendung hinzuzimmern.
Eventuell klappt es in einem all-in-one-step hiermit:
"Los FPGA EP2C5T144 Learning Development Kit für Cyclone II Altera FPGA"
Auf der gleichen Plattform gab es vor Jahren mal kleine FPGA-boards zu unter 10,- mit MAX2 etc..
Eine optimistische Abschätzung, vor allem, wenn der keine 16 UARTs in
Hardware hat.
Man braucht keine UARTs in HW. Ich habe vor 25 Jahren mal einen HC08 mit
8 UART-Funktionen bestückt: Einfach mit 5-facher Rate per Interrupt
einen Port mit 8 Bit absampeln
Naja. Es sind hier 32kBaud, macht bei x5 immerhin 150kHz bzw. ~6us Periodendauer. Da kommt auch der nicht ganz so lahme AVR schon ins Schwitzen, zumal auch noch ein "paar" andere Dinge zu tun sind.
Der AVR kann verdammt viel, aber auch er hat Grenzen.
Man überzeuge mich mit REALEM Quelltext, wenn ich denn falsch liegen sollte.
Dein HC08 hat wahrscheinlich 300 Baud TTY eingelesen ;-)
So ganz am Anfang ist es ganz gut, sich erstmal
einen kleinen, lötbaren CPLD (z.B. CoolRunner-II in TQFP44 mit 0.8mm) zu
nehmen, um damit die ersten Schritte in die Richtung FPGA zu machen,
Unsinn! Sowas kauft man GERADE als Anfänger fertig! Da gibt es mehr als genug Boards bzq. USB-Sticks mit integriertem Programmieradapter.
CPLDs sind viel zu klein und heute nahezu out. Selbst das kleineste FPGA kostet das Gleiche und kann 100x mehr!
Sowas oder ähnlich, gibt es vermutlich auch billiger.
denn wenn man es hier gut verstanden hat, kann man sich als nächstes
einem kleinen FPGA nähern. Ich entwerfe gerade eine Evaluationsplatine
mit einem FPGA, wo ich explizit auf diesen ganzen Überhang/Überschuss an
Peripherie verzichte, aber das wird noch einige Wochen dauern, bis es
für jedermann verfügbar ist.
Kann man machen, es gibt aber genügend davon auf dem Markt. Da hat man als Anfänger eher das Probem des unübersichlichen Angebots.
Die meisten Adepten und Halbstarken machen es leider genau umgekehrt –
sie bestellen sich irgendeine, fertige Platine mit einem FPGA in BGA mit
Hunderten IOs, wo noch andere diverse Peripherie auf einer hochwertigen
Multilayerplatine angekoppelt ist,
Stimmt. Aber davon wurde ja schon mehrfach abgeraten. Ich glaube der OP kann lesen und das auch verstehen.
man die Teile nur noch unter Lupe
erkennen kann, und versuchen damit zu spielen und die ersten Schritte zu
machen. Also am besten am Anfang immer schön den Ball flachhalten und
versuchen, das Thema in kleinen Häppchen nach und nach zu verdauen,
sonst verschluckt man sich ganz schnell mit einem zu großen Happen – wie
komplex die Thematik der FPGAs ist, sieht man auch schon anhand der
vielen Datenblätter, die man leider auch durchforsten und studieren
muss. Deswegen werden es irgendwelche Hardware-, Register- und
Datenblattphobiker niemals schaffen, hier Fuß zu fassen; und das ist
auch gut und gerecht so, finde ich.
Die letzte Männerdomäne, nachdem Assembler und Mamutjagd ausgestorben sind! ;-)
Unsinn! Sowas kauft man GERADE als Anfänger fertig! Da gibt es mehr als
genug Boards bzq. USB-Sticks mit integriertem Programmieradapter.
CPLDs sind viel zu klein und heute nahezu out. Selbst das kleineste FPGA
kostet das Gleiche und kann 100x mehr!
Also am besten von Deinem Trip hier eine Bulldogge zu machen schön runterkommen, denn es ging dabei nicht darum, die UARTs damit zu erledigen, sondern sich der Thematik der FPGAs zu nähern und da ist klein genau das richtige, auch wenn es Dir nicht passen sollte. Nochmal lesen hilft.
Das finde ich interessant. Wie schaffen es denn dann z.B. der Midiface oder jegliche USB-MIDI-Geräte zeitlich synchron und latenzarm (auch mit vielen Geräten über einen Hub) zu operieren? Ob ich sechs UARTs per USB-Karte, oder sechs Synths per Hub ansteuere, dürfte doch vergleichbar sein?
Vielen Dank für eure Empfehlungen. Ich habe morgen Urlaub und lese mich mal ein!
... hört sich grundsätzlich gut an. An die Ansprache per USB
habe ich noch nicht gedacht.
Vergiss USB schnell wieder.
Sehe ich nicht so. Beim FT4232 ist die Standard-Latenz 16ms, lässt sich
aber auf 0 runterdrehen.
In der Standardeinstellung wird also alles in Haeppchen mit je 16 ms
Inhalt verhackstueckt. Und 0 wird man auch nicht erreichen. :)
Das sind Adapter die fuer eine "serielle Uebertragung von Daten"
gedacht sind. Fein wird man denken, MIDI ist ja seriell.
Aber auf seine spezielle Art.
... Ja, dann ist sicher einiges an Overhead auf dem
USB, aber wen juckt das. Ist ja nicht so, dass der RPI nebenbei noch
Primzahlen rechnen müsste. Durch das Linux-System gewinnt er Zugriff auf
zahlreiche Software in diesem Bereich.
Die der TO wozu gebrauchen soll? Bevor sein MIDI-Byte in seinem
Userspace angekommen ist, kommen auch noch Latenzen im System dazu.
Beim Senden genau das selbe noch einmal. Und die kann man vorher
noch nicht einmal genau beziffern. Da reicht u.U. ein wenig
Broadcasttraffic auf dem Netzwerk, dass das ganze zu "Eiern" anfaengt.
Bevor ich mit so etwas Zeit verschwende, wuerde ich ja sogar eine
Platine voll mit 16C450 und einem Controller vorziehen.
Das finde ich interessant. Wie schaffen es denn dann z.B. der Midiface
oder jegliche USB-MIDI-Geräte zeitlich synchron und latenzarm (auch mit
vielen Geräten über einen Hub) zu operieren? Ob ich sechs UARTs per
USB-Karte, oder sechs Synths per Hub ansteuere, dürfte doch vergleichbar
sein?
Vermutlich gibt es fuer USB-MIDI-Controller eine andere Spezikation
im USB-Standard. Man muss dort ja keine serielle Schnittstelle mit
einer fuer USB niedrigen Baudrate emulieren.
Bei einem USB-MIDI-Adapter auf "serielles" MIDI, kann man ja die
Paketlatenz auf 1 ms einstellen. Da wuerden dann ca. 30 MIDI-Bytes
in ein Paket passen. Oder auch nur Eines.
Es koennte also schon Unterschiede geben, ob per UART oder per
USB-MIDI angesteuert.
Und ob die Geraete das wirklich latenzarm und wirklich synchron schaffen? Das muesste man nachmessen.
Ich haette fuer den Begriff "synchron" vermutlich auch eine strengere
Definition. :)
Nach der muesste man bezogen auf eine "Sample Rate" genau triggern
koennen.
Das finde ich interessant. Wie schaffen es denn dann z.B. der Midiface
oder jegliche USB-MIDI-Geräte zeitlich synchron und latenzarm (auch mit
vielen Geräten über einen Hub) zu operieren?
USB 2.0 Full Speed (12 Mbit/s) hat 1kHz Frame clock, USB 2.0 High Speed 8kHz. Damit kann man prinzipiell 1 Byte/Frame übertragen, auch wenn das nicht sonderlich effizient ist, wohl aber verzögerungsarm. MIDI mit seinen 32kBaud hat 3kHz sprich 330us Bytetakt.
Also am besten von Deinem Trip hier eine Bulldogge zu machen schön
runterkommen, denn es ging dabei nicht darum, die UARTs damit zu
erledigen, sondern sich der Thematik der FPGAs zu nähern und da ist
klein genau das richtige, auch wenn es Dir nicht passen sollte. Nochmal
lesen hilft.
Also am besten von Deinem Trip hier eine Bulldogge zu machen schön
runterkommen, denn es ging dabei nicht darum, die UARTs damit zu
erledigen, sondern sich der Thematik der FPGAs zu nähern und da ist
klein genau das richtige, auch wenn es Dir nicht passen sollte. Nochmal
lesen hilft.
Gleichfalls!
Also, wie ich bereits sagte, erstmal von Deinem Trip runterkommen, dann klappt es bestimmt auch besser mit dem Kontexterfassen der Aussagen – in Deinem jetzigen Zustand ist das nicht überzeugend, eher mangelhaft. Viel Erfolg!
Man muss dort ja keine serielle Schnittstelle mit
einer fuer USB niedrigen Baudrate emulieren.
Bei einem USB-MIDI-Adapter auf "serielles" MIDI, kann man ja die
Paketlatenz auf 1 ms einstellen. Da wuerden dann ca. 30 MIDI-Bytes
in ein Paket passen. Oder auch nur Eines.
Bei USB-MIDI hat jedes Paket 4 Bytes. Das erste Byte enthält die Nummer des MIDI-Anschlusses (USB-MIDI unterstützt 16 MIDI-Anschlüsse pro Gerät) und ein paar Zusatzinfos zur einfacheren Auswertung. Die restlichen 3 Bytes sind der Inhalt der MIDI-Botschaft. Außer für SysEx reicht das für alle MIDI-Botschaften, da die je nach Art der Botschaft 1 bis 3 Bytes lang sind. Es wird also für jede MIDI-Botschaft ein eigenes Paket über USB verschickt. SysEx wird einfach auf mehrere 3-Byte-Häppchen aufgeteilt.
Das finde ich interessant. Wie schaffen es denn dann z.B. der Midiface
oder jegliche USB-MIDI-Geräte zeitlich synchron und latenzarm (auch mit
vielen Geräten über einen Hub) zu operieren?
USB 2.0 Full Speed (12 Mbit/s) hat 1kHz Frame clock, USB 2.0 High Speed
8kHz. Damit kann man prinzipiell 1 Byte/Frame übertragen, auch wenn das
nicht sonderlich effizient ist, wohl aber verzögerungsarm. MIDI mit
seinen 32kBaud hat 3kHz sprich 330us Bytetakt.
Die FT4232H Chips sind USB 2.0 High Speed Chips mit 480 MBit/s und 125us Frame Clock. Ich hätte also keien Probleme, das erstmal damit zu probieren, weil der Einstiegsaufwand damit relativ gering ist.
Die FT4232H Chips sind USB 2.0 High Speed Chips mit 480 MBit/s und 125us
Frame Clock. Ich hätte also keien Probleme, das erstmal damit zu
probieren, weil der Einstiegsaufwand damit relativ gering ist.
Du kannst es drehen und wenden wie du willst. Eine harte maximale
Latenz, schon fuer das blosse Durchreichen, kannst du damit nicht
garantieren. So eine USB-Loesung mit Chinaplatinchen ist in erster
Linie eben nur eins: Billig. Das war es dann mit den Vorteilen aber
auch.
Die Latenzen im Linux-Kernel sind äußerst gering, für so ein paar MIDI-Daten geht das alles unproblematisch. Ich hätte bei der USB-Lösung auch keine großen Bedenken, wie schon geschrieben, da bleibe ich dabei. Wenn User "Motopick" seine FPGA-Lösung favorisiert ist mir das recht, der TE kann ja hoffentlich selbst entscheiden.
Warum jetzt ein Raspi gut ist: den kann man programmieren, und (hardwaretechnisch) erweitern.
Außerdem gibt es gewisse Standards, Leute zum Ansprechen/Netzwerke oder "Workflows", Tutorials usw. die sind auch nett.
Von der Geschwindigkeit: der Atari ST lief auf 8 MHz
Die Unterschiede zwischen Asm, C und BASIC-Interpreter konnte man (im thematischen Zusammenhang hier) schon direkt wahrnehmen. Sicherlich war compiliertes BASIC auch nicht langsam, aber es gab auch relativ viel Hintergrundinfo für feingetunten Assemblercode.
Ja, und außerdem ist das Timing vom ST immer noch Referenz, wenn es um Midi-Setups geht - welches als solches aber auch nicht selbstverständlich ist. Der einfache 16 Spur-Sequenzer im Emax2 hat z.B. ein grottiges Timing.
edit: Wenn man schon ein Linux an Board hat, ist doch auch nicht schlimm, dann kann man Csound oder andere Scherze miteinbinden.
Fuer ein "äußerst gering" kann man sich in diesem Zusammenhang eben
nichts kaufen. Weil eben nur im statistischen Mittel "äußerst gering"
und gelegentlich :) dann doch ein "Ausreisser" dabei sein kann.
Beim RPi1 sorgte schon das etwas "ungluecklich" angebundene
Netzwerkinterface fuer solche "Aussetzer".
Und: Beziffere doch mal "äußerst gering", und den Maximalwert den
du fuer vorstellbar haeltst. Mit 16 von solchen USB-Seriell-Adaptern
angeschlossen und im Betrieb...
Bei einem Atari brauchte es solche Betrachtungen nicht.
Die ist, wenn es nur einfache Transformationen der MIDI-Daten sind,
eben praktisch latenzfrei. Und das in jeder Mondphase.
Spendiert man jedem "Transformator" dann auch noch seinen eigenen
Interpreter/Softcore, auch von den uebrigen Kanaelen unbeeinflusst.
Thema FPGA: ich muss zugeben, dass das für mich bislang ein rotes Tuch
war, da ich da wirklich so gar keine Berührungspunkte mit gesammelt
habe. Aber es ist ja auch nie zu spät. Ich habe mir die Welt der FPGAs
mal angesehen, und es hört sich durchaus interessant und lernenswert an,
nur glaube ich, dass das ein Fass ohne Boden sein könnte - gerade wenn
ich bedenke, dass ich auch noch ca. zehn andere Hobbyprojekte auf dem
Tisch liegen habe, die ähnlich behandelt werden wollen.
Vergiss FPGA. Ohne zwingenden Bedarf ist es vergeudete Lebenszeit.
Das ist tatsächlich gegenüber meinem Vorschlag ein deutlicher Vorteil.
Darüber kann man das Gesamtkonstrukt einfachst an einen PC anbinden, dazu wird keinerlei zusätzliche Hardware mehr benötigt.
Theoretisch sollte es ja auch irgendwann mal möglich sein, eine USB-NIC dranzuhängen.
Aber, so weit ich informiert bin, ist die USB-Host-Unterstützung des SDK immer noch sehr rudimentär. Aber immerhin HID scheint inzwischen ja zu funktionieren. Das war noch anders, als ich mich das letzte Mal damit beschäftigt habe.
Die Unterstützung für USB-NICs wird aber wohl daran scheitern, dass praktisch alle am Markt zunächst mal einen Blob mit ihrer Firmware brauchen, um zu funktionieren. Und dann gibt es drölfzig mögliche USB-Klassen, nach denen sie das tun könnten. Steht natürlich nirgendwo dran, ob und welche sie tatsächlich verwenden.
Zum Glück kann man immerhin schauen, was Linux so unterstützt. Wenn in Linux unterstützt, kann man immerhin alle nötigen Infos daraus zusammenklauben.
Warum jetzt ein Raspi gut ist: den kann man programmieren, und
(hardwaretechnisch) erweitern.
Dafür muss der immer erst booten und will nachher auch wieder runtergefahren werden. Das war letztendlich der Grund, warum ich das mit einem µC machen wollte: Robuster für unterwegs, ist nach Anlegen der Versorgung in <1s vollständig betriebsbereit und kann jederzeit wie die anderen Geräte auch, hart abgeschaltet werden, ohne dass das potenzielle Probleme bereiten könnte.
Warum dann nicht gleich den Teensy, den ich vorgeschlagen habe?
Was kostet der?
Der hat
schon Ethernet und USB Host und USB Device eingebaut.
Und der USB-Host funktioniert tatsächlich so, dass ich z.B. bei Amazon irgendeinen beliebigen USB-NIC-Adapter kaufen kann, denn an den Teensy anstöpsele und ich bin darüber im LAN?
Wenn das wirklich so wäre, hätte ich doch einiges verschlafen. Allerdings: ich bin mir doch ziemlich sicher, dass ich nicht so lange geschlafen habe...
Was die prinzipielle Unterstützung betrifft, hat der PiPico auch beides. Aber es ist eben ein verdammter Unterschied, ob es prinzipiell gehen könnte oder auch praktisch geht...
Das macht der aber nur einmal. Du baust bei deiner Musikanlag 100x
länger auf, als der Raspberry Pi bootet ;-)
Vielleicht bin ich ja auch altmodisch, aber ich will eigentlich nicht solche Geräte erst booten müssen. Das ist wie bei dem Fernseher, den wir auf der Messe zum Anzeigen eines Videos verwendet haben. Dann kam ein potenzieller Kunde, dem wir das Video zeigen wollten, aber beim Fernseher hat sich irgendwas verhaspelt, und es hat Minuten gedauert, bis er wieder lief, weil er erst das integrierte Andriod komplett neu booten musste.
Wenn man das richtige Linux nutzt, kann man den eiskalt ausschalten.
Stichwort overlay file system.
Wie ist das mit den SD-Karten? Kommen die damit auch problemlos klar?
Warum dann nicht gleich den Teensy, den ich vorgeschlagen habe?
Was kostet der?
Weiß nicht, was der jetzt kostet. Damals, als ich in gekauft habe, gut 30 €.
Der hat
schon Ethernet und USB Host und USB Device eingebaut.
Und der USB-Host funktioniert tatsächlich so, dass ich z.B. bei Amazon
irgendeinen beliebigen USB-NIC-Adapter kaufen kann, denn an den Teensy
anstöpsele und ich bin darüber im LAN?
Wozu brauchst du den denn? Er hat wie gesagt schon Ethernet eingebaut. Wenn du also nicht gerade zwei Ethernet-Ports brauchst, benötigst du auch keinen USB-NIC.
USB-MIDI-Geräte funktionieren ohne Probleme, auch mehrere gleichzeitig über einen Hub. Und auch als USB-Device am PC lässt er sich leicht als USB-MIDI-Gerät konfigurieren. Hab ich aber alles oben schon mal geschrieben.
Was die prinzipielle Unterstützung betrifft, hat der PiPico auch
beides. Aber es ist eben ein verdammter Unterschied, ob es prinzipiell
gehen könnte oder auch praktisch geht...
Eben, und beim Teensy hab ich es ausprobiert, und es funktionierte wunderbar.
Das macht der aber nur einmal. Du baust bei deiner Musikanlag 100x
länger auf, als der Raspberry Pi bootet ;-)
Vielleicht bin ich ja auch altmodisch, aber ich will eigentlich nicht
solche Geräte erst booten müssen.
Jain. Optimal isses nicht, aber in vielen Fällen wie auch hier sind die 10-60s egal.
Wenn man das richtige Linux nutzt, kann man den eiskalt ausschalten.
Stichwort overlay file system.
Wie ist das mit den SD-Karten? Kommen die damit auch problemlos klar?
Das ist ja der Trick. Die werden dann read only betrieben. Funktioniert in Millionen Digitalkameras etc. OK, die fahren meist definiert per Knopfdruck runter. Hmmm.
Wie ist das mit den SD-Karten? Kommen die damit auch problemlos klar?
Das ist ja der Trick. Die werden dann read only betrieben. Funktioniert
in Millionen Digitalkameras etc. OK, die fahren meist definiert per
Knopfdruck runter. Hmmm.
Kollege Stefanus (wo ist der eigentlich, lange nichts mehr gehört) berichtete mal, dass ausgerechnet die „originalen“ SD Karten von der Raspberry Foundation mit vorinstalliertem OS keine Probleme mit abrupten Abschalten haben. Fatal sind hingegen Karten z.B. von Intenso. Ebenfalls sehr gut funktioniert ein CM4 Modul mit EMMC.
Kollege Stefanus (wo ist der eigentlich, lange nichts mehr gehört)
Der hat sich wohl, wie viele andere auch, ausgeklinkt. Sein Account wurde gelöscht oder stillgelegt, erkennbar an seinen Beiträgen, die nur noch als Gast dargestellt werden.
Ich habe einen Teensy 4.1 dafür vorgesehen. Der ist zwar von Rechenpower
und Speicher her auch deutlich überdimensioniert, hat aber immerhin
schon 8 UARTs eingebaut. Außerdem hat er noch USB host und device, und
zwar beides gleichzeitig (MIDI-over-USB gibt's für beides schon fertig
als Bibliothek, am Host-Port kann man sogar per Hub mehrere Devices
gleichzeitig nutzen). Man kann das ganze darüber also auch gleich noch
mit dem PC verbinden und mit irgendwelchen Gerätschaften, die kein
echtes MIDI haben. Ethernet hat er auch noch.
Das hat 16 Kanäle mit Dreh-Encodiereren und programmierbare MIDI-Funktionen.
Am liebsten wäre mir eine Platine mit nur den Encodierern und einem Prozessor, was man zu einem richtigen Pult ausbauen kann.
Vermutlich gibt es fuer USB-MIDI-Controller eine andere Spezikation
im USB-Standard.
Die ist völlig anders. Das MIDI ist sozusagen im USB-Protokoll eingelassen, also gewissermaßen virtuelles MIDI. Ein großes Problem ist, dass es keine Vorschriften für das timing gibt. Jeder sendet wie er will und so schnell er will, bzw. so schnell er kann. Damit ist beim Empfänger das timing erst eimal verloren. Keine Echtzeit mehr und unkontrolliertes Eintreffen der Daten.
Als erste Konsequenz senden viele Hersteller eigene timings virtuell mit und stellen sie im PC in ihrem eigenen Treiber wieder her. Manche bekommen auf diese Weise eine Art MTC hin. Angeblich wenigsten! Nutzt du aber ein konventionelles MIDI-Keyboard oder Endgerät ohne MTC, dann ist es Lotterie, wie schnell das Endgerät reagiert.
Als weitere Konsequenz braucht es Puffer, um die Daten abzufangen und sicherzustellen, dass man das timing überhaupt einhalten kann und kontinuierlich arbeitet, wenn man kein MTC benutzen kann.
Dies wiederum hat zur Konsequenz, dass es einen Haufen Latenz gibt und der Ton mehrere Hundertsel nach dem Drücken der Taste ertönt. Im PC oft Zehntel!!!
Alles zusammen hat die Konsequenz, dass viele Hersteller mit ihren Tricksereien das MIDI-Protokoll aufblasen und kein Standard-USB-MIDI mehr fahren, weshalb es immer einen Spezialtreiber braucht. Den gibt es meistens nur für Windows. Wir MAC-Nutzer und Anwender von Linux sitzen da auf dem Trockenen!
Die Lösung wäre ein schneller Microcontroller mit USB und echte MIDIs dran und zwar in die eine und in die anderen Richtung. Also auch USB-Gerät in normales MIDI gewandelt. Wahrscheinlich braucht es dafür einen Controller pro Gerät. Der Beschiss ist nämlich, dass die meisten Geräte heute gar keinen echten MIDI mehr haben. Nur noch billig USB.
Komisch, ich spiele Keyboard entweder über USB direkt in den Linux PC oder über Midi mit einem selbst programmierten Midi zu USB Controller (Itsy Bitsy 32u4 5V)und habe nirgends Probleme mit Latenz (und wenn ich noch so schnell spiele ;-)
*die hier hatten vor allem einen einfachen kleinen Casio-Sampler eingesetzt, und sind recht kreativ damit umgegangen -> sehr hörenswertes Album!
https://www.youtube.com/watch?v=l3KqGZM8S7g
Ich habe nicht gezielt nachgeschaut, aber so weit ich die im Hinterkopf
habe, müssten mit einigen der Chips sogar mehr als 16 UART möglich sein.
Mit dem, den wir einsetzen sind insgesamt 10 drin, einige aber als I2C.
Die Art des Controllers ist aber eigentlich nebensächlich, denn es behebt aber nicht das Problem, dass sich der TE einiges an SW schreiben muss, um sein routing hin zu bekommen.
Wo wir die Hardwarefrage ja eigentlich jetzt allumfassend geklärt haben ;-) , würde mich interessieren, wie Du Dir das Webinterface vorstellst.
Hast Du Dir da schon Gedanken drüber gemacht?
Einige Anforderungen hast Du ja schon erwähnt :
"
Okay, da habe ich mich wohl missverständlich ausgedrückt - sorry! Die
Verbindungen sollen nicht nur durchgeschaltet, sondern auch
softwareseitig gefiltert und modifiziert werden können. Beispiel: "Leite
MIDI Input #2 nach MIDI Ouptut #4, aber nur Oktave 1 bis 2, und
transponiere die Noten eine Oktave nach oben".
"
Ich denke, es würde Sinn machen, das mal alles nieder zu schreiben und zu zeichnen, da kommen bestimmt noch viele Impulse, die eventuell auch bis in das Hardware-layout hinein reichen.
Möglichst von "dringend erforderlich" bis "wär ja ganz nett" bewertet.
Ich finde Dein Projekt sehr spannend und habe jetzt so beim mitlesen irgendwie eine Hardware zwischen mehreren rp2040 (aus meiner Sicht einfach) und einer FPGA Lösung (aus meiner Sicht die totale Herausforderung) vor Augen.
Frage an die FPGA-Fraktion : Wie würde sich die Einbindung des Web-Interfaces technisch gestalten?
Viel Erfolg und ein trollarmes Projekt wünsche ich Dir.
Frage an die FPGA-Fraktion : Wie würde sich die Einbindung des
Web-Interfaces technisch gestalten?
Oder welches Synthese-Verfahren, oder wie den Arbeitsspeicher organisieren. Besser wäre es natürlich, fertige Setups einzusetzen. Das Webinterface wird auf dem normalen Wege eingebunden, wie bei den anderen Möglichkeiten auch.
Aber man kann sich tatsächlich ein paar Gedanken über die Bedienung machen. Was möchte man genau einstellen, und wie will man das machen? -> wird man aufschreiben müssen. Je nach Empfängerhardware gibt es mal mehr, mal weniger Steuermöglichkeiten über Midi. Beim Korg DW 8000 kann man alles mögliche über Midi ansteuern. So gesehen könnte man auch einen universalen Editor überlegen. Was natürlich in Programmen wie Cubase schon länger und auch ökonomisiert (also über die Jahre verbessert) eingebunden ist.
Letztlich hat man auch eine Frage des Handlings - für welche Art von Songs brauche ich wieviel Midi-Steuerung? - wo der Link oben zur Sequenzer-Seite schon sehr hilfreich ist.
Außerdem waren so Steuerfragen bei der Analogseite wesentlich einfacher und übersichtlicher:
KRAFTWERK : Wir Sind die Roboter (1978)
https://www.youtube.com/watch?v=JgtFRj38fEw
Sowas würde man auch gerne mal mit Pulsweitenmodulation, oder Ringmodulation, Vibrato, LFO usw. ausprobieren - nur um mal klarzumachen, wo die Reise mit Midi hingehen könnte.
Teilweise kann man dies und das über die Anschlagstärke managen - aber wie gesagt, kommt halt drauf an - und man macht sich besser erstmal ein paar Pläne mit Bleistift hinsichtlich dessen, was man haben will, was tatsächlich realisierbar was ist und was gut zu passen scheint.
Wo wir die Hardwarefrage ja eigentlich jetzt allumfassend geklärt haben
;-) , würde mich interessieren, wie Du Dir das Webinterface vorstellst.
Hast Du Dir da schon Gedanken drüber gemacht?
Sind wir nun beim Webinterface?
Wofür? für MIDI?
Das macht doch der Computer direkt - über eben MIDI! Mit jedem MIDI-Editor und jedem Audioprogramm lässt sich das machen.
Oder anders gesagt: Nach meiner Verstellung muss der Prozessor (oder der FPGA), der das MIDI umlenken und verwalten soll (und daher einen MIDI-Eingang haben muss!!!!) auch selber mit MIDI konfigurierbar sein.
Das finde ich interessant. Wie schaffen es denn dann z.B. der Midiface
oder jegliche USB-MIDI-Geräte zeitlich synchron und latenzarm (auch mit
vielen Geräten über einen Hub) zu operieren?
Indem sie in ihren Spezifikationen das Wort "latenzarm" hineinschreiben und den User erklären, was "geringe Latenz" in Zahlen zu bedeuten hat.
Wer aber mit USB arbeitet und etwas von Paketen versteht, der weiß dass da sehr schnell unnötige Verzögerungen entstehen und infolge von Buskollisionen keine Gleichzeitigkeit existiert. Je nach verwendetem Teilnehmer und dessen Sendefreudigkeit kommt da einiges an Verzögerung und vor allem Jitter zustande.
Frage an die FPGA-Fraktion : Wie würde sich die Einbindung des
Web-Interfaces technisch gestalten?
Oder welches Synthese-Verfahren, oder wie den Arbeitsspeicher
organisieren.
Wenn hier mit einem Interface per Internet zugriffen werden soll, dann ist da eine Menge Arbeit nötig. Die Richtung ginge dann auf einen Zynq unter Nutzung des ARMs für den Internetteil.
16 "normale" UARTs kann man da durchaus fahren. Habe ich vor 20 Jahren mal mit einem "COMTROL DEVICEMASTER 16" gemacht, zusammen mit der WXWIDGETS Library. Da muss aber auch noch einiges programmiert werden. Immerhin hat man die UARTs direkt virtuell in der WINAPI greifbar.
Wenn man mit Synthedit einen VST-Treiber für UART-Interfaces so umbiegt, dass er MIDI macht, könnte man so direkt MIDI aus der DAW ins Netz schicken, 100km weiter mit dem Gerät dekodieren und hätte dann vorort eben 16 UARTs mit RX und TX. Es ginge auch RS422 und RS485, kann man an dem Ding einstellen.
Man wird aber die darin inbegriffene ECOS und ARM5 Software anfassen müssen, um von den 9600 x X UART Zahlen auf die 31k25 beim MIDI zu kommen.
Aus meiner Sicht ist das alles overkill.
Bei mir macht ein S/PDIF-MIDI 16x4 virtuelle Kanäle und wird physikalisch auf 4 echte Leitungen mit 16er MIDI gemapped. Sind genau 50.000 MIDI-Bytes/Sek. und zusammen mit anderem Gedöhns Clock und Synch weniger als 10% Auslastung des S/PDIF Signals. Latenz 2-3 Ccs des 48kHz. Einstellung geht per normaler UART über eine einfache GUI.
Das stimmt zwar, zeigt aber gleichzeitig auch auf, dass das OT Bullshit ist.
Wie fast alles, was meint, unbedingt ein "Webinterface" zu brauchen. Das sind doch (zumindest in erster Näherung) nur Gimmiks.
Vlt. will er sich das genau deshalb bauen, weil
die Standardkomponenten das anders machen, so wie Du beschreibst.
Wäre denkbar und möglicherweise sogar auch nützlich. Aber ändert nichts daran, dass diese Web-Scheiße allenfalls sekundären Charakter hat. Erstmal geht es um die eigentliche Funktion. GUI (insbesondere ein maßlos aufgeblähtes Web-GUI) ist Eye-Candy, mehr nicht.
Kein Mensch braucht ein Web-GUI, nur wenige wollen wirklich ein Web-GUI. die meisten wollen einfach nur ein GUI. Das kann man ohne aufgeblähtes und hochunsicheres Web-Gedöhns viel einfacher und billiger haben.
Kein Mensch braucht ein Web-GUI, nur wenige wollen wirklich ein Web-GUI.
die meisten wollen einfach nur ein GUI. Das kann man ohne aufgeblähtes
und hochunsicheres Web-Gedöhns viel einfacher und billiger haben.
Das genaue Gegenteil ist richtig.
Kein Mensch will proprietäre Apps/GUIs, die nur auf einem Devicetype funktionieren.
Hm, verstehe die Zitierung nicht so ganz. Möchtest Du mir mitteilen, was Jonas zu brauchen hat und warum seine Projektidee nicht gut ist? Also ich bin da raus. Ursprünglich suchte er Ideen für „sein“ Projekt, die hat er reichlich bekommen. Nun ist es sein Ding, was er davon macht oder auch nicht.
Hochkompetent vorgebrachtes, überaus sachhaltigen Argument. Davor kann
man wohl nur kapitulieren.
Da eine wie auch immer gestaltete und realisierte GUI absolut überhaupt nichts mit Security und Privacy zu tun hat, gibt es da auch nichts zu diskutieren.
Den kenne ich, ist ein tolles Gerät - lediglich die Software dafür ist nicht so super gelöst imo. Ich verstehe nicht, warum diese wie eine eher unübersichtliche Excel-Tabelle aufgebaut ist. Das ginge mMn schöner - und ich glaube, dass dort auch keine Modifier, wie z.B. "Transpose" möglich sind. Und, was mich eben stört, ich brauche eine USB-Verbindung. Wo wir beim nächsten Thema wären:
Aber ändert nichts
daran, dass diese Web-Scheiße allenfalls sekundären Charakter hat.
Erstmal geht es um die eigentliche Funktion. GUI (insbesondere ein
maßlos aufgeblähtes Web-GUI) ist Eye-Candy, mehr nicht.
Kein Mensch braucht ein Web-GUI, nur wenige wollen wirklich ein Web-GUI.
die meisten wollen einfach nur ein GUI. Das kann man ohne aufgeblähtes
und hochunsicheres Web-Gedöhns viel einfacher und billiger haben.
Kann man, dann könnte ich auch gleich eine Schaltermatrix oder ein kleines 16x2 LCD nutzen, wie mein Vater und dessen Vater es schon genutzt hat. Ist halt nur fummelig und nicht alles, was alt ist, könnte man nicht auch mal modernisieren. Daher die Inpsiration für mein Projekt. Letzten Endes wird sich zeigen, wie nützlich das ist.
Niemand hat behauptet, dass die GUI primären Charakter hat oder haben sollte. Ich frage mich allerdings, inwiefern Sicherheit hier überhaupt von Relevanz ist. Das Gerät öffnet einen WiFi-AP oder verbindet sich mit meinem lokalen Netz (auf der Bühne habe ich dafür einen Router im Rack). Dieser ist mittels WPA2 geschützt, was gibt es da noch für Bedenken? Und: wenn es so unsicher ist, warum nutzen selbst grandMA-Lichtpulte oder die großen Tonpulte WiFi? Weil es doch eben sehr angenehm ist, mit dem iPad in der Venue rumlaufen zu können, um seine PA oder sein Licht einzustellen. Ich muss mein MIDI zwar nicht oft ändern, aber wenn ich es will, dann nicht über irgendwelche fummeligen Windows-Anwendungen, die dann schon wieder nicht mehr laufen, wenn der, der es benutzen will, einen Mac hat. Was spricht denn gegen Plattformunabhängigkeit und voralldem gegen den Vorteil, nicht erstmal irgendwelche Treiber und Softwarepakete installieren zu müssen, um einfach nur eine simple Konfiguration vorzunehmen? Das ist genau das, was mich an den existierenden Geräten nervt. Und ein Web-Interface muss auch nicht aufgebläht sein, nur weils ein Web-Interface ist. Spar die jQuery, besondere Fonts und Grafiken und die Webanwendung ist kleiner als die meisten Softwares (die im Übrigen auch nur eingepackte headless browser sind - dann kann ich auch gleich im Browser drauf zugreifen).
Doch. Alle Leute, den privacy und security wichtig sind, nehmen die
daraus erwachsenden Nachteile in Kauf.
Ganz bewußt. In rationaler Abwägung der Vor- und Nachteile.
Ich finde das dennoch interessant, deshalb würde ich gerne hören, inwiefern ein Web-Interface, dass lokal AUF dem zu bauenden Gerät läuft und auch keine Anbindung nach "außen" braucht (und über einen WiFi-AP auch gar nicht hat), Sicherheitsbedenken mit sich bringt, die sich nicht über IP-Whitelists und Verschlüsselung lösen lassen? Es geht hier um einen MIDI-Router - da dürfte so ziemlich nichts irgendwie privatsphärerelevant sein.
So ein 16 Port Multi-UART auf einem FPGA, haette den Vorteil,
dass die Routingsoftware die MIDI-Daten gepuffert und ohne eigenen
Aufwand "hineingeschoben" bekommt
So ein 16 Port Multi-UART auf einem FPGA, haette den Vorteil,
dass die Routingsoftware die MIDI-Daten gepuffert und ohne eigenen
Aufwand "hineingeschoben" bekommt
Zu welchem Preis ?
Jemand hatte hier vor kurzer Zeit, nach einem niedrigpreisigem
"Einsteigerboard" gefragt. Dem hatte ich dann ein Cyclone2 Board
aus China empfohlen. Das so etwas ohne jede Problem stemmen kann.
Mancher mag sich an der aelteren Quartus Version stoeren.
Das bleibt dann ihm ueberlassen.
Das Board nebst Altera JTAG-Adapter lag bei ca. 40 Eu.
Wenn er dann noch KI darauf laufen lassen will, gibt es von Terasic
ein "Early-Adaptor-Board" mit einem Agilex drauf. Der fruehe Fokel
bekommt fuer sein "Early" einen FPGA mit knapp 0.7 Mio LEs.
Ist aber auch 2 k$ plus Shipment und Customs los. :)
Aber 0.7 Mio LE sind schon eine Menge. Und HW-ARMe sind natuerlich
auch mit dabei.
Keine Ahnung. Ich habe grundsaetzlich nicht vor, mit Lattice-Produkten
ueberhaupt etwas anzustellen. "Never ever ISPLever" you know?
Wir wissen schon, dass 3 RP2040 es schaffen.
Naja, ein alter Single-Cycle 8752 von Signetics schafft bei 33 MHz
auch eine Menge. Das man nun schon 3 von den RP2040 braucht...
laesst die zeitliche Entwicklung doch etwas blas aussehen.
Der 8752 wuerde natuerlich auch gerne einige UARTs per Memorymapping
haben. Der RP2040 ist da also nicht so viel besser.
So grundsaetzlich wird hier ja schon da 5. Rad am Wagen diskutiert.
Web-GUI
Der TO sollte sich lieber mal einen kleinen Prototypen bauen, mit
einem MIDI-Eingang und 2 MIDI-Ausgaengen. Dann ka die dafuer noetigen
Funktionen schreiben und ausgiebig testen. Ausserdem haette er dann
schon etwas fuer ihn unmittelbar nuetzliches.
Weiter koennte er z.B. feststellen, ob er damit nur "vorverdrahtete"
Operaroen bedienen will, oder nicht doch etwas eher frei
programmierbares. Forth hatte ich ja schon angeregt.
Besonders lustig stelle ich mir auf der Buehe das "Gefummel" an einem
Tablett nicht gerade vor.
Und lasst euch blos nicht von dem Privacy&Security-Schwaetzer
irgendwelchen Bullshit erzaehlen...
Hmmmm, wo kommt das denn her?
Neun MIDI Inputs und mindestens 13 Outputs sind selbst ohne Verrenkungen im Bereich des Frontallappens zu erreichen. Pro Chip!
Hmmmm, wo kommt das denn her?
Neun MIDI Inputs und mindestens 13 Outputs sind selbst ohne Verrenkungen
im Bereich des Frontallappens zu erreichen. Pro Chip!
Du hast falsch zitiert! Das ist nicht meine Behauptung.
Inwieweit diese neun Inputs und die mindestens 13 Outputs einfach
handhabar sind, schreibst du aber nicht.
Ich wuerde zumindest behaupten, dass der Zugriff auf memory-mapped IO
auf einem 8752 sehr einfach, und uniform ueber alls Inputs/Outputs ist.
Frontallappens
Etwas lobotomisiert kommt mir der RP2040 schon vor. :)
Gluecklicherweise muss man ihn ja nicht benutzen.
Naja, ein alter Single-Cycle 8752 von Signetics schafft bei 33 MHz
auch eine Menge. Das man nun schon 3 von den RP2040 braucht...
laesst die zeitliche Entwicklung doch etwas blas aussehen.
Der 8752 wuerde natuerlich auch gerne einige UARTs per Memorymapping
haben. Der RP2040 ist da also nicht so viel besser.
Da nicht klar erkennbar war, ob die Aussage von dir kam oder du dich auf etwas Früheres beziehst, schrieb ich:
Hmmmm, wo kommt das denn her?
Du hast falsch zitiert! Das ist nicht meine Behauptung.
NEIN, das habe ich NICHT.
DU hast diesen Satz in deinem Text geschrieben. HÄTTEST du ihn zitiert, dann würde ich mir den Schuh anziehen. So aber nicht.
Es gibt einen großen Unterschied zwischen ›Recht haben wollen‹ und ›Recht haben‹.
Oder anders gesagt: Nach meiner Verstellung muss der Prozessor (oder der
FPGA), der das MIDI umlenken und verwalten soll (und daher einen
MIDI-Eingang haben muss!!!!) auch selber mit MIDI konfigurierbar sein.
Nennt sich SYSEX-Level.
Gute Idee, neben der WebGui kann das Gerät immer noch zusätzlich über MIDI selbst gesteuert werden.
Der TO sollte sich lieber mal einen kleinen Prototypen bauen, mit
einem MIDI-Eingang und 2 MIDI-Ausgaengen. Dann ka die dafuer noetigen
Funktionen schreiben und ausgiebig testen. Ausserdem haette er dann
schon etwas fuer ihn unmittelbar nuetzliches.
Weiter koennte er z.B. feststellen, ob er damit nur "vorverdrahtete"
Operaroen bedienen will, oder nicht doch etwas eher frei
programmierbares.
Ich bin zwar nicht der TO, aber das Thema hat auch mich persönlich immer wieder gereizt :-)
Zumal Theorie und Praxis (selber machen als Hobby) eben doch verschieden sind.
Also schnappte ich mir den Pi Pico W und 3 Adafruit MIDI FeatherWing Kits, die zufällig noch in meiner Bastelkiste lagen, und begann zu basteln.
Vor allem, wenn es nicht nur um Routingaufgaben und "leichte" Änderungen wie Transponieren oder Kanalmanipulation geht.
Sondern Midi-Merge und dabei so Feinheiten wie Running Status beachten werden muss.
Aber wer sagt schon was von einfach ;-) ;-)
Und, was mich eben stört, ich brauche eine USB-Verbindung.
Das wird ggf. für mich etwas schwieriger, eigentlich sollte der rp2040 das können. Er kann ja als verschiedene USB-Geräte fungieren, als Demo im Repository ja verfügbar. Bis hin zur Soundkarte. Beißt sich nur mit meiner Wahl der Entwicklungsumgebung. Aber das kommt ganz zum Schluss.
Die beiden UARTs laufen schon mal, jetzt versuche ich mich am dritten Midi-Port via PIO.
@Jonathan: Viel Erfolg und ich bin gespannt auf deine Wahl. Mir hat mein "Demo"-Versuch schon viel gebracht.
..., kommt halt drauf an - und man macht sich besser erstmal ein
paar Pläne mit Bleistift hinsichtlich dessen, was man haben will, was
tatsächlich realisierbar was ist und was gut zu passen scheint.
Ja, wie man am besten mit der "Routingtabelle" und den "Modifikationswünschen" umgeht, da fehlen mir auch noch ein paar Ideen,
das muss ja immer zur Laufzeit geprüft und abgearbeitet werden.
Vielleicht wie eine Firewall mit den Regelsätzen? … Ideen sind willkommen.
ALLE, wirklich ALLE Midi-Geräte arbeiten selber auch mit MIDI, um sie zu
steuern.
Wie sieht das dann in der Praxis aus? Also ganz konkret: was mache ich mit welchem Gerät, wenn ich bei meinen eigenen Midi-Mux Eingang 3 auf Ausgang 7 schalten will?
Wie sieht das dann in der Praxis aus? Also ganz konkret: was mache ich
mit welchem Gerät, wenn ich bei meinen eigenen Midi-Mux Eingang 3 auf
Ausgang 7 schalten will?
Man schickt der "Kiste" einen Sysex in dem genau das drinsteht.
Kwasi auf deren "MIDI-Console". Die "Kiste" hat also einen MIDI-IN/OUT
mehr, als es zu routen gibt.
Man schickt der "Kiste" einen Sysex in dem genau das drinsteht
Und den Tippe ich dann manuell mit einer Tsstatur ein? Also wie sieht
Bedienoberfläche aus?
Die Sysex kann zum einen eine zum Synthie gehoerende Software aka
GUI an das Geraet schicken, oder ein Sequenzer.
Mitunter hat man nur eine Tabelle mit den Sysex-Sequenzen.
Fuer die haelt zumindest der Sequenzer dann eine Eingabemoeglichkeit
bereit, die an einen Hexeditor erinnert. :)
Man schickt der "Kiste" einen Sysex in dem genau das drinsteht.
Kwasi auf deren "MIDI-Console". Die "Kiste" hat also einen MIDI-IN/OUT
mehr, als es zu routen gibt.
Nicht mal das, die meisten empfangen sysex auf allen MIDI-IN Kanälen.
Das Problem ist eher, eine Kiste zu finden, die noch SYSEX einfach sendet, wenn man keinen PC zur Hand hat.
inwiefern Sicherheit hier überhaupt
von Relevanz ist.
Ich hätte da auch kaum Sicherheitsbedenken, es sei denn, jemand möchte das MIDI in Echtzeit klauen! :D
Es geht wohl mehr um den Zugriff als solchen. Ich persönlich sehe es einfach nur als zweckmäßig an, den gesamten Aufbau eines Setup per recall zu etablieren und da haben wir mit MIDI bereits alles, was wir brauchen. Alle Synths, alle Expander, alle Keyboards und Effektgeräte und nicht zuletzt die Mischpulte hören auf MIDI. Damit ist es für mich als producer völlig logisch, all das in die DAW zu packen.
Und kurzerhand wird stringent denkend damit auch das Setup für den MIDI-Router dort untergebracht, weil das routing ja zum Musikstück und zur Darbietung, also dem Instrumentensetup und deren Einstellungen passen muss. Rein praktisch habe ich einfach nicht den Fall, dass ich nur am MIDI Routing intuitiv und adhoc die Einstellungen ändere und damit das Gemüse woanders hinschicke, ohne auch die Instrumente und deren Einstellungen zu ändern.
Ich betrachte das sozusagen vom use case her und da fällt der hiesige technische Realisationsansatz, den Anforderungen zu Opfer :-)
Natürlich ist eine Einstellung per Tele immer interessant und das über Ethernet zu machen, hat seinen Reiz, wenngleich das Bandbreiten-overkill ist. Dann würde ich auch eher das Antriggern des Schaltens in einen Raspi verlagern und den per remote anfunken. Oder man macht es in Hardware mit einem MIDI-over-Ethernet von ESI. Die wandeln das selber. Da braucht es nur einen MIDI-Client oben als funtionellen Master.
Ich gebe aber zu Bedenken, dass sich der Aufwand, das alles zu implementieren nicht lohnt, um am Ende 16 Kanäle zu verbuddeln. Da müsste dann schon mehr bei rauskommen, finde ich. Wie gesagt, nudelt meiner mit 256 Kanälen. Für diese mehrkanaligen Sachen gleicher HW-Struktur ist ein FPGA wie gemacht. Und zwar nicht, wegen "parallel" und x-mal reinkopieren, sondern wegen Tempo und pipeline loop.
Wenn ich das planen müsste, dann würde ich meinen MIDI-Router in einen ZynQ setzen und den ARM den ETH-Stack besaften lassen. Das gleiche gilt fürs USB. USB MIDI als C gibt es frei und das Protokoll kriegt man schnell selber implementiert, wie man es haben will.
Alle Synths, alle Expander, alle Keyboards und Effektgeräte
und nicht zuletzt die Mischpulte hören auf MIDI. Damit ist es für mich
als producer völlig logisch, all das in die DAW zu packen.
Das war früher eigentlich auch nicht anders. Beim Analogsequenzer musste man aber auch schauen wie man die gefälligen Modulationen miteinbezieht.
Ein MIDI-Vollzugriff ist nicht selbstverständlich da müsste man zumindest auch schauen welche Modulationsmöglichkeiten über MIDI überhaupt da sind. Wünschenswert ist natürlich alles mögliche, aber bei einigen kann man auch nur den Kanal einstellen.
Vom Management her kann noch ein Masterkeyboard sehr nützlich sein, wie auch ein Controller, welcher möglich auch noch sehr musikfreundlich ist.
Vom Management her kann noch ein Masterkeyboard sehr nützlich sein, wie
auch ein Controller,
Die können aber auch nicht mehr, als das Gerät an MIDI versteht und die stecken ja auch ganz sicher in jedem Setup.
Hier geht es aber doch eigentlich darum, die Schalterei, also faktisch die Verkabelung zu ändern. Und diesen Schalter kann man sehr leicht mit allen MIDI-Funktionen ausstatten, wenn man ihn selber baut.
Ohne jetzt Werbung zu machen, habe ich bei mir z.B. auch das Layering drin, d.h. ich kann die einlaufenden MIDI-Ströme in mehrere Layer splitten (und zwar mit Überlagerung (*) siehe unten) und sie dann an Sequenzer, Echos, interne und externe MIDI-Verbraucher schicken und somit auch loopen. Praktisch alles, was mit einem Audiopult geht, auch auf MIDI-Daten machen. Inzwischen gibt es auch Lautstärkeeinstellungen, Expander, Gates und Kompressoren auf den MIDI-Lautstärken, sowie Stereosplitter etc...
Das sind Sachen die man sich im Laufe der Jahre binnen einer Stunde reinprogrammiert hat, weil sie den kommerziellen Geräten fehlen oder in der Kombi nicht erhältlich sind. Am Ende ersetzt eine solche Micki-Einheit einen halben Gerätepark.
(*) Unter Überlagerung verstehe ich autarke Ausgänge, die auf einen Bereich der Tastatur höhren, unabhängig von den anderen. Damit kann ich z.B. 3 Keyboards definieren von denen das 1. die linke Hand nimmt bis z.B. C3, das 3. die rechte ab C3 und die 2. beide schnappt von z.C. C1 ... C4.
Man kann zB. auch programmieren dass C1 ... C2 auf einen Ausgang geht, der um 1 Oktave nach oben geschiftet ist, wodurch es für die linke Hand egal ist ob sie eine Oktave triefer greift. Dann spielt sie aber nur alleine, während in der Mitte gegriffen dieselben Töne kommen, aber eben auch auf der oberen Tastatur. Macht man das mit der oberen genau so, kann man mit einer 61er Tastatur insgesamt 5 KB-Griffsituationen steuern und nicht nur 2 mit einem harten split irgendwo in der Mitte.
Eine von vielen Funktionen die es so nur in meinem MIDI-Verteiler gibt.
Wollte man das nachstellen, braucht man jeweils Klangerzeuger parallel, deren MIDI-Input man passend einschränkt. Und es braucht 3 verschiedene, 2 davon jeweils doppelt, weil es kein Gerät gibt, das intern splittet und auch mergen kann.
EIN MIDI-Interface an einem z.B. Arduino zu verwenden, ist trivial. Aber
was ist mit 16? So viele UART-Interfaces hat selbst ein STM32 nicht zur
Verfügung.
Der Trend geht wieder zu analog und direkter Verkabelung, sowohl bei den elektronischen Musikerzeugern selbst, als auch bei deren Verbindung mit dem PC und der nötigen MIDI-Verteilung.
Es wird wieder geplugged. Old Style is IN. Wenn man das zweite Angebot in der Bucht sucht, findet man unten noch einen elegant gemachten Print bezüglich der features: Alles schön hübsch mit einem alten Mono-Analogmonitor in grün wie in den 1990ern.
in der Bucht sucht, findet man unten noch einen elegant gemachten Print
bezüglich der features: Alles schön hübsch mit einem alten
Mono-Analogmonitor in grün wie in den 1990ern.
Wird es eine Wiederauferstehung der Schellackplatte geben? Mit romantischem Knistern.
Allerdings gab es damals Unmengen an Nachbauten, die gerade im privaten Umfeld verbreiteter waren als die Originale. Und dafür kaufte man dann ganz bestimmt keinen Originalmonitor von Apple ("gebrandeter" Sanyo). Und auch ein Original-Apple wurden häufig mit einem Fremdmonitor betrieben, insbesondere in Verbindung mit der Farbgrafikkarte (eigentlich eher nur Buntgrafik).
Ich fragte nur welcher apple grün konnte serienmäßig, mit extra
Grünmonitor gilt nicht, das kann fast jeder.
Wieso nicht? Die Originalteile waren doch extra teuer, und nicht unbedingt notwendig.
Andere wie Vince Clark schwören noch auf CV/Gate. Kann durchaus Vorteile haben, wenn man nicht für jedes analoge Teil eine Extrawurst MIDI zusammenbasteln muss.
Beim Minimoog ist das so eine Sache, da man den doch ganz gut mehrkanalig ansteuern kann, und eventuell noch mit Gimmicks aufpeppen (PWM, Ringmodulator, LFO o.ä).
Die Minimoog-Filter-Input-Sessions kann man zwar nicht so gut kontrollieren, aber das macht ja irgendwie auch den Reiz des kleinen Fettsacks aus.
Ich fragte nur welcher apple grün konnte serienmäßig, mit extra
Grünmonitor gilt nicht, das kann fast jeder.
Wieso nicht? Die Originalteile waren doch extra teuer, und nicht
unbedingt notwendig.
OK waren aber extra Monitore, ich dachte eher an das fest verbaute CBM grün, witzig dabei die aus USA importierten PET2001 1977 hatten weiße Leuchtschicht, sah bei Schach besser aus
OK waren aber extra Monitore, ich dachte eher an das fest verbaute CBM
grün, witzig dabei die aus USA importierten PET2001 1977 hatten weiße
Leuchtschicht, sah bei Schach besser aus
Damals(tm) in unserer Schule hatten wir PET 2001 mit weißem Phosphor, CBM 3016 und 3032 mit grünem Phosphor und auch einen CBM 8032, an dessen Farbe ich mich nicht mehr erinnere.
Mein eigener Sharp MZ-80K hatte weißen Phorphor mit einer bläulichen Filterscheibe. Später kaufte ich mir einen gebrauchten Siemens R10VH mit einem umgelabelten Tandberg-Terminal; auf Grund eines kleinen Kratzers auf dem Bildschirm konnte ich sehen, dass dessen orange nicht echt war, sondern durch eine Lackschicht auf einem Monitor mit weißem Phosphor erzeugt wurde.
CV/Gate. Kann durchaus Vorteile
haben, wenn man nicht für jedes analoge Teil eine Extrawurst MIDI
zusammenbasteln muss.
Auch das ist wieder im Kommen. Das Problem ist nur, dass die meisten Sequenzer, die es steuern, digitale Geräte sind und auf langsames MIDI ausgelegt sind. Das gleiche gilt auch für viele Synths, die es empfangen und oft nichts genaueres erwarten.
Wenn man da drum herum will, muss man voll analog arbeiten und die digitale Steuerung entsprechend bauen, z.B. mit diesen Pulsegeneratoren:
Das Problem ist nur, dass die meisten
Sequenzer, die es steuern, digitale Geräte sind und auf langsames MIDI
ausgelegt sind. Das gleiche gilt auch für viele Synths, die es empfangen
und oft nichts genaueres erwarten.
Kennst du zufällig Joystick-Movement-Sequenzer? Mit Joysticks kann man z.B, Oktav-Überblendungen machen - aber sequenzieren ging da eher gar nicht.
Man kann diesbezüglich aber auch spieltechnisch ein wenig tricksen, d.h. müsste man diesen Weg auch mit dem Sequenzer gehen.
(Chris Hülsbeck (https://www.youtube.com/watch?v=UJ4xNoJzn-0) hatte früher einfache Akkorde über schnelle Wechsel realisiert.)
Das haben wir alle so gemacht :-)
Im Prinzip sind es schnelle Triolen, die idealerweise im Rhythmus sind und 3-4 Akkordtöne abdecken. Klassische Klavierspieltechnik, nur meist schneller.
Aber was ist mit 16? So viele UART-Interfaces hat selbst ein STM32
nicht zur Verfügung.
Man kann UARTs auch in Software nachbilden, sogar ziemlich viele davon,
wenn man es geschickt angeht und genügend GPIO-Pins zur Verfügung hat.
Ein FPGA ist zwar schneller, aber es geht hier ja nicht um zig Mbit/s,
sondern gerade mal um 31,25 kbit/s.
Ein STM32F103 im 48-Pin-Gehäuse ist billig und könnte ganz gut passen.
Oder auch ein RP2350B. Der hat mehr Rechenleistung, was ein Vorteil sein
kann, wenn komplexere Filterfunktionen benötigt werden und noch mehr als
die 16 UARTs (bis zu 24) gewünscht sind.
Auch mit einem RP2040 ist schon viel möglich, allerdings hat dieser nur
GPIOs für maximal 15 UARTs. Auf dem Pico-Board gehen sogar nur 13 UARTs,
weil 4 GPIOs schon intern genutzt werden. Immerhin könnte auf dem Pico W
neben der UART-Kommunikation, dem Routing und der Filterung noch ein
Webserver für die Konfiguration über WLAN laufen, so dass man das
gesamte System auf einem einzigen, billigen Board implementiert werden
kann, das nur noch mit den für MIDI erforderlichen Optokopplern und
Widerständen beschaltet werden muss.
Man kann UARTs auch in Software nachbilden, sogar ziemlich viele davon,
wenn man es geschickt angeht und genügend GPIO-Pins zur Verfügung hat.
Wahrscheinlich muss in dieser speziellen MIDI-Anwendung ein (großer?) Teil der UARTs nur senden, noch dazu alle mit der gleichen festen Baudrate. Das ist in Software trivial; Empfang nicht so sehr.
Man kann UARTs auch in Software nachbilden, sogar ziemlich viele davon,
wenn man es geschickt angeht und genügend GPIO-Pins zur Verfügung hat.
Wahrscheinlich muss in dieser speziellen MIDI-Anwendung ein (großer?)
Teil der UARTs nur senden, noch dazu alle mit der gleichen festen
Baudrate. Das ist in Software trivial; Empfang nicht so sehr.
Das ist richtig.
Wie viele Inputs und Outputs real benötigt werden, hängt natürlich vom
Gerätepark des Anwenders ab.
Hier sind noch ein paar Überlegungen zu einer möglichen Realisierung der
Patchbay:
Das Senden ist einfacher, weil die Software dazu nur im Takt der Baurate
(also 31,25 kHz) laufen muss. Für das Empfangen wird als Abtastrate ein
Vielfaches dieser Frequenz benötigt. So ist bspw. beim AVR-UART der
Faktor wahlweise 8 oder 16. Die High-/Low-Entscheidung für jedes Bit
erfolgt dort per Majority-Voting über 3 Abtastwerte in der (ungefähren)
Mitte des Bits, was der Elimination potentieller Spikes dient.
Wenn man auf das Majority-Voting verzichtet und von einer genauen
Einhaltung der 31,25 kbaud bei allen angeschlossenen Geräten ausgeht,
reicht theoretisch auch schon ein Abtastfaktor von 2. Allerdings würde
ich hier im Sinne einer hohen Zuverlässigkeit (Jonathans öffentliche
Synthie-Konzerte sollen ja schließlich nicht im Desaster enden ;-))
keine Abstriche machen.
Will man den oben beschriebenen AVR-UART in Software nachbilden, muss
diese zyklisch mit einer Frequenz von 250 kHz (8-fach) bzw. 500 kHz
(16-fach) abgearbeitet werden. Ein STM32F103 läuft mit 72 MHz, d.h. ein
Softwarezyklus darf bis zu 288 bzw. 144 CPU-Zyklen dauern. Bei einem
RP2040 mit 130 MHz dürfen es sogar bis zu 520 bzw. 260 CPU-Zyklen sein.
Um auch bei 16 Inputs noch schnell genug zu sein, bearbeitet man in dem
zeitkritischen, für das Bit-Sampling zuständigen Softwareteil am besten
alle Inputs parallel ab. Auf der 32-Bit-CPU können das bis zu 32 sein.
So spielt es an dieser Stelle keine (oder oder nur eine untergeordnete)
Rolle, ob man 4, 16 oder 32 Inputs hat.
Beim Shiften der Bits in Bytes ist diese Parallelisierung nicht möglich.
Hier ist der Aufwand proportional zur Anzahl der Inputs. Da dies aber
nur mit einer Zykluszeit von 1 Bitdauer erfolgen muss, darf dies bis zu
32 µs, also 2304 CPU-Zyklen auf dem STM32F103 oder 4160 CPU-Zyklen auf
dem RP2040 dauern. Selbst für 32 Inputs dürfte das noch locker machbar
sein. In diesem Teil der Software werden auch die Outputs bedient.
Ich schätze, dass die auf einem RP2040 maximal möglichen (wegen der
begrenzten Anzahl von GPIOs) 15 Software-UARTs (also 15 Inputs und 15
Outputs) höchstens 20% eines CPU-Cores belegen. Die verbleibenden
mindestens 80% stehen für das Routing und Filtering zur Verfügung. Falls
das nicht reichen sollte, kann man ja noch den zweiten Core aktivieren.
Dieser Softwareteil ist nur insofern echtzeitkritisch, dass er die
Latenz der übertragenen Nachrichten beeinflusst. Die von Jonathan
akzeptierten 4-5 ms stellen diesbezüglich aber keine hohe Anforderung
dar.
Als Konfigurationsschnittstelle kann wahlweise USB, WLAN (beim Pico W)
oder auch einer der Midi-Anschlüsse (mit "SysEx", wie ich inzwischen
gelernt habe :)) verwendet werden, je nachdem, was für den Benutzer am
praktikabelsten ist.
Das Verhältnis von Inputs zu Outputs muss nicht unbedingt 1:1 sein. So
lässt sich die Software konfigurierbar gestalten, dass statt 15I/15O
bspw. auch 8I/22O oder 20I/10O möglich sind. Die externe Hardware
(Optokoppler und Widerstände) könnte so aufgebaut werden, dass jeder
Anschluss mit Steckbrücken wahlweise als Input oder Output konfiguriert
werden kann.
Damals(tm) in unserer Schule hatten wir PET 2001 mit weißem Phosphor
Die hatten wir auch - die Farbe war aber definitiv grün. Wie die
zustande kam, darum habe ich mich allerdings nicht gekümmert.
Die PETs gab es an unserer Schule schon zur Zeit meiner Umschulung, d.h. im Sommer 1979. Laut der oben verlinkten Webseite des Computermuseums an der Uni Stuttgart gilt: "Ausgerüstet ist er mit einem 9"-Monitor, der in der älteren Version, wie er im Museum steht, noch einen weiß leuchtenden Phosphor hat." Möglicherweise wurden bei späteren Versionsständen des PET 2001 derselbe grüne Monitortyp wie bei den CBM 30xx eingesetzt.
Wie ich beim Lesen des Wikipediaartikels erfahren habe, wurde der Name PET u.a. durch Pet Rock, d.h. Haustiersteine, inspiriert. Ich wusste noch gar nicht, dass diese schon 1975 "erfunden" wurden, und dachte immer, sie wären um 2010 erstmalig auf dem Markt angeboten worden. Zumindest gab es sie zu der Zeit bei getDigital. Neu war offenbar nur der "USB-Anschluss".
Wir hatten die auch immer Computerraum. Ebenfalls 1979. Allesamt grün.
Es waren die mit der Cassettet - so wie der im Bild.
Es geht jetzt so oder so Richtung Off-Topic: Auch wir hatten einen PET-2001, das Lieblingsspiel der pubertierende Jungs (keine Maedels) war Space-Invader.
