Moin aus Bremen! 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? Beste Grüße!
:
Bearbeitet durch User
Könnte man so machen. 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 nächsteinfachste sind Quad-UARTs mit Intel 8080 Bus wie z.B. den hier: https://www.ti.com/lit/ds/symlink/tl16c754b.pdf 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. fchk
Jonathan schrieb: > EIN MIDI-Interface an einem z.B. Arduino zu verwenden, ist trivial. Aber > was ist mit 16? Ein kleines FPGA für 10€ wäre meine Lösung für das Problem. Da ist eine SIO relativ einfach zu implementieren: - http://www.lothar-miller.de/s9y/archives/48-RS232.html 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... ;-)
Jonathan schrieb: > 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.
Hallo ihr zwei! Frank K. schrieb: > 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. Lothar M. schrieb: > Ein kleines FPGA für 10€ wäre meine Lösung für das Problem. Da ist eine > SIO relativ einfach zu implementieren: > - http://www.lothar-miller.de/s9y/archives/48-RS232.html > > Verglichen mit dem Preis von fast 20€ für ein solches Mäxchen wäre die > FPGA-Lösung sogar noch billig. Ich glaube, das übersteigt dann doch meine Fähigkeiten. Da müsste ich mich mal reinlesen... Falk B. schrieb: > 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".
Jonathan schrieb: > 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.
Bauform B. schrieb: > Jonathan schrieb: >> Aber was ist mit 16? So viele UART-Interfaces hat selbst ein STM32 >> nicht zur Verfügung. > > Muss es denn eine runde Zahl sein? YMMD! Total gut! Es gibt 10 Arten Menschen auf der Welt....
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. http://www.midibox.org/dokuwiki/doku.php?id=home:project:midi_mapper Gruß Roman
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: > 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.
:
Bearbeitet durch User
Bauform B. schrieb: > 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. Roman K. schrieb: > Die > Einschränkungen auf den Stimmbereich bzw. Kanal solltest du am > jeweiligen Midigerät durchführen. Motopick schrieb: > 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 ;)
:
Bearbeitet durch User
Jonathan schrieb: > 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.
Andreas S. schrieb: > 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. Um den Overkill noch zu verstärken!!! JAWOHL! ;-)
Falk B. schrieb: > Um den Overkill noch zu verstärken!!! JAWOHL! ;-) 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.
:
Bearbeitet durch User
Andreas S. schrieb: > ... 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.
:
Bearbeitet durch User
Jonathan schrieb: > 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.
Motopick schrieb: > 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). fchk
Jonathan schrieb: > 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 😊
Michael W. schrieb: > Das alles konnte/kann das MIDITEMP PMM-88 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. Das lief problemlos auch mit hohen Bitraten.
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.
Michael W. schrieb: > Das alles konnte/kann das MIDITEMP PMM-88 E (und Geräte der MP-88-Serie) So was hab ich noch hier und brauche es nicht mehr. Bei Bedarf schick mir ne PM.
Gerhard Z. schrieb: > Michael W. schrieb: >> Das alles konnte/kann das MIDITEMP PMM-88 E (und Geräte der MP-88-Serie) > > So was hab ich noch hier und brauche es nicht mehr. Bei Bedarf schick > mir ne PM. Falls Du mich meintest: ich habe eine PMM-88 E hier stehen... 😉
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.
Harald A. schrieb: > 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. fchk
Frank K. schrieb: > Wenn das dann alles so funktioniert, dann kann er davon immer noch eine > Leiterplatte machen. 100% ACK - mit den JSTs inkl. GND und VCC eine perfekte Vorlage.
:
Bearbeitet durch User
Harald A. schrieb: > 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
Εrnst B. schrieb: > Device-Nodes können statt auf Seriennummer auch auf den "Pfad" matchen, Gute Idee, die konsistente Nummerierung der 8 Ports im CH348 sollen die ja hoffentlich hinbekommen. Dann wird es nochmal billiger: https://de.aliexpress.com/item/1005005200591341.html 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).
J. S. schrieb: > Wollte ich eigentlich schon längst releasen, aber es finden sich zu > wenige Interessenten. Die meisten, die noch Hardware nutzen, haben ihren Kram zusammen. Viele, wie z.B. auch Musikschulen brauchen da eher Reparatur oder Datenträgeranpassung. Oft wird ja auch empfohlen, einfach anzufangen: https://www.sequencer.de/synthesizer/threads/arbeiten-mit-einer-midi-patchbay-am-praktischen-beispiel.107589/
Ob S. schrieb: > Ich würde drei AVR128DB64 verwenden. Für jemanden, der als einziges Werkzeug nur den Hammer kennt, sieht jedes Problems wie ein Nagel aus.
Andreas S. schrieb: > Für jemanden, der als einziges Werkzeug nur den Hammer kennt, sieht > jedes Problems wie ein Nagel aus. Für jemanden welcher noch nie ein Hammer gesehen hat, für den ist der Nagel ein Null Ohm R. ;-)) Mfg alterknacker P.s. Toleranz sollte eine gute Eigenschaft eines Menschen sein.
Andreas S. schrieb: > Für jemanden, der als einziges Werkzeug nur den Hammer kennt, sieht > jedes Problems wie ein Nagel aus. Oh, ich kenne durchaus auch andere Werkzeuge. Aber ich kann, anders als manch anderer, auch rechnen. Wieviel Prozent von deinem "tollen" Design-Vorschlag kannst du denn für 8€ kaufen?
Ob S. schrieb: > Wieviel Prozent von deinem "tollen" Design-Vorschlag kannst du denn für > 8€ kaufen? Stimmt. Aber für ein Einzelstück und Hobbyprojekt ist es egal, ob die Hardware 10 oder 50 Euro kostet. Egal. Viele Wege führen nach Rom und fast genau so viele zu so einem 16 Kanal MIDI-Mixer.
:
Bearbeitet durch User
Jonathan schrieb: > 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.
:
Bearbeitet durch User
Harald A. schrieb: > Jonathan, liest Du noch mit oder hat es sich erübrigt? Vermutlich zu Recht ausgeklinkt, nachdem die ersten FPGA Vorschläge mit eingebettetem Großrechner und ausgewachsenem Betriebssystem kamen. ;-)
Ob S. schrieb: > 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.
Gregor J. schrieb: > 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.
Andreas S. schrieb: > 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.
Moin, 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. Hier ein Beispiel für 8 uarts: https://www.parallax.com/multiple-serial-port-16-object/ In die Programmiersprache Spin kommst du ohne Probleme rein und es gibt genügend Beispiele. Die community ist auch sehr hilfsbereit und vor allem freundlich: https://forums.parallax.com/ Evtl. findest du auch schon fertige Lösungen die deinem Problem nahekommen, ich hab da jetzt noch nicht näher gesucht. Kannst mich auch gerne per PN kontaktieren falls du noch ein paar Tipps brauchst Gruß Christian
Falk B. schrieb: > 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.
Ob S. schrieb: > 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.
Andreas S. schrieb: > 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.
Norbert schrieb: > 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. ;-) Hallo Norbert, das würde mich interessieren wie? Laut https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html hat er nur zwei UARTs. Die weiteren vier bzw. sieben würdest du dann mit den GPIOs in Software machen? Dein Ansatz würde mich hier interessieren. LG Matthias
Matthias 🟠. schrieb: > Dein Ansatz würde mich hier interessieren. PIO. https://github.com/raspberrypi/pico-examples/blob/master/pio/uart_tx/uart_tx.pio
Matthias 🟠. schrieb: > Norbert schrieb: >> 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.
Matthias 🟠. schrieb: > 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.
Ob S. schrieb: > 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€.
Norbert schrieb: > Eine komplette, lauffähige Platine kostet die erwähnten 4€. Da du zwei davon brauchst, um die geforderte Zahl UARTs zu erreichen, bist du eben auch wieder bei den 8€ meines Vorschlags.
Ob S. schrieb: > Da du zwei davon brauchst, um die geforderte Zahl UARTs zu erreichen, > bist du eben auch wieder bei den 8€ meines Vorschlags. Ob, ich wollte daraus keinen Wettkampf machen… ;-)
Ob S. schrieb: > 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"
Falk B. schrieb: > Ob S. schrieb: >> 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.
Norbert schrieb: > 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.
Falk B. schrieb: > Warum mit diesem Hipster-Kram Micropython? Ist das olle C bzw. C++ jetzt > altes Eisen? Zu leistungsfähig? Nie für einen blöden Kommentar zu schade…
Norbert schrieb: >> Warum mit diesem Hipster-Kram Micropython? Ist das olle C bzw. C++ jetzt >> altes Eisen? Zu leistungsfähig? > > Nie für einen blöden Kommentar zu schade… Du scheinst auch ein Schneeflöckchen zu sein. https://micropython.org/ 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? http://docs.micropython.org/en/latest/reference/constrained.html Compilation phase 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!
:
Bearbeitet durch User
Falk B. schrieb: > 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 ;-)
Norbert schrieb: >> 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. Du weichst aus. War ja zu erwarten.
Mi N. schrieb: > 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...
:
Bearbeitet durch User
Falk B. schrieb: > Also ein Byte Code Interpreter auf einem Mikrocontroller. Darauf hat die > Welt gewartet! Die Welt vielleicht schon, nur alte Weiße Männer mit einem Horizont aus den 80er Jahren gewiss nicht.
Εrnst B. schrieb: > 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.
Falk B. schrieb: > Du weichst aus. War ja zu erwarten. Du stellst dich dumm. War ebenso zu erwarten.
Klaus schrieb: > Falk B. schrieb: >> Also ein Byte Code Interpreter auf einem Mikrocontroller. Darauf hat die >> Welt gewartet! > > Die Welt vielleicht schon, nur alte Weiße Männer mit einem Horizont aus > den 80er Jahren gewiss nicht. Gibt es doch längst. Müsste man halt in Java programmieren. Braucht man aber auch nicht unbedingt: https://news.ycombinator.com/item?id=39089294 https://github.com/riscv/riscv-j-extension
Natürlich, an die PIOs habe ich nicht gedacht. Gute Idee. Danke auch an alle für die Links zu den Beispielen.
Klaus schrieb: >> Also ein Byte Code Interpreter auf einem Mikrocontroller. Darauf hat die >> Welt gewartet! > > Die Welt vielleicht schon, nur alte Weiße Männer mit einem Horizont aus > den 80er Jahren gewiss nicht. Hahahahah, noch so ein Schneeflöcken, das keine Sekunde was substantielles vorweisen kann. Nur Jammern, aber das ohne Ende.
Falk B. schrieb: > Klaus schrieb: >>> Also ein Byte Code Interpreter auf einem Mikrocontroller. Darauf hat die >>> Welt gewartet! >> >> Die Welt vielleicht schon, nur alte Weiße Männer mit einem Horizont aus >> den 80er Jahren gewiss nicht. > > Hahahahah, noch so ein Schneeflöcken, das keine Sekunde was > substantielles vorweisen kann. Nur Jammern, aber das ohne Ende. Mann Falk, hast du eigentlich eine zumindest grobe Vorstellung davon, wann es besser ist mal die Fresse zu halten?
Angehängte Dateien:
-
pyratone_midi.jpg
180 KB
Motopick schrieb: > 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. Falk B. schrieb: > 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. Motopick schrieb: > 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.
:
Bearbeitet durch User
J. S. schrieb: > 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.
J. S. schrieb: > 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. Das entspricht nicht den Anforderungen: Jonathan schrieb: > 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...
Ob S. schrieb: > irgendeiner der anderen Blähungs-Lover Bist Du jetzt sprachlich auf dem Niveau der Bildzeitung oder des AfD-Stammtischs angekommen?
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? Beste Grüße aus Bremen!
Jonathan schrieb: > 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.
:
Bearbeitet durch User
Motopick schrieb: >> ... 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.
Jonathan schrieb: > 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.
:
Bearbeitet durch User
Falk B. schrieb: >> Verschalten das nicht unnötig verlängert. Die Übermittlung eines >> MIDI-Pakets geht mit gut 30kHz > Bitrate. Genau. >> und hat eine Wertfrequenz von 3kH. > Byterate. Genau. Byte-Rate ist Wortrate, wobei eine vollständige MIDI-Nachricht überwiegend aus mehr als einen Byte besteht. Falk B. schrieb: > 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.
Gregor J. schrieb: > 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..
J. S. schrieb: >> 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 ;-)
Gregor J. schrieb: > 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! https://eu.robotshop.com/de/products/icefun-fpga-board 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! ;-)
https://www.digikey.de/de/products/detail/amd/EK-U1-ZCU111-G/9655153 Wer mal etwas mehr Power braucht ;-)
Falk B. schrieb: > 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.
Motopick schrieb: > Vergiss USB schnell wieder. 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!
Harald A. schrieb: > Motopick schrieb: >>> ... 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.
Jonathan schrieb: > Motopick schrieb: >> Vergiss USB schnell wieder. > > 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.
:
Bearbeitet durch User
Rein technisch fühle ich mich ein wenig überfordert... Aber wie mein Sohn immer sagt, Mit man kann, sollte ,könnte ,muss, ist es es nicht getan.. MfG alterknacker
Jonathan schrieb: > 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.
Gregor J. schrieb: > 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!
Falk B. schrieb: > Gregor J. schrieb: >> 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!
:
Bearbeitet durch User
Motopick schrieb: >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.
:
Bearbeitet durch User
Falk B. schrieb: > Jonathan schrieb: >> 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. fchk
Rolf M. schrieb: > Motopick schrieb: >>Man muss dort ja keine serielle Schnittstelle mit >> einer fuer USB niedrigen Baudrate emulieren. >> ... > Bei USB-MIDI hat jedes Paket 4 Bytes. Das erste Byte enthält die Nummer > des MIDI-Anschlusses ... Da habe ich ja dann richtig vermutet. :) Frank K. schrieb: > 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 -> https://www.youtube.com/watch?v=YQvpgqEjpVY T:Atari ST & Cubase: A Recording Session Using the DAW of the 1980s! Längere Erklärung: Folge 104: Der Atari ST und MIDI - wie funktioniert(e) ein MIDI-Studio? https://www.youtube.com/watch?v=5lsMMiLlb50 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.
:
Bearbeitet durch User
Harald A. schrieb: > Die Latenzen im Linux-Kernel sind äußerst gering 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. > FPGA-Lösung favorisiert 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.
:
Bearbeitet durch User
Jonathan schrieb: > 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. Zur Info: Der RP2040 hat auch USB ;-)
Motopick schrieb: > Und: Beziffere doch mal "äußerst gering", und den *Maximalwert* Mache ich vielleicht... >> FPGA-Lösung favorisiert > Spendiert man jedem "Transformator" dann auch noch seinen eigenen > Interpreter/Softcore, auch von den uebrigen Kanaelen unbeeinflusst. ...wenn Du ihm das fertig baust. Samt Ansteuerung per Webinterface bitte.
Mi N. schrieb: > Zur Info: Der RP2040 hat auch USB ;-) 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.
Rbx schrieb: > 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. Ob S. schrieb: > Mi N. schrieb: > >> Zur Info: Der RP2040 hat auch USB ;-) > > 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. Warum dann nicht gleich den Teensy, den ich vorgeschlagen habe? Der hat schon Ethernet und USB Host und USB Device eingebaut.
Rolf M. schrieb: > Rbx schrieb: >> Warum jetzt ein Raspi gut ist: den kann man programmieren, und >> (hardwaretechnisch) erweitern. > > Dafür muss der immer erst booten Das macht der aber nur einmal. Du baust bei deiner Musikanlag 100x länger auf, als der Raspberry Pi bootet ;-) > und will nachher auch wieder > runtergefahren werden. Wenn man das richtige Linux nutzt, kann man den eiskalt ausschalten. Stichwort overlay file system. https://www.raspberrypi.com/documentation/computers/configuration.html#overlay-file-system > Warum dann nicht gleich den Teensy, den ich vorgeschlagen habe? Der hat > schon Ethernet und USB Host und USB Device eingebaut. 1001 Wege um ins Gras zu beißen, ähhh, MIDI zu multiplexen ;-)
Rolf M. schrieb: > 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...
Falk B. schrieb: >> Dafür muss der immer erst booten > > 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? Ob S. schrieb: > Rolf M. schrieb: > >> 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.
:
Bearbeitet durch User
Rolf M. schrieb: > Falk B. schrieb: >>> Dafür muss der immer erst booten >> >> 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.
Falk B. schrieb: > Rolf M. schrieb im Beitrag #77> >> 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.
Harald A. schrieb: > 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.
Rolf M. schrieb: > 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. Wow! Gibt es das Projekt irgendwo dokumentiert? Ich könnte ein Steuergerät gebrauchen, wie das hier: https://www.thomann.de/de/faderfox_ec4.htm 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.
Motopick schrieb: > 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 ;-)
Hat schon jemand PSoC 5/6 von Infineon (vormals Cypress) vorgeschlagen? Die gibt es mit sehr vielen Logikblöcken die jeweils eine serielle Schnittstelle machen können. 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.
Rolf M. schrieb: > Dafür muss der immer erst booten und will nachher auch wieder > runtergefahren werden. Da heißt ja nicht, das man sich mit diesem (booten) oder jenem (Timing,Latenz) nicht auch beschäftigen kann: https://www.industry-of-things.de/so-wird-ein-raspberry-pi-echtzeitfaehig-a-eae9bffa371c43c02e8f95b5b7ae2f57/ https://copperhilltech.com/blog/fastboot-your-raspberry-pi-3-linux-in-under-two-seconds/ Bei früheren Analogen Anlagen, war es auch gut, so 30 Min abzuwarten für besseren Klang. Der Atari ST als Midi-Zentrale ist bzw. war auch supernützlich, man konnte dann z.B. Sequenzen vom schlechten Emax-Sequenzer an den Atari übertragen, der keine Probleme mit solchen Sequenzen hatte. Darüber hinaus können Synthesizer und Sampler auch Timing-Schwierigkeiten haben. Diese kleinen Module wie das MT-32 oder der E-mu Morpheus https://www.amazona.de/vintage-digital-e-mu-morpheus-ultraproteus-synthesizer/ waren nicht ohne Grund so beliebt. Was auch toll war, man konnte mit ein paar Billig-Synths* Songs vorproduzieren, und brauchte im Studio mit teurem Klangerzeugerzeugs zur Aufnahme nur noch Feineinstellungen machen. *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 [OT] (Zugabe :)) https://www.youtube.com/watch?v=NaBjo1c8Eec https://www.youtube.com/watch?v=nqVJWFNpTqA&list=PLHDxrzOvt6kSlixbgxgpTXkonfe1yfcCo&index=2 [/OT]
Guido K. schrieb: > 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. Rbx schrieb: > Der Atari ST als Midi-Zentrale ist bzw. war auch supernützlich, Hat aber nur eine MIDI-Leitung.
Falk B. schrieb: > Harald A. schrieb: >> Kollege Stefanus (wo ist der eigentlich, lange nichts mehr gehört) > Der hat sich wohl, wie viele andere auch, ausgeklinkt. nö, er schreibt nur inzwischen unter vielen anderen Nicknames und neuen Namen.
Joachim B. schrieb: >> Der hat sich wohl, wie viele andere auch, ausgeklinkt. > > nö, er schreibt nur inzwischen unter vielen anderen Nicknames und neuen > Namen. Warum? War sein alter (Marken)name so verbraucht? Raider ist jetzt Twix?
Falk B. schrieb: > Warum? War sein alter (Marken)name so verbraucht? Raider ist jetzt Twix? Frag ihn doch selbst. Hilft gerade bei zur Midi-Musik tanzenden Gärboxen aus.
Hallo Jonathan. 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? Hardware: z.B. TI DP83620 Software: Nach Belieben :)
Jens K. schrieb: > 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 (edit: das hier ist aus künstlerischer Sicht auch ganz gut, erinnert ein wenig an eine glattgebügelte Spiegelwelt: https://www.youtube.com/watch?v=NJ3UhGIxozU&list=PL-wIRClcMZiGgCqnVcgazWUhu7cHE8tKg&index=2 ) 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.
:
Bearbeitet durch User
Jens K. schrieb: > 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. Nennt sich SYSEX-Level.
Simon R. schrieb: > Sind wir nun beim Webinterface? Seit dem OP > Wofür? für MIDI? Wenn er es sich wünscht? Vlt. will er sich das genau deshalb bauen, weil die Standardkomponenten das anders machen, so wie Du beschreibst.
Simon R. schrieb: > Dann IConnectivity mioXM mit Expander. Wow, krass. Die kannte ich noch gar nicht. Gegenüber den bisher genannten alten Oldies (s.o.) zu Wucher Preisen ist das hier der Hammer: https://www.thomann.de/de/iconnectivity_mioxm.htm oder als XL https://www.thomann.de/de/iconnectivity_mioxl.htm Aber was wäre ein Hobby, wenn man es nicht selber versucht :-) Außerdem lernt man dann MIDI viel besser zu verstehen als nur Plug-and-Play ...
Jonathan schrieb: > 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. Rbx schrieb: > Jens K. schrieb: >> 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.
Harald A. schrieb: > Simon R. schrieb: >> Sind wir nun beim Webinterface? > > Seit dem OP 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.
Ob S. schrieb: > 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.
Klaus schrieb: > Das genaue Gegenteil ist richtig. > Kein Mensch will proprietäre Apps/GUIs, die nur auf einem Devicetype > funktionieren. 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.
Klaus schrieb: > Bullshit. Hochkompetent vorgebrachtes, überaus sachhaltigen Argument. Davor kann man wohl nur kapitulieren.
Ob S. schrieb: > Klaus schrieb: >> Bullshit. > > 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.
:
Bearbeitet durch User
Soo, ich finde wieder Zeit! Simon R. schrieb: > Dann IConnectivity mioXM mit Expander. 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: Ob S. schrieb: > dass das OT Bullshit > ist. Ich bin ja wirklich froh, hier einen sachlichen Austausch zu haben! Ob S. schrieb: > 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). Ob S. schrieb: > 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.
Motopick schrieb: > 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 ? Schafft der https://de.farnell.com/lattice-semiconductor/lcmxo2-640hc-4sg48i/fpga-machxo2-40-i-o-qfn-48/dp/3768755 das ? Wir wissen schon, dass 3 RP2040 es schaffen.
Michael B. schrieb: > Motopick schrieb: >> 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. > Schafft der > https://de.farnell.com/lattice-semiconductor/lcmxo2-640hc-4sg48i/fpga-machxo2-40-i-o-qfn-48/dp/3768755 > das ? 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...
Motopick schrieb: > Das man nun schon 3 von den RP2040 braucht... 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!
Norbert schrieb: > Motopick schrieb: >> Das man nun schon 3 von den RP2040 braucht... > > 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.
Motopick schrieb: > Du hast falsch zitiert! Das ist nicht meine Behauptung. Ich bin da eigentlich recht sorgfältig. Dein Beitrag vom 12.08.2024 13:13 Motopick schrieb: > 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? Motopick schrieb: > Inwieweit diese neun Inputs und die mindestens 13 Outputs einfach > handhabar sind, schreibst du aber nicht. Das ist korrekt. MIDI IN: Zwei mittels UART, sieben mittels SMs. Auf'm Kern0 MIDI OUT: Alle mittels der letzten verbliebenen SM über DMA. Auf'm Kern1
Norbert schrieb: > Motopick schrieb: >> Du hast falsch zitiert! Das ist nicht meine Behauptung. > > Ich bin da eigentlich recht sorgfältig. Es war klar erkennbar in meinem Beitrag ein Zitat von: Michael B. schrieb: ... > Wir wissen schon, dass 3 RP2040 es schaffen. ...
Norbert schrieb: > Belassen wir's dabei. Dann bleibt es bei: > Du hast falsch zitiert! Das ist nicht meine Behauptung.
Motopick schrieb: > Norbert schrieb: >> Belassen wir's dabei. > > Dann bleibt es bei: >> 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‹.
Norbert schrieb: > DU hast diesen Satz in deinem Text geschrieben. Das es ein Zitat ist, ist klar durch das vorangestellte ">" erkennbar. Und die Quelle des Zitats steht im Beitrag oben. Soweit zu "recht sorgfältig". Doch wohl eher ein wenig schluderig. :)
Klaus schrieb: > Das genaue Gegenteil ist richtig. > Kein Mensch will proprietäre Apps/GUIs, die nur auf einem Devicetype > funktionieren. Man kann es aber auch übertreiben! Was ist denn gegen ein simples MIDI/UART-Interface zu sagen? ALLE, wirklich ALLE Midi-Geräte arbeiten selber auch mit MIDI, um sie zu steuern. Norbert schrieb: > IDI IN: Zwei mittels UART, sieben mittels SMs. Auf'm Kern0 > MIDI OUT: Alle mittels der letzten verbliebenen SM über DMA. Auf'm Kern1 alles zu kompliziert. Ein kleiner ARM und es rennt! Wird ja in jedem MIDI-fähigen device so gemacht.
Angehängte Dateien:
-
myMidiTestBoard_www.jpg
460 KB
Simon R. schrieb: > 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. Motopick schrieb: > 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 ;-) ;-) Jonathan schrieb: > 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. Rbx schrieb: > ..., 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. Matthias
Simon R. schrieb: > 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?
Klaus schrieb: > 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.
Motopick schrieb: > 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?
Klaus schrieb: > Motopick schrieb: >> 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. :)
Motopick schrieb: > 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. Klaus schrieb: > Und den Tippe ich dann manuell mit einer Tsstatur ein? Also wie sieht > Bedienoberfläche aus? Ein MIDI-Controller oder ein virtueller als Software im PC. Oder eben gleich die DAW, z.B. Logic oder Reason.
Jonathan schrieb: > 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.
J. S. schrieb: > 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. Gerade zur Anfangszeit wurde auch noch groß herumgehypt, was auf technischem Wege (angeblich) alles möglich ist mit MIDI. (https://www.youtube.com/watch?v=mua8Pr6uRso)
Angehängte Dateien:
-
midi_routing_example.jpg
88 KB
Rbx schrieb: > 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
midi-burner.jpg
230 KB -
midi-minder.jpg
250 KB
Jonathan schrieb: > 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.
Andi schrieb: > Alles schön hübsch mit einem alten > Mono-Analogmonitor in grün wie in den 1990ern. Grün waren vor allem die Apples und der BBC ;) (https://www.youtube.com/watch?v=wXpP1-mdkzA)
Andi schrieb: > Es wird wieder geplugged. Und gedenglischt, ähh, gedengelt. ;-) 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. Wird es eine Wiederauferstehung der Schellackplatte geben? Mit romantischem Knistern.
Angehängte Dateien:
-
wieso_90er.jpg
110 KB
Andi schrieb: > Alles schön hübsch mit einem alten > Mono-Analogmonitor in grün wie in den 1990ern. Wieso 90er?
Rbx schrieb: > Grün waren vor allem die Apples und der BBC ;) und der PET 2001 von 1979, welcher apple hatte einen Monitor in grün?
:
Bearbeitet durch User
Falk B. schrieb: > Wird es eine Wiederauferstehung der Schellackplatte geben? Mit > romantischem Knistern. Schellackplatten wird es wohl eher nicht mehr geben, aber es gibt doch seit einigen Jahren wieder mehr Schallplatten, d.h. auch Neuerscheinungen. https://www.youtube.com/watch?v=0Np1BCM6lwk
J. S. schrieb: > OT. Der konnte kein MIDI :-) ne, das konnte wieder der AtariST, sogar ab Werk ohne Umbau. Ich fragte nur welcher apple grün konnte serienmäßig, mit extra Grünmonitor gilt nicht, das kann fast jeder. Rbx schrieb: > Grün waren vor allem die Apples
Joachim B. schrieb: > Ich fragte nur welcher apple grün konnte serienmäßig, mit extra > Grünmonitor gilt nicht, das kann fast jeder. Die offiziellen Monitore zu den Modellen II (euro)plus, IIe, III und IIc waren auf jeden Fall grün, siehe z.B.: https://en.wikipedia.org/wiki/Apple_Monitor_II https://www.homecomputermuseum.de/sammlung/detailansicht?tx_compges_computer%5Baction%5D=show&tx_compges_computer%5Bcomputer%5D=91&tx_compges_computer%5Bcontroller%5D=Computer&cHash=e2756185a03f9ae286aab38d0a1e9dd3 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).
Joachim B. schrieb: > 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.
Norbert schrieb: > Andi schrieb: >> Alles schön hübsch mit einem alten >> Mono-Analogmonitor in grün wie in den 1990ern. > > Wieso 90er? cool-retro-term?
Rolf M. schrieb: > Norbert schrieb: >> Andi schrieb: >>> Alles schön hübsch mit einem alten >>> Mono-Analogmonitor in grün wie in den 1990ern. >> >> Wieso 90er? > > cool-retro-term? Daumen hoch!
Rbx schrieb: > Joachim B. schrieb: >> 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 https://computermuseum.informatik.uni-stuttgart.de/dev/pet2001/ meiner von Quelle 1979 kam leider in grün https://www.hnf.de/retrolab-intro/42-commodore-pet-2001.html Ein Kollege berichtete sogar von Farbumbauten, sah ich aber nie https://newatlas.com/love-hulten-pet-de-lux/53608/
Joachim B. schrieb: > 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
waldorf_pulse.jpg
73 KB
Andreas S. schrieb: > 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. Rbx schrieb: > 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:
J. S. schrieb: > 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.)
Nee denn kenne ich nicht. Rbx schrieb: > Oktav-Überblendungen Glisandi? Portamenti? > einfache Akkorde über schnelle Wechsel 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.
Der Thread ist zwar nicht mehr ganz frisch, aber vielleicht schaut Jonathan ja noch einmal herein. Jonathan schrieb: > 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.
Yalu X. schrieb: > 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.
Bauform B. schrieb: > Yalu X. schrieb: >> 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.
J. S. schrieb: > Andreas S. schrieb: >> 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". Quellen: https://de.wikipedia.org/wiki/PET_2001 https://www.getdigital.de/pages/offlineprodukt/usb-haustier-stein
Angehängte Dateien:
-
pet2001.jpg
85 KB
Andreas S. schrieb: > Die PETs gab es an unserer Schule Wir hatten die auch immer Computerraum. Ebenfalls 1979. Allesamt grün. Es waren die mit der Cassettet - so wie der im Bild. Zum Thema Steuerung der MIDI-Umschaltung hätte ich noch das hier: https://de.wikipedia.org/wiki/Open_Sound_Control
J. S. schrieb: > Andreas S. schrieb: >> Damals(tm) in unserer Schule hatten wir PET 2001 mit weißem Phosphor > Die hatten wir auch - die Farbe war aber definitiv grün. genial, mit weißem Phosphor in grün 🤣🤣🤣🤣
J. S. schrieb: > Andreas S. schrieb: >> Die PETs gab es an unserer Schule > 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. Die Space-Taste hielt zwei Monate.
Thomas W. schrieb: > Die Space-Taste hielt zwei Monate. war auch mein Lieblingsspiel, aber bevor die bei mir ausfiel lockte der apple2 Nachbau.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.