MIDI Signal als Audio modulieren/aufzeichnen

[Stefan_O]

Hallo,
in Live-Settings soll die MIDI-Spur eines E-Pianos aufgezeichnet werden. Dafür soll jetzt nicht noch ein Notebook mit irgendeiner DAW-Software hinzukommen, sondern einfach über ein Digitalpult auf einer freie Audiospur (sowie Fax oder Modem auch über Audiosignale auf der Telefonleitung übertragen werden, also nicht indem da irgendein Instrument drauf kommt, sondern als ein moduliertes MIDI-Signal). MIDI hat 31,25 kBit/s, die letzte Modem-Generation hat es geschafft über eine Telefonleitung 56 kBit/s zu übertragen, bedeutet mit der richtigen Modulation ist bei 24 Bit / 48 kHz mehr als genug Bandbreite da, selbst wenn man durch zu niedrigen Pegel die 24 Bit nicht ausreizt und noch Rauschen etc. drauf ist. Im Idealfall hat man dann eine Rechner-Software, die das Audio am Rechner wieder demoduliert und eine Midi-Datei ausspuckt, die man dann in eine DAW-Software ziehen kann.
Weiß irgendjemand ob man so ein Gerät kaufen kann? Einfach MIDI in, XLR out.
Viele Grüße
Stefan

 

[HaraldS]

Das klingt so, als ob du einiges durcheinander bringen würdest…

Ein E-Piano produziert bei jedem Tastendruck i.d.R. 3 Bytes, beim Loslassen der Taste noch einmal. Diese 6 Bytes könnte man übertragen, und eine empfangende Soft- oder Hardware könnte beim Empfang dieser Daten diese z.B. so interpretieren, dass eben ein vorher aufgenommener Ton anfängt und beendet wird. In diesem Fall werden aber keine Audiodaten übertragen, sondern Steuersignale.

Diese Steuersignale kann man auch als Datei gemäß des MIDI-Standards speichern und z.B. als Anhang an eine e-Mail verschicken. Damit kann man ganze Aufnahmen von Stücken verschicken - allerdings, wie gesagt, sind das nur die Steuersignale. Quasi die Bedienaktionen, wann jemand welche Tasten/Knöpfe/Pedale bedient hat.

Und ein E-Piano hat einen Audio-Out. Den könnte man durchaus an ein Digitalpult anschließen, wo der Klang in einen digitalen Datenstrom gewandelt wird. Auch diese Daten könnte man als Stream oder als aufgenommene Datei verschicken - und erst dann würde so etwas wie Rauschen eine Rolle spielen, worüber du dir ja Gedanken machst. Solange es um MIDI geht kann da nichts rauschen, weil ja gar keine Klänge übertragen werden.

 

[Be-3]

Wie ich @Stefan_O verstanden habe, will er ja gerade keine Audio-Daten, sondern MIDI-Daten übertragen, diese allerdings etwas unorthodox als Audio-Spur speichern.

Also genau so, wie früher die Telefon-Modems digitale Daten wie ein Fax in per Audio übertragbare Tonfolgen modulieren, die später wieder in digitale MIDI-Daten demoduliert werden können.
Am Ende sollen über den Umweg einer Audio-Spur wieder die ursprünglichen MIDI-Daten rekonstruiert werden.

Fertige Geräte wird es wohl nicht geben. Vielleicht könnte man mit einem Arduino oder Raspberry-PI etwas basteln, aber da wäre wohl ein ordinärer MIDI-Recorder (vielleicht sogar als Smartphone-App?) einfacher und billiger.
Die Idee ist allerdings schon interessant und überaus kreativ.

Viele Grüße
Torsten

 

[Stefan_O]

Wie ich @Stefan_O verstanden habe, will er ja gerade keine Audio-Daten, sondern MIDI-Daten übertragen, diese allerdings etwas unorthodox als Audio-Spur speichern.

Also genau so, wie früher die Telefon-Modems digitale Daten wie ein Fax in per Audio übertragbare Tonfolgen modulieren, die später wieder in digitale MIDI-Daten demoduliert werden können.
Am Ende sollen über den Umweg einer Audio-Spur wieder die ursprünglichen MIDI-Daten rekonstruiert werden.

Fertige Geräte wird es wohl nicht geben. Vielleicht könnte man mit einem Arduino oder Raspberry-PI etwas basteln, aber da wäre wohl ein ordinärer MIDI-Recorder (vielleicht sogar als Smartphone-App?) einfacher und billiger.
Die Idee ist allerdings schon interessant und überaus kreativ.

Viele Grüße
Torsten

Exakt das meinte ich. Es soll in Live-Situation vor allem einfach & unkompliziert sein und danach auch ohne Bastelei synchron sein, so dass ich die Audiodateien zusammen mit einer demodulierten MIDI-Datei einfach z.B. in Logic ziehen kann. Man hat meistens mehr als einen Kanal frei und ein weiteres Kabel ist höchstens 1 Minute Arbeit, ein zusätzliches Gerät und das ganze danach noch synchron zu bekommen ist wesentlich mehr Aufwand. Ich hatte gehofft das jemand vor mir schon auf so eine Idee gekommen ist (und sie umgesetzt hat). Ich weiß nicht ob es möglich wäre mit einem Arduino das MIDI Signal an ein altes Modem weiterzuleiten und dann mit einer Art DI-Box von Telefonleitung auf XLR zu gehen. Das wäre aber nur eine Bastellösung zum erproben, nichts für die Bühne. Im Idealfall gibt es noch fertige Modem-Modulator ICs die man kaufen kann und mit einem Arduino verbinden oder sogar ohne Mikrocontroller direkt das MIDI Signal akzeptieren (ist eine serielle Schnittstelle mit anderem Pegel als RS-232 und unkonventioneller Baudrate)

Das klingt so, als ob du einiges durcheinander bringen würdest…

Jein, meine Idee ist es das absichtlich durcheinander zu bringen

 

[Signalschwarz]

...ein zusätzliches Gerät und das ganze danach noch synchron zu bekommen ist wesentlich mehr Aufwand.

Ich weiß nicht ob es möglich wäre mit einem Arduino das MIDI Signal an ein altes Modem weiterzuleiten und dann mit einer Art DI-Box von Telefonleitung auf XLR zu gehen.

Nimm halt erstmal Audio auf und lass es dir in der DAW-Software zu MIDI umsetzen.

Dann kannst Du ja noch einen Forschungsauftrag erteilen.

 

[adrachin]

Wo ist das Problem? Midi Ausgang mit entsprechendem Adapter in einen Eingang, Signal was hochziehen und aufnehmen.

Danach die Audiospur an einem Ausgang ausgeben, wieder runterregeln natürlich, passenden Adapter dran und dann in einen Midi Eingang.

 

[Doggiebert]

nö, also mit nem einfachen "elektrischen" Adapter wird das nicht funkionieren. Selbst wenn es mit Bandbreite/Frequenz/Pegel hinhauen würde, wäre sowas viel zu störanfällig.
Das muss schon einigermaßen bombensicher sein - ein einziger nicht erkannter note-off führt dann zu einem Notenhänger...
Google Suche nach "Midi over audio" zeigt, dass sich ein paar Leute Gedanken dazu gemacht haben, aber fertig zu kaufen oder Bauanleitung ist wohl Fehlanzeige.
Midi als Midi und Audio als Audio aufzeichnen ist immer der problemlosere Weg, Verkabelung dafür ist ja überschaubar. Bin jetzt kein Experte dafür, aber für Synchronität müsste man doch über SMPTE / Midi Time Code irgendwie herstellen können?

Was ich mir auch noch vorstellen könnte, Midi durch ein Soundmodul zu jagen (irgendein klarer Sound), als normale Audiospur aufzeichnen, und dann über Audio-to-Midi rückzuverwandeln, das können ja die DAWs (und auch Gitarrrensynthesizer) wohl ganz gut. Wird aber nicht für beliebig polyphones Material funktionieren, und kann natürlich auch nur das klassische note on/off und ggf. velocity, aber das volle Midi Repertoire kriegt man damit nicht.

 

[Stefan_O]

Das Midi einfach auf Audio legen wird so nicht gehen: Zwar braucht man bei 31,25 kBaud nur 15,625 kHz Bandbreite, dass würde theoretisch gehen, sogar schon mit 32 kHz Sample Rate, aber in der Praxis wird das wie schon gesagt nicht zuverlässig funktionieren (weil das ein Rechtecksignal ist und kein Sinus). "MIDI over Audio" hatte ich tatsächlich noch nicht gesucht, da findet man tatsächlich was, andere heben ähnliche Ideen gehabt. Leider habe ich kein fertiges Projekt gefunden das man nachbauen kann, angeblich gab es sowas von ESI, aber bei denen finde ich nichts das auch nur annähernd vergleichbar ist. Ich vermute wenn ich mal viel Zeit habe muss ich mal schauen ob ich sowas bauen kann.

 

[boisdelac]

Man könnte auch das MIDI-Signal quasi offline im Homestudio in ein Musik-Sample (Audio) umwandeln und dann dieses Sample mit einem einfachen Looper/Sample-Player zeitgenau während der Live-Performance ablaufen lassen.

 

[engineer]

Weiß irgendjemand ob man so ein Gerät kaufen kann? Einfach MIDI in, XLR out.

Fertig zu kaufen gibt es das nicht, aber die Idee hatten schon einige
http://www.96khz.org/oldpages/midiasaudio.htm
Das ist aber Richtung Pulse-Amplituden-Modulation - nur ohne echte Leitungscodierung.

Klar kann man das einfach mit aufzeichnen, allerdings brauchst du schon ein bissl Elektronik:
- MIDI ist eine Stromschleife, die man mit einem Optokoppler auf einen Pegel umsetzen muss, der dann runtergeteilt auf 0,7V ins Mischpult geht.
- Das MIDI-Signal ist nicht gleichstromfrei, also gibt es ein Bandbreitenproblem nach unten.

Auf EBAY gibt es solche ARDUINO-MIDI-Shield Adapter für 7,- Euro das Stück. Damit könntest du einen Spannungspegel mit 5V erzeugen und dann mit einem XOR-Gatter in 5 Volt mit einem Takt scattern, damit du einen gleichstromfreien Code bekommst, den eine Audio-Karte mit 5-10Hz Grenzfrequenz aufzeichnen kann. Ansonsten gibt es drift, den man nachher weginterpretieren muss.

Aufzeichnen würde ich mit 192kHz und wenigstens 60kHz Bandbreite, wenn der ADC das kann. Denn;
- Ein 31kHz-Rechteck braucht streng genommen mindestens 93kHz, damit die dritte Oberwelle, voll drin ist und man ein einigermassen gut interpretierbares Signal bekommt.
- Die Nyquist-Frequenz bei 192kHz liegt bei 96kHz, mehr darf man nicht aufnehmen, wegen Spiegelfrequenzen. Daher muss ein Filter her, der 60kHz noch durchlässt und bei rund 100, spätestens 120kHz zumacht. Damit hat man wenige Störungen drin.

Einfach nur mit 48kHz aufzeichnen, gibt Spiegelfrequenzen und Gleichstromdrift.

Beim Rückinterpretieren brauchst du einen De-Scatterer, der das hochfrequente Taktsignal wieder rausnimmt oder du musst entsprechend komplizierter Interpretieren, weil es dann von den Signalflanken schwieriger wird. Läuft auf eine digitale PLL hinaus, ist aber machbar.

Ich habe solche Sachen schon gemacht, digitale Signale aus seriellen Schnittstellen mit in den Logger reinzunehmen und wie analoge Signale zu scopen. Ist aber nur sinnvoll, wenn man volle Kohärenz in den Signalen braucht. Reinterpreation mit MATLAB. Was ich heute machen würde, wäre meinen SALEA anzuwerfen und das mit aufzuzeichnen. Der kann bis 50MHz analog scopen. Allerdings kannst du dann auch die 10,- Euro Version aus der Bucht kaufen und mitlaufen lassen. Die packen immerhin 10MHz und ein Kanal ist in Echtzeit aufzuzeichnen, denke ich. Das musst du später einfach nur wieder abspielen und in elektrisches MIDI verwandeln.

Die goldene Alternative geht nur mit digitalem MIDI, wie ich es hier definiere:
http://www.96khz.org/oldpages/midi2000.htm

Also MIDI im S/PDIF verpackt. Das kannst du dann parallel mit einem anderen digitalisierten Datenstrom samplegenau aufzeichnen. Meine MIDI-Matrix im FPGA macht genau das in so einem Fall: 4 physikalische MIDI-Kabel werden auf 64 MIDI-Kanäle gemappt und ins S/PDIF verpackt. (100 wären technisch möglich, wegen 6MBit S/PDIF Datenrate). Statt das dann dem Synthesizer zuzuführen, könnte man es ins Mischpult brücken und mit aufzeichnen.

Solche Fälle sind aber eigentlich selten.

Man kann das MIDI auch völlig losgelöst aufzeichnen, wenn der Recorder einigermassen stabil läuft und im Nachhin durch einen Synthesizer geben. Längendifferenzen muss man über den Abspieler in der Soundkarte (beim MIDI!) ausgeleichen, also messen, ausrechnen und dann das Abspieltempo um einige Promille korrigieren und einmal laufen lassen. Oder halt per Hand schneiden. Habe ich auch schon machen müssen, da Begleiter beim Chor krank und nur MIDI vorrätig (im Nachhinein draufproduziert).

 

[engineer]

Zwar braucht man bei 31,25 kBaud nur 15,625 kHz Bandbreite

Das gilt soweit für einen idealen 1010-Wechsel und die Betrachtung der Grundwelle. Das MIDI-Signal ist aber ein asynchrones Protokoll, d.h. nach einer Pause kann theoretisch irgendwann ein neuer Datenstrom kommen. Je nach MIDI-Gerät ist das der Fall oder auch nicht. Viele ältere Geräte ratten mit dem doppelten Takt die Daten raus, hinzu kommt Jitter, den ein Filter und die Abtastung mit ihrer Anstiegszeit packen muss. Von daher würde man sicherheitshalber die Taktfrequenz an sich ansetzen.

Hinzu kommen die Oberwellen, die ein Rechteck bringt. Bei einem 48kHz-ADC mit fg=~20kHz wird es schon mit der 1. Harmonischen knapp. Ein richtig gutes Rechteck mit einem Anstieg im Bereich von max 20% der Periode braucht wenigstens die 9. Oberwelle. Hier ist ein Bild aus meinem Synthie, der Rechtecke manuell zusammensetzt: https://www.mikrocontroller.net/topic/520500#6868207

Einen längeren Artikel zu dem Thema habe ich hier:
https://www.mikrocontroller.net/articles/Digitaler_LaPlace-Funktionsgenerator_im_FPGA
Siehe die blaue Kurve im Bild unten.

 

[einseinsnull]

das, was du willst, ginge relativ problemlos in software umzusetzen:

jedes note on wird dabei in die notennummer umgesetzt, und jedes note off löscht diese notennumer wieder - also quasi eine art running status.

und wird gerade gar keine note gehalten, beträgt der wert des audio signals null.

bevor die verschiedenen notenwerte, die sich ja überlappen, ergo gleichzeitig stattfinden können, zu einem signal zusammengemischt werden können, werden sie in binäre werte, oder korrekter gesagt, potenzen von 2 kodiert, denn nur so entsteht bem adddieren ein wert, der sich wieder decodieren lässt.

beispiel:

ein digitales signal mit 32 bit deckt einen wertebreich von -2147483648,0 und 2147483647,0 ab

benutzen wir der einfachheit halber erst mal nur den positiven bereich von 0,0 bis 2147483647,0.

innerhalb dieses bereiches kann man alle vielfachen von 2 zwischen 2^0 und 2^30 fehlerfrei als integralzahl darstellen.

also 2, 4, 6, 8, ...-1024, 2048, ... 2147483648 ist leider eins zuviel, aber 1073741824 geht.

wir müssen jetzt nur noch den eingehenden MIDI noten bereich auf den erlaubten begrenzen. z.b. filtern wir alle noten kleiner als 48 und größer als 78 heraus.

die tasten dazwischen, von 48 bis 78 kann unser system jetzt erfassen, und diese notenwerte in 2^0 bis 2^30 umwandeln.


an einer stelle spielen wir C-E-G (5) nun gleichzeitig.

das entspricht den MIDI note on befehlen mit den notenwerten 60, 64, und 67, die unser system, was ja bei 48 anfängt, jetzt in 2^13, 2^17 und 2^20 umwandelt.

diese zahlen addieren wir jetzt:

8192
131072
524288
________
1187840

unser audio signal, was bislang auf den wert 0 gesetzt war, springt jetzt mit dem nächsten sample auf den wert 1187840, der unverkennbar das ereignis "C Dur Akkord auf dem mittleren C" repräsentiert und leicht zurückcodiert werden kann, weil die zahl 1187840 sich nämlich praktischweise auf genau auf eine einzige art wieder in potenzen von 2 zerlegen lässt: nämlich 13, 17, und 20, die bei uns für notennummern 60, 64 und 67 stehen.

nimmt man die negativen werte noch mit rein, kann man das spiel dann statt mit 30 schon mit 61 noten machen.

für die gesamte MIDI range von 0-127 bräuchte man 64 bit audio, aber auch das geht heutzutage problemlos. oder man nimmt einfach 2x 32 bit signale, dann kommt man immerhin auf 0-122.


das, was du suchst, nämlich fertige geräte, die diese irren scheiß out of the box genau so machen, gibt es natürlich nicht.

aber in max4live oder mit einem 40 euro arduino kit ist es fast ein nobrainer und in einer halben stunde programmiert.

also viel spass damit...

p.s.: ach und die von dir verlangte "exakte sychronität" wird es auch nicht geben, weil jede übersetzung zeit kostet, weil audio immer in vektoren berechnet wird, und weil du, wenn du aus der velocity auch ein signal machen willst, schon 2 vektoren verzögerung brauchst, um die MIDI daten hinterher wieder zusammenzusetzen.

Beitrag automatisch zusammengefügt: 17.06.22

Das ist aber Richtung Pulse-Amplituden-Modulation - nur ohne echte Leitungscodierung.
Klar kann man das einfach mit aufzeichnen, allerdings brauchst du schon ein bissl Elektronik:
- MIDI ist eine Stromschleife, die man mit einem Optokoppler auf einen Pegel umsetzen muss, der dann runtergeteilt auf 0,7V ins Mischpult geht.
- Das MIDI-Signal ist nicht gleichstromfrei, also gibt es ein Bandbreitenproblem nach unten.

der ansatz ist ja auch wirklich quark.

wenn das zielformat ein digitales audiosignal ist, dann ist die elektrotechnische situation irrelevant. man buffert und interpretiert MIDI In mit einem ganz normalen MIDI IN system wie er in jeder device drin ist und führt die daten in einen mikrocontroller.

irgendwelche bandbreiten-, spannungs- oder leistungsfragen stellen sich da nicht, da MIDI digital ist.

Beitrag automatisch zusammengefügt: 17.06.22

Man könnte auch das MIDI-Signal quasi offline im Homestudio in ein Musik-Sample (Audio) umwandeln

das könnte man tun, wenn MIDI ein signal wäre. das ist leider nicht der fall.

 

[einseinsnull]

Wo ist das Problem? Midi Ausgang mit entsprechendem Adapter in einen Eingang, Signal was hochziehen und aufnehmen.

Danach die Audiospur an einem Ausgang ausgeben, wieder runterregeln natürlich, passenden Adapter dran und dann in einen Midi Eingang.

auch das funktioniert nicht. denn was, wenn zwei aufeinanderfolgende hexbtes identisch sind?

 

[Be-3]

an einer stelle spielen wir C-E-G (5) nun gleichzeitig.

Ähm, nur kann kein Mensch aus Fleisch und Blut C-E-G "gleichzeitig" spielen.
Und das MIDI-Protokoll ist doch sowieso seriell, warum dann eigentlich die Mühe mit Gleichzeitigkeit und Binärcodierung?
Quantisierung macht aus "Groove" ein steriles "Jawn".
Oder habe ich etwas missverstanden?

Viele Grüße
Torsten

 

[engineer]

das, was du willst, ginge relativ problemlos in software umzusetzen:

Ich denke, du hast das Problem nicht völlig erfasst. Natürlich kann man das alles in Software lösen aber auch die müsste ja erst einmal geschrieben werden. Was du beschreibst, ist richtig, liefert aber kein bessere Ergebnis, als ein parallel laufender Hardware-MIDI-Rekorder. Denn (s.u.)

das, was du suchst, nämlich fertige geräte, die diese irren scheiß out of the box genau so machen, gibt es natürlich nicht.

a) Wir sollten mal nicht von "irr" und b) nicht von "S...." reden! (Interessante Sprache, die sich hier im Forum in den letzten Monaten und Jahren entwickelt hat)
Denn gibt es in der Tat Lösungen für digitales MIDI ("ES" wurde oben genannt), die genau das fix und fertig tut, weil es den Bedarf gibt und das eine berechtigte Forderung ist. Denn (s.u):

wenn das zielformat ein digitales audiosignal ist, dann ist die elektrotechnische situation irrelevant. man buffert und interpretiert MIDI In mit einem ganz normalen MIDI IN system wie er in jeder device drin ist und führt die daten in einen mikrocontroller.

Das ist genau das Problem! Wenn man buffert und keinen Zeitstempel für die Signale hat (was man so ohne Weiteres eben nicht hat!) dann geht der Zeitbezug zum Audio verloren. D.h. wenn man nicht ein steriles Muster = Pop-Musik-Takt oder Techno aus der Büchse nutzt, sondern ein sich änderndes Tempo mit Beschleunigungen und Verzögerungen verwendet, wie es bei Pianisten Gang und Gäbe ist (siehe accelerando und ritardando) dann kriegst du das im Nachhein nicht mehr zusammen.

Es ist ohnehin ein Problem mit Sequenzern etwas aufzuzeichnen, denn die MIDI-Granularität ist endlich. Man findet derzeit in HW-Senquenzern 480er / 960er Teilungen und die Software ist meist schlechter, weil sie zwar theoretisch sehr viel feiner auflösen kann, infolge fetter MIDI-Buffer und fehlender MTCs aber keinen Zeitbezug mehr hat. Wenn man also Musik dynamisch spielt, MUSS man das sehr eng und zeitnah am Audio haben, wenn das MIDI wirklich das Gespielte abbilden soll. Dies ist vor allem dann nötig, wenn man das Aufgenommene später noch bearbeiten und einsetzen möchte.

irgendwelche bandbreiten-, spannungs- oder leistungsfragen stellen sich da nicht, da MIDI digital ist.

das könnte man tun, wenn MIDI ein signal wäre. das ist leider nicht der fall.

???

Ein Signal (in der offiziellen Interpretation der Signalverarbeitung) ist ein Stück Information und das ist eine MIDI-Note oder ein MIDI-Code mal definitiv. Was du wahrscheinlich ausdrücken möchtest, ist, dass MIDI kein elektrisches Signal ist und deshalb keine Bandbreite enthält. Auch das ist aus zwei Gründen falsch:

a) lassen sich auch nicht-elektrischen Signalen und solchen ohne einen Pegel ein Informationsgehalt zuordnen, der sich (verknüpft mit einer Dichte des Auftretens) in einer Bandbreite ausdrücken lässt.
b) sind elektrische MIDI-Signale ziemlich eindeutig festgelegt, da es praktisch nur eine Protokoll-Spezifikation mit eben jenen 31.250bps gibt und deren Bandbreite kann man aufs Hertz genau berechnen, spätesten wenn man sich die des Optokopplers ansieht.

auch das funktioniert nicht. denn was, wenn zwei aufeinanderfolgende hexbtes identisch sind?

Das funktioniert nicht nur aus diesem Grund nicht. Die Bandbreite eines rechteckigen MIDI-Signals ist einfach zu hoch, um es sauber genug aufzuzeichnen und hernach wieder abzuspielen. Siehe das NRZ-Problem.

Ähm, nur kann kein Mensch aus Fleisch und Blut C-E-G "gleichzeitig" spielen.
Und das MIDI-Protokoll ist doch sowieso seriell, warum dann eigentlich die Mühe mit Gleichzeitigkeit und Binärcodierung?
Quantisierung macht aus "Groove" ein steriles "Jawn".
Oder habe ich etwas missverstanden?

Viele Grüße
Torsten

Dazu: Pianisten spielen Tasten reproduzierbar in Bereichen weniger Millisekunden genau. Auch Schlagzeuger tun das. Man kann einen Akkord ganz langsam, peu a pau in eine Triole schieben und das so genau, dass man es mit rund 10kHz exakt abtasten muss - um es korrekt zu repräsentieren, so meine Beobachtungen und Messungen. Und ja MIDI kann das so genau gar nicht weitergeben. Das normale MIDI wenigstens nicht, siehe die Jitterbetrachtung hier:

http://www.96khz.org/oldpages/limitsofmidi.htm

 

[engineer]

Nochmal zum Thema:

Die Aufgabe ist, das MIDI mit hoher Korrelation zum Audio mitzuschneiden, um es z.B. später abzuspielen und dann ein Audio zu haben, das idealerweise exakt zum aufgezeichneten Audio passt. Das ist wie beschrieben direkt nur möglich, wenn man das elektrische Signal direkt mit aufzeichnet - da hat der TE völlig richtig gedacht. Soweit das gelingt, hätte man dann nur noch einen MIDI-Jitter und ein Delay, das von der Quelle rührt, weil die erzeugte Note ja codiert und als Binärpaket verchickt wird.

Natürlich kann man das MIDI auffangen, es SER-PAR wandeln und hat dann einen Wert von 0 ... 255. Den könnte man mit einem AD-Wandler scannen und als 8 Bit in z.B. 16 Bit verpacken. Dann würde die Audio-Datenrate locker reichen, weil dann ein PCM-Wert mit ca 1/10 der Bandbreite = 3kHz (10 bit je Wert) ankommen würde. Der Jitter wäre dann minimal höher, aber trotzdem im akzeptablen Bereich. Allerdings hat man dann um so mehr das Problem, einen DC-behafteten Wert mit BIAS übertragen zu müssen, weil dann nochgrößere Pausen entstehen, bzw das Spektrum des Signals um eine Dekade nach unten geschoben wird. Einfache ADCs, wie wir sie in unseren Sound-Karten haben, vertragen aber kein DC, sondern schieben das Signal immer in Richtung Mittelpegel. Damit müsste man sich für das 0...255 - Signal auch wieder einen Leitungscode in Richtung NRZ ausdenken, oder braucht eine sehr intelligente Signalverabreitung, damit aus einer 221 nicht ein 220 werden und das Signal vollkommen falsch decodiert wird.

Um solchen Problemen aus dem Weg zu gehen, machen wir es in der technischen Datenübertragung genau umgekehrt: Das Signal wird im Spektrum nach oben geschoben, indem man es scattert oder scrabelt um zu einem kontinuierlichen Datenstrom zu kommen, der weitgehend gleichstromfrei ist. BMC macht das z.B. wie man ihn fürs S/PDIF benutzt und daher hatte ich das auch seinerzeit benutzt, um mein MIDI zu verpacken. Damit kommt man dann auch locker 100m weit und nicht nur 10-15 wie beim MIDI-Kabel mit Stromschleife und das bei 10facher Bandbreite.

Für mich ist das die schlaueste Lösung: Man verwandelt das normale MIDI in ein fast-MIDI, packt es ins S/PDIF ein und verschickt es parallel mit dem Audio-S/PDIF. Der Fehler, der dabei passiert, ist maximal ein einziges Sample, um das ein fertiges MIDI-Bröckchen verpasst wird, wenn der Muliplexer die Kanäle mischt. Bei 4 Kanälen kommen also maximal 3 samples an Jitter hinzu. Im langsamsten System, dass ich gebaut hatte, waren das 3/48kHz.
http://www.96khz.org/htm/midimixmatrix.htm

Inzwischen sind es für 8 Kanäle 7/768kHz = 10us. Das ist ein Bruchteil von einem MIDI-Bit.

Ich hatte eine ähnliche Problematik mal vor rund einem Jahr in der Synth-Edit-Gruppe angeregt und um eine Einschätzung gebeten, wie schnell das damit ginge, weil ich beabsichtige, mein System in DAWs einzubinden und einen Plugin brauche, der MIDI ins Audio verpackt. Ergebnis: Mit der Bandbreite wahrscheinlich gar nicht und wenn, dann auch nur mit Jitter, weil das System asynchron arbeitet und (noch) nicht in der Lage ist, mit geringen Latenzen auf die Hardware zu kommen. Ob das mit einem (anderen) proprietären SW-System in Windows besser geht, sei dahin gestellt.

 

[einseinsnull]

Ich denke, du hast das Problem nicht völlig erfasst. Natürlich kann man das alles in Software lösen aber auch die müsste ja erst einmal geschrieben werden. Was du beschreibst, ist richtig, liefert aber kein bessere Ergebnis, als ein parallel laufender Hardware-MIDI-Rekorder. Denn (s.u.)

ich wollte mir keinesfalls die schräge aufgabenstellung des TE zu eigen machen, ich habe nur beschrieben wie es mit "gate style" signalen theoretisch geht (und ich wie ich so etwas in software löse.)

jedenfalls war die aufgabenstellung des TE irgendwas mit "digitalpult", und da ist eine softwarelösung dann doch praxisnaher wie eine analoge pulse-sonstwas schaltung, denn die ist ja analog.

Denn gibt es in der Tat Lösungen für digitales MIDI

MIDI ist immer digital.

Das ist genau das Problem! Wenn man buffert und keinen Zeitstempel für die Signale hat (was man so ohne Weiteres eben nicht hat!) dann geht der Zeitbezug zum Audio verloren.

das ist aber kein neues problem, was erst bei unseren konvertierungsspiel entsteht.

herkommliche MIDI bearbeitung kommt niemals ohne buffer aus, viele hardware synthesizer haben bis zu 8 ms latenz, und die ursache dafür ist das MIDI protokoll selbst.

das ist also wirklich überhaupt gar nicht vermeidbar.

D.h. wenn man nicht ein steriles Muster = Pop-Musik-Takt oder Techno aus der Büchse nutzt, sondern ein sich änderndes Tempo mit Beschleunigungen und Verzögerungen verwendet, wie es bei Pianisten Gang und Gäbe ist (siehe accelerando und ritardando) dann kriegst du das im Nachhein nicht mehr zusammen.

ich halte das für schlichtweg nicht vermeidbar. MIDI ist seriell, digitale audio signale sind es auch. bei letzteren besteht allerdings kein problem, dinge zu synchronisieren. "sofort und unverzüglich" gibt es auch in einem digitalmischpult nicht.

48 kHz ist nebenbei bemerkt immerhin eine um das 48 fache höher in der zeit aufgelöste übertragung als USB 2.

Es ist ohnehin ein Problem mit Sequenzern etwas aufzuzeichnen, denn die MIDI-Granularität ist endlich. Man findet derzeit in HW-Senquenzern 480er / 960er Teilungen und die Software ist meist schlechter, weil sie zwar theoretisch sehr viel feiner auflösen kann, infolge fetter MIDI-Buffer und fehlender MTCs aber keinen Zeitbezug mehr hat. Wenn man also Musik dynamisch spielt, MUSS man das sehr eng und zeitnah am Audio haben, wenn das MIDI wirklich das Gespielte abbilden soll. Dies ist vor allem dann nötig, wenn man das Aufgenommene später noch bearbeiten und einsetzen möchte.

bei MIDI über DIN - ganz zu schweigen von MIDI über USB ist die ppq auflösung dein geringstes problem.

und so wie ich den TE verstanden habe, will er doch sein midi genau deswegen als audio aufzeichnen, oder nicht? dann besteht nämlich dieses problem nicht mehr. also nicht beim abspielen... beim aufnehmen muss man natürlich abstriche machen.

die aber wie gesagt schon aufgrund des protokolls wohl unvermeidlich sind. bevor du drei aufeinanderfolgende ereignisse als akkord interpretieren kannst musst du immer warten, bis das letzte endlich da ist. das ist die normative kraft des faktischen und genau dafür hat jede midi device einen buffer.

Ein Signal (in der offiziellen Interpretation der Signalverarbeitung) ist ein Stück Information

ein "signal" ist in abgrenzung zu einer nachricht etwas kontinuierliches, was demzufolge einen verlauf hat. über eine DIN MIDI verbindung werden nur einzelne bytes geschickt, ohne feste rate, und ohne dass zwischen diesen nachrichten irgendetwas wäre.

sich den unterschied klar zu machen ist fundamental wichtig, wenn man das eine in das andere konvertieren will.

Was du wahrscheinlich ausdrücken möchtest, ist, dass MIDI kein elektrisches Signal ist und deshalb keine Bandbreite enthält.

es ist auch aus informationstheoretischer sicht nicht das gleiche.

b) sind elektrische MIDI-Signale ziemlich eindeutig festgelegt, da es praktisch nur eine Protokoll-Spezifikation mit eben jenen 31.250bps gibt

das protokoll hat rein gar nichts mit irgendwelchen kabeln und bandbreiten zu tun.

ein protokoll ist ein regelwerk.

MIDI kann seriell, parallel, über USB, die klassischen MIDI verbindungen, über netzwerkprotokolle wie firewire oder TCP IP oder in nichtdiskreter zeit in computerprogrammen versendet und empfangen werden. die daten sind dabei immer gleich.

zu einem "signal" wird das ganze erst, wenn du es als digitales oder analoges audio versendest (also so wie wir es hier diskutieren)

und deren Bandbreite kann man aufs Hertz genau berechnen, spätesten wenn man sich die des Optokopplers ansieht.

was auch immer hertz oder optokoppler nun wieder damit zu tun haben.

Die Bandbreite eines rechteckigen MIDI-Signals ist einfach zu hoch, um es sauber genug aufzuzeichnen und hernach wieder abzuspielen.

das ist ungefähr das, was ich sage, man kann das nicht einfach in irgendeine andere buchse reinstecken und mit einem widerstand die spannung ändern, sondern man muss die daten empfangen und interpretieren, um sie auf eine andere art weiterzuleiten.

wenn er aus MIDI - egal wo es herkommt - digitale audio signale machen will, dann ist das nicht mit dem lötkolben zu lösen, sondern mit datenverarbeitung. und die schnittstelle braucht man nicht selbst bauen, denn die heißt midi controller und gibt es fertig zu kaufen.

oder?

Dazu: Pianisten spielen Tasten reproduzierbar in Bereichen weniger Millisekunden genau. Auch Schlagzeuger tun das. Man kann einen Akkord ganz langsam, peu a pau in eine Triole schieben und das so genau, dass man es mit rund 10kHz exakt abtasten muss - um es korrekt zu repräsentieren, so meine Beobachtungen und Messungen. Und ja MIDI kann das so genau gar nicht weitergeben. Das normale MIDI wenigstens nicht, siehe die Jitterbetrachtung hier:

ich verstehe da echt den zusammenhang nicht ganz.

wenn jemand daten aus einer DIN MIDI verbindung in etwas anderes konvertieren will, sind fehler gegenüber dem erwünschten ergebnis bereits von anfang an vorhanden. das fängt bei einem MIDI keyboard schon mit der abtastfrequenz der tasten an.

jitter in dem sinne hat DIN MIDI sowieso nicht, das problem tritt eher bei USB auf.

und ein pianist, der auf 0,1 millisekunden exakt tasten runterdrückt? die einschwingzeit der saite variert doch schon zwischen 1 und 4 ms.

wer eine unbegrenzt hohe auflösung in der zeit haben will, muss analoge signale nehmen, und zwar von anfang bis zum ende. dafür darf er dann aber auch auf genaue werte verzichten. willkommen zurück in den siebzigern.

 

[engineer]

jedenfalls war die aufgabenstellung des TE irgendwas mit "digitalpult", und da ist eine softwarelösung dann doch praxisnaher wie eine analoge pulse-sonstwas schaltung, denn die ist ja analog.

Exakt, es ist "analog". Das Signal sollte so, wie es kommt, als elektrisches Signal aufgezeichnet werden. Und das wirft eben den Aufwand auf.

MIDI ist immer digital.

Nein, eben nicht. Im Verständnis eines über Kabel übertragen Signals ist es ein analoges Signal, inklusive Pegel, Jitter, Anstiegszeit. All das gilt es zu beachten, wenn man es so "einfach" machen will, wie der TE es angedacht hat. Dass MIDI-Daten intern zuächst digitale Informationen sind, bleibt davon unberührt.

das ist aber kein neues problem, was erst bei unseren konvertierungsspiel entsteht.

herkommliche MIDI bearbeitung kommt niemals ohne buffer aus, viele hardware synthesizer haben bis zu 8 ms latenz,

Es wird aber zu einem größeren Problem, das in Sofware zu machen, weil zusäztliches Buffering notwenig wird. Dass das Gerät an sich schon mit verzögerten Daten heraus kommt, ist richtig, damit muss der TE aber leben und man wird versuchen, die nicht weiter zu vergrößern. Ob das 8ms Latenz sind, muss bestritten werden. Wenn er über ein vernüftiges Masterkeyboard oder ein E-Piano spielt, dann kommt das MIDI-Paket der ersten Taste mit Bruchteilen von ms raus. Eine Übertragung eines MIDI-Tripels braucht dann gerade 1ms. Das ist schon ziemlich akzeptabel, wenn man es in HW verarbeiteten und direkt aufzeichnen würde.

Ich gehe bis dahin komplett mit dem TE dass das eine sinnvolle Option wäre.

 

[engineer]

"sofort und unverzüglich" gibt es auch in einem digitalmischpult nicht.

48 kHz ist nebenbei bemerkt immerhin eine um das 48 fache höher in der zeit aufgelöste übertragung als USB 2.

"Sofort" nennen wir in der Technik "Echtzeit" und "unverzüglich" übersetze ich mal mit "Latenz << Granularität". Beides ist selbstverständlich möglich und wird auch gemacht. Es wird vielleicht nicht in allen Geräten richtig und in vielen sicher (aus Kostengründen = Prozessorleistung) nicht sonderlich gut gemacht, aber es ist technisch überhaupt kein Problem die MIDI-Daten zu scannen und binnen eines Samples zu verbeiten. Selbst mit 48kHz gescannte Daten wären schnell genug. Es geht aber wie beschrieben noch besser:

Meine MIDI Matrix läuft mit 768kHz x 256 , also fast 200MHz und kann folglich 256 MIDI-Kanäle mit eben jener Samplefrequenz erfassen. Splittet man das auf 64 Ausgangskanäle auf, dann bekomme ich aus einem einzigen Multiplexer alle meine 64 möglichen Musik-Kanaäle (die man mit Parts vergelichen könnte) aus jedem der 4 MIDI-Datenströme. Für den Sytth, den Sequenzer und die Ausgangsmatrix laufen insgesamt 4 solche Schaltungen.

Zum USB: Ja, genau. Was vielen nicht klar ist, ist die gewaltige Latenz bei USB, wenn man die Chips konventionell nutzt und nicht künslich zuballert, damit sie senden. Genau deshalb empfehle ich ja seit 20 Jahren für die Echtzeitübertragung von MIDI- eben das S/PDIF zu nehmen. Damit kriegt man alles, was ein MKBD erzeugt in praktiscch Echtzeit übertragen.

ein "signal" ist in abgrenzung zu einer nachricht etwas kontinuierliches, was demzufolge einen verlauf hat. über eine DIN MIDI verbindung werden nur einzelne bytes geschickt, ohne feste rate, und ohne dass zwischen diesen nachrichten irgendetwas wäre.

Da müssen wir aber die Vorlesungsunterlagen nochmals wälzen Praktisch kein Signal in der Technik ist in dieser Weise kontinuierlich - siehe RADAR, LIDAR und auch die Daten aus CPUs. All das verwalten wir aber in FPGAs ganz wunderbar als zeitdikretisierte kontinuierliche Signale. Mithin lassen sich alle Signale die "Pausen" haben nach Fourier in solche kontinuierlichen Signale zerlegen. Ich sehe aber auch nicht das Problem beim MIDI:

Die Diskontinuität der MIDI Daten wirft nur ein Jitterproblem auf, weil nicht sichergestellt ist, dass nach Pausen das neue Paket im ehemaligen Bitzeitraster auftaucht. MIDI ist aber als asynchrones Datenformat definiert und damit per Neusynchronisation erfassbar / zu erfassen.

das protokoll hat rein gar nichts mit irgendwelchen kabeln und bandbreiten zu tun.

ein protokoll ist ein regelwerk.

Natürlich hat es das. Die Ü-Geschwindkeit ist im MIDI-Standard ausdrücklich festgelegt. Ich sagte auch nicht "Das Protokoll läuft mit 31k" sondern dass "eine Protokoll-Spezifikation mit 31k" gibt - und eben nur die "eine". Damit ist indirekt festgelegt, welche physikalsiche Bandbreite das Signal haben wird. Wo ist da was unklar?

zu einem "signal" wird das ganze erst, wenn du es als digitales oder analoges audio versendest (also so wie wir es hier diskutieren)

Genau! Genauer : aus einem theoretischen Signal = Ereignis wird ein elektrisches Signal = Spannung/Strom auf dem Kabel. Und um das geht es hier, denn das ist ja das, was der TE geliefert bekommt. Besser wäre es freilich, er bekäme die Daten als echte Codes in anderer Weise digital übermittelt. So hat er ein anloges Signal mit digitalem Inhalt.

was auch immer hertz oder optokoppler nun wieder damit zu tun haben.

Sie haben genau deshalb etwas damit zu tun, weil er das irgendwie wandeln muss und dafür muss er es gut genug aufgezeichnet habe. Die Soundkarte wird ihm aber eine 20kHz Bandbreitenbegrenzung (oder noch tiefer) aufbrummen, womit er ein recht verkrüppeltes 31kpbs Signal aufzeichnet.

Und wie gesagt: Wegen der "Pausen" und den nicht vorhersehbaren Signalwerten treten da beliebig tiefe Frequenzanteile auf, die deutlich unter das gehen, was die Soundkarte mit ihrer AC-Kopplung noch erfassen kann. Daher bauen wir z.B. wenn wir billige Datenlogger, die im Audiobereich arbeiten können, bauen möchten zwar "normale" AD-Wandler aus der Audiotechnik ein, nehmen aber die BAndbegrenzung raus und koppeln DC.

 

[engineer]

enn jemand daten aus einer DIN MIDI verbindung in etwas anderes konvertieren will, sind fehler gegenüber dem erwünschten ergebnis bereits von anfang an vorhanden. das fängt bei einem MIDI keyboard schon mit der abtastfrequenz der tasten an.

jitter in dem sinne hat DIN MIDI sowieso nicht, das problem tritt eher bei USB auf.

Das ist schon richtig, aber wie gut das Keyboard intern abgetastet wird, wissen wir hier nicht. Ich kenne nur einige Daten der Hersteller und das was ich und andere gemessen haben. Die sind teilweise der Notwendkeit angemessen, teilweise nicht. Legt die Anforderungen eines guten Pianisten zugrunde, der in der Tat so gut reproduzierbar die Tasten drückt, dass sowohl Einsatz als auch Druckverlauf es erfordern, mit einer Genauigkeit von 10kHz abzutasten (jede Taste!!), dann erfüllen nicht viele diese Anforderungen.

Das ist aber noch nicht unbedingt ein MIDI-Problem, denn die Abtastung der Tasten erfolgt bei den typischen elektronischen Keyboards (also nicht nachgerüsteten Klavieren etc) VOR der Klangerzeugung. Das bedeutet, das Keyboard produziert MIDI, das einerseits intern verwertet, andererseits parallel ausgegeben wird. Damit bekommt der MIDI-Prozessor / -Task / -hwardware erstmal genau exakt das, was die Syntheseeinheit bekommt. Damit ist an der Stelle kein Problem.

Es liegt also nur der Zeitbedarf für die Konversion der MIDI-Codes = Taste + Velocity + X vor und dann deren Transmission. Ersteres dürfte / sollte nahe Null sein, entscheidend wären also die 31k. Und ja, die sind beim normalen MIDI bei mehreren Tasten ein Problem.

Bei meinem MIDI nicht!

und ein pianist, der auf 0,1 millisekunden exakt tasten runterdrückt? die einschwingzeit der saite variert doch schon zwischen 1 und 4 ms.

Das hat aber damit gar nicht zu tun. (?) Einschwingen der Saiten wäre etwas, was eine Klangsynthese NACH Empfang der MIDI Daten vorllzieht und auch ein MIDI-fiziertes Klavier würde sofort nach Interpreation des Beginns der Taste einen Code absetzen, den nächsten nach Erreichen des Punktes 2 in der Velocity-Kennlinie / bzw des physikalischen Messpunktes 2 und dann einen dritten nach Erreichen das Tiefpunktes, gerechnetem Velocity und dann den Aftertouch. Das passiert alles mit 1ms Verzögerung, wenn man es richtig macht. Von einem Hersteller, der Klebetasten für Pianos vertreibt, um selbige mit weiteren Ausdrucksmöglichkeiten zu versehen, weis ich, dass er mit 5kHz abtastet und mit Mikrosekunden Verzögerung beginnt zu senden.

P.S. die 10kHz, die ich immer angebe, wenn ich über die nötige Samplequalität bei Pianisten spreche, meinen nicht, dass er eine Taste in 0,1 ms drückt. Das dauert mehrere 10ms. Es geht um den Druckverlauf, während der Zeit, die er die Taste bewegt und während der das Gegenmoment der Hammermechanik wirkt. Um diesen -> analogen Druckverlauf gut genug abzubilden, braucht man nach meiner Einschätzung bei 7-Bit MIDI wenigstens 10kHz. Der Tastendruck bei schnellem Spiel wird dann mit etwa 20-30 Punkten aufgezeichnet, womit man "unterwegs" schon die Geschwindigkeit recht genau rechnen kann. Mit einem genaueren Erfassungsystem 10,12 Bit ginge auch weniger.

Sehr viel weniger sollte es aber nicht sein, weil man dann den Beginn der Taste nicht mehr so genau mitbekommt. Die Variation in der Geschwindigkeit beim Klavierspiel beträgt auch binnen weniger Akkorde mal 20-30%, wenn man beschleunigt und ausgehend von z.B. 120 bpm steigert sich die Zahl der Tastenbetätigungen bei z.B.16teln so, dass die Zeitverläufe von 40ms auf 30ms ändern. Will man das nachvollziehen, ist z.B. 1kHz Auflösung einfach zu knapp und am Rande der Genauigkeit. Es gibt da noch mehr Sachverhalte, die mich an den 10k festhalten lassen. Das ist auch elektronisch kein Problem, Tasten und ihre paar Sensoren analog zu multiplexen. 96 Tasten x 4 Sensoren sind nicht mal 4 MHz. Ein einzelner Analog-MUX packt aber das 5 fache.

Man darf bei der Betrachtung auch nicht vergessen, dass elektronische Orgeln oftmals voll parallem gespielt haben!

Im Übrigen braucht auch der Aftertouch beim KBD einiges an Auflösung, wenn er funktionieren soll.



Die