Gibt es ein textbasiertes standardisiertes Zwischenformat zum binären MIDI?

[M15064]

Wer diese Programme nutzen kann und möchte, soll sie nutzen. Wer für die Programmiersprache seines Vertrauens eine entsprechende Erweiterung verfügbar hat und sich nicht erst da einarbeiten, deren Unzulänglichkeiten verstehen und darum herumarbeiten muss, prima. Hat oder will man aber nicht immer, da es unpraktikabel sein kann: In den frühen Stadien möchte man einfach den Output eines unfertigen Programms zunächst visuell überprüfen.
...

In der Zeit die du hier für Grundsatzdiskussionen investierst hätte ich in jeder meiner Lieblings-Programmiersprachen einen MIDI-IO-Parser geschrieben, der 98% der MIDI-Syntax abdeckt (und für den Rest müsste man mal schauen ob man es überhaupt braucht).
Und zur visuellen Überprüfung des Outputs gibt es Logger, das ist (je Datentyp) eine Zeile im Code, die jeder vernunftbegabte Entwickler ohnehin reflexartig einbaut.

Für mich klingt das Ganze hier wie der vergebliche Versuch, das Rad neu zu erfinden, bevor man sich mal kundig gemacht hat, wie viele verschiedene Sorten an Rädern es bereits gibt.

Hinzu kommt: Die MIDI-Spezifikation wurde von Leuten durchdacht, so wirklich durchdacht, bis zum (jeweils zu der Zeit bekannten) Ende ... mit Erfahrung und so.
Sich da einarbeiten heißt, von Anderen lernen.
Das nochmal von vorne anfangen heißt, Erfahrungen Anderer ignorieren und in Fallen tappen.

Nerdkomfort heißt, Dinge abzulehnen

Dann verhalte ich mich deiner Idee gegenüber mal nerdkonform und lehne sie ab.

 

[ssssssssssss14316]

@MoogelPackung
Daumen mit Widerwillen Aber wir wissen ja nicht so ganz genau, worauf der TO hinaus möchte, und warum, oder? Im Übrigen ist die alte MIDI Spezi auch veraltet, sonst käme keine 2.0 ...

 

[GegenKlang]

vielleicht bin ich völlig am Thema vorbei, aber es gibt doch viele Ansätze Musik textbasiert zu beschreiben... C-Sound, Super Collider etc...

Du bist nicht am Thema vorbei, du lehnst an der Leitplanke. Genau solche Musikbeschreibungssprachen benutz ich ja, genau genommen meine eigene. C-Sound und SuperCollider sind mir leider zu wenig selbst gemacht, ihre Unzulänglichkeiten (diese Imperativität ist nicht so mein Fall) schreien geradezu danach, mit selbstverbrochenen Unzulänglichkeiten ersetzt zu werden.

Für mich klingt das Ganze hier wie der vergebliche Versuch, das Rad neu zu erfinden, bevor man sich mal kundig gemacht hat, wie viele verschiedene Sorten an Rädern es bereits gibt.

Ach, der Versuch ist relativ erfolgreich. Ist ja im Prinzip ein Logger, der lediglich so konzipiert ist, dass der Output an einen Zu-MIDI-Konverter z.B. übergeben werden kann. Was auf den Logging-Output, den es schon immer gab, nicht zutrifft. Und wenn es einen Zu-MIDI-Konvertierung geben soll, warum nicht auch eine von MIDI? Voilà, da haben wir sie dann, eine neue Sprache. Die vielen anderen Sprachen waren mir genau so wenig standardisiert / verbreitet. Absurd wär die Eigenentwicklung gewesen, wenn ich gegen einen Platzhirsch anprogrammiert hätte. Den gibt es nicht, MIDI ist binär.

 

[GegenKlang]

Aber wir wissen ja nicht so ganz genau, worauf der TO hinaus möchte

Tja, offenbar bin ich nicht so gut im Erklären. Habe mein bestes gegeben. Quintessenz des Thread ist also, es gibt keine anerkannte Textversion vom binären MIDI-Protokoll, mit der Soft- oder Hardware von größeren Herstellern etwas anfangen könnte. Das wollte ich wissen. Thread kann zu.

 

[Max]

Google sagt, dass es da wohl schon eine ganze Menge gibt, sowohl mit XML, JSON als auch CSV...

XML - viel Overhead & Redundanz, verwendet man eigentlich nur noch aus historischen Gründen oder "in begründeten Ausnahmefällen"
JSON - schlank und leichtgewichtig, der absolute Standard für Web-API's
CSV - einfacher geht's nicht...

Nachdem ja MIDI keinerlei strukturierte, also ineinander "verschachtelte" Datenstrukturen verwendet, halte ich eine Lösung in Richtung CSV am sinnvollsten: leichtgewichtig und effizient bei bester Menschen- und Maschinenlesbarkeit

 

[GegenKlang]

Ja, CSV ist key, ist halt ein Metaformat, wie XML und JSON auch. Das heißt, ob du in CSV MIDI oder deine Socken beschreibst, ist dem Format egal. Und wenn du CSV mit dem einen Tool schreibst, kann es ein anderes Tool wahrscheinlich nicht lesen. Das wäre für mich ein Standard.

Okay, gibt es des halt nicht. Brau ich halt halt mein eigenes Zeug, schon in Ordnung. Und bin auch nicht in Rechtfertigungsnot, warum ich den Prozess zweiteile, Sompyler Score -> Zwischenformat MIDI-Text und MIDI-Text zu MIDI.

 

[4t6ßweuglerjhbrd]

Die Argumente für JSON vs XML überzeugen.
Beide scheinen aber auch nur bedingt geeignet zumal MIDI ja ein Datenstrom ist aus weitgehend gleichförmigen Daten.

Ich würde aber dennoch weiter schauen ob es nicht doch irgend einen Standard gibt auf dem man aufbauen kann.

 

[4t6ßweuglerjhbrd]

Es gibt tatsächlich einen XML SGML Standard: SMDL, offenbar sogar ISO Norm

SGML: SMDL Overview

 

[4t6ßweuglerjhbrd]

ausserdem gibt es einen Vorschlag für eine "Practical Music Macro Language" https://quod.lib.umich.edu/cgi/p/po...c.pdf?c=icmc&format=pdf&idno=bbp2372.1998.312

 

[einseinsnull]

Was mich betrifft, ich bin ein Fan von Textformaten. Textformate können relativ einfach mit relativ einfachen selbst entwickelten Programmen bearbeitet werden. Sobald Binärformate ins Spiel kommen, braucht der geneigte Enrwickler schon ne Ausbildung oder macht sich halt abhängig von fertigem Code.

da es m.w. kein solches format gibt und du es daher die übersetzung von und zu midi datei formaten selbst machen müsstest, ist es vermutlich egal davon abhängig zu sein.

mich nervt die nichtlinearität auch schrecklich, aber im gegensatz zu manch anderem ist midi wenigstens gut dokumentiert.

"lese bytewise bis du xyz findest, das nächste byte ist dann der typ, die folgenden beschreiben dann die geschwindigkeit, die auflösung, und die trackanzahl" usw., und dann folgen die tracks, und die haben dann so 7 oder 8 verschiedene datentypen, die auch alle mit einem byte anfangen, so dass man sie danach sortieren kann, das ist doch noch relativ gut handlebar.

delta zeiten in zeitpositionen und zurück umrechnen ist auch keine schwere übung.


zum tema text: text ist ja letztlich nur eine bestimmte darstellungsform. wenn man will, dann kann man auch eine binärdatei so strukturieren, dass das zeug halbwegs lesbar ist. das wollten die halt nur nicht, die hatten wohl spas daran die dinge möglichst kryptisch zu machen.

der größere mist bei MIDI ist nicht nur, dass das alles hex ist, und dass es keine ordnung in diesem system zu geben scheint, sondern das du es dort mit blödsinn wie MPE, key pressure oder showroom control zu tun hast, die im grunde genommen propietär sind und dann von den herrschern des systems aber zum allgemeinen standard erklärt wurden.

 

[einseinsnull]

Hinzu kommt: Die MIDI-Spezifikation wurde von Leuten durchdacht, so wirklich durchdacht, bis zum (jeweils zu der Zeit bekannten) Ende ... mit Erfahrung und so.
Sich da einarbeiten heißt, von Anderen lernen.

ist das noch wunschdenken oder schon opportunismus?

alleine dieser rpn/nrpn dreck ist doch vollkommen obskur und idiosynkratisch und entbehrt jeder inneren logik, so dass einem bleibt, dass alles auswendig zu lernen oder nachzuschlagen.

gleichzeitig lässt der standard seinen anwendern oft viel zu viel freiheit, so dass jedes gerät die dinge wieder ein bischen anders macht.

 

[recliq]

Music markup languages

MML (Music Markup Language). This document contains the background of MML.

steyn.pro

 

[einseinsnull]

Mich würde das auch interessieren, wie das MIDI Protokoll als Programm Code aussieht.

das protokoll (vor allem der physischen schnittstelle) ist das eine, das andere ist das dateiformat.

im grunde genommen ist eine midi datei ähnlich aufgebaut wie die meisten binären dokumente, vorne wird erst mal beschrieben, was es ist und was hinten alles drin ist oder auch nicht, und dann kommt der inhalt möglicher spuren, also noten, controller und das gedöns.

hex bytes (erste spalte) sind der "normale" weg dateien zu beschreiben, weil man sie üblicherweise nur in der form lesen, schreiben und verarbeiten kann, nämlich in abschnitten von 1, 2, oder 4 bytes.

dann in der mitte das ist die binäre darstellung; so liegen die daten tatsächlich auf der festplatte oder im RAM vor.

und hinten das ist dann die darstellung als textzeichen. wie man erkennt, kann man damit bei einer midi datei fast garnix anfangen, weil es nicht für alle binären werte überhaupt ascii zeichen gibt.

weswegen hier der wunsch nach übersetzung zu text besteht, die erst mal einer interpretation solcher daten bedarf.


ganz konkret sieht das dann z.b. so aus, dass hier alles hinter "MTrk" - für uns, die wir nicht flüssig hex lesen können - als dezimalzahlen dargestellt werden müsste, von denen dann wieder jeder eine bestimmte bedeutung hat, z.b. "144 60 0" ist dann "mittleres C auf kanal 1 wieder loslassen" - das ist das, was über das midi kabel zwischen den kisten verschickt wird.

vor jeder dieser sächelchen steht dann noch dabei, um wieviel später dieses sächelchen nach dem vorgehenden sächelchen abgespielt werden soll, in absurden zeitauflösungen (die man ohne taschenrechner nicht umgerechnet bekommt.)

 

[einseinsnull]

Die Argumente für JSON vs XML überzeugen.

er benutzt python und ich persönlich finde, dass json relativ unlesbar ist, zumal mit dem umbruchsgedöns.

ganz gewöhnlicher fließtext kann viel leichter einfach als eine art tabelle benutzt werden.

 

[M15064]

... alleine dieser rpn/nrpn dreck ist doch vollkommen obskur und idiosynkratisch und entbehrt jeder inneren logik ...

Daran dachte ich schon beim Schreiben, aber ich baue gerade einen MIDI-Dispatcher und schaue hier immer nur kurz zwischendurch rein und da dachte ich mir, soll sich doch ein Anderer mit dieser "bahnbrechenden" Erkenntnis profilieren.

 

[GegenKlang]

@reqliq, danke für die Liste. Seit 2000 ist allerdings sxhon ne Zeit vergangen. Egal.

Allein, die Nähe zu MIDI steht bei diesen Sprachen auch nicht gerade hoch im Kurs. So gesehen bilden sie auch keine Brücke zu meinem Ziel, MIDI zu generieren oder in Textform zu gießen. SDML/MML suche ich nicht, hab ja schon eine solche als Ausgangsmaterial. Eine MIDI-Event-ML, das wärs. Aber ich glaub jetzt auch, das hat einen Grund. Nein, keine Weltverschwörung sehe ich darin. Mehr die traurige Tatsache, dass ich der einzige Texteditorenfanatiker mit Musikmachneigung unter der Sonne bin, und ich als einziger Vertreter meiner Zielgruppe kaum erwarten kann, dass es einen entsprechenden Standard gibt. Bitte kurz mal Mitleid mit mir haben, danke.

 

[EF7XLHH7BV]

Ist Midi denn nun binaer ? hexadezimal ? sedezimal oder doch dezimal ? ich bin verwirrt - 8 Bit ? signed Word oder unsignet Longword

 

[4t6ßweuglerjhbrd]

Bitte kurz mal Mitleid mit mir haben, danke.

Sieh es als Chance - du kannst jetzt einen Standard definierem.

Eine seltene Gelegenheit die große Verantwortung mit sich bringt.

 

[einseinsnull]

Daran dachte ich schon beim Schreiben

ich wollte das nur "ergänzen", weil du ja immerhin, obwohl du auch dran gedacht hast, das genaue gegenteil davon gesagt hast.

wenn man bedenkt, dass MIDI nicht gerade von sehr großem umfang ist, ist es dafür dann doch schon relativ chaotisch aufgebaut. das ein oder andere mag historisch bedingt sein, aber linear und schlüssig ist echt was anderes.

und als interchange format zu was anderem taugt es sowieso nicht, weil ja alles modernere förmlich nach einer höheren auflösung schreit.

wenn ich noten von max nach cubase transportieren will, dann mache ich mir ein VST plug-in, was mein eigenformat lesen kann, dann hab ich float.^^
alles andere wäre mehr arbeit und bietet mehr fehlerquellen. die foren dieser welt sind doch voll mit geschichten über "hilfe, ich habe midi aus A in B geöffnet und jetzt stimmen die BPM nicht mehr"... ein sinnvolles, klar strukturietes datenformat würde so etwas niemals zulassen.

so, rant fertig.

 

[einseinsnull]

Ist Midi denn nun binaer ?

binär ist alles irgendwie, sobald ein PC ins spiel kommt, der das abspeichert oder verarbeitet.

hexadezimal ? sedezimal oder doch dezimal ? ich bin verwirrt - 8 Bit ? signed Word oder unsignet Longword

immer signed, ((8/16/32 bit bzw. dbyte/long/word oder nenns wie du willst) jedoch mit dateninhalt von unterschiedlicher länge... 2, 4 oder 8 bytes, also wenn du nur 3 brauchst musst du eins frei lassen, und bei sysex z.b. auch gerne unbegrenzt lang.

zum suchen/spoolen immer in byte offsets denken und alles ist gut.

 

[M15064]

und als interchange format zu was anderem taugt es sowieso nicht, weil ja alles modernere förmlich nach einer höheren auflösung schreit.

MIDI ist halt aus Zeiten, als man mit Datenrate noch haushalten musste.
Heute beobachtet man eher das Gegenteil, es wird angeboten was das Limit des technisch Möglichen ist ... und für die Lobpreisung der völlig irrelevanten "Verbesserungen" sorgen dann schon die mit den Gold-Ohren.

Und dass es als Interchange-Format nicht taugt hängt vor Allem auch damit zusammen, dass Vieles was in DAWs wichtig und Kern der Funktionalität ist, in MIDI überhaupt nicht enthalten sein kann, weil nicht standardisierbar, weil in jeder DAW anders realisiert.

 

[einseinsnull]

was letztlich aber nur beweist, dass es monopolist ist. es kann also nicht alles falsch gemacht haben.

 

[GegenKlang]

Sieh es als Chance - du kannst jetzt einen Standard definierem.

LOL - aber erster Tagesordnungspunkt ist Mammut reiten. Dann release ich eben mal PlainMIDI-Text 1.0 - Got MIDI right. Und wenn dann noch Zeit ist und ihr fein artig seid, rette ich noch die Welt.

Ne, also nen Standard entwickel ich alleine bestimmt nicht. Bin ja kein Normierungsamt. Mein Ansprechpartner ist python3-mido, auf den verlasse ich mich, und das textbasierte Zwischenformat wird womöglich genauso unportabel wie csv2midi oder so, da mach ich mir nix vor, hab ja noch auf unzähligen anderen selbstverkorksten Hochzeiten zu tanzen. Vielleicht nehmen meinen Impuls andere auf, mehr kann ich nicht erwarten.

 

[Max]

du musst ja nicht gleich alles implementieren, wenn du erstmal nur Noten und Controller brauchst ist das doch in 5 min gemacht...

Beispiel Noten: [Zeit] [Kanal] [Befehl] [Note] [Velocity]

103 1 NoteOn G3 108
180 1 NoteOn E3 77
402 1 NoteOff E3 0
407 1 NoteOff G3 0
...

 

[einseinsnull]

Ne, also nen Standard entwickel ich alleine bestimmt nicht. Bin ja kein Normierungsamt.

fang einfach mal an damit, dann wirst du schnell merken, dass es nicht schwierig ist.

wenn du dich einfach auf 16 kanäle, noten, controller und von mir aus MTC beschränkst, dann ist das keine 30 minuten arbeit, selbst wenn du byteweise ausliest anstatt einen existierenden midi import parser für deine umgebung zu benutzen.

das schwierigste daran ist sich zu entscheiden, was das eigenformat überhaupt leisten soll.

also z.b. ob du eine struktur mit 16 getrennten kanälen schaffen willst, oder ob du alles in einer liste darstellen und den kanal als attribut den ereignissen zuordnen willst.

 

[einseinsnull]

okay, da war jemand schneller!

 

[einseinsnull]

MIDICSV: Convert MIDI File to and from CSV

MIDICSV: Convert MIDI File to and from CSV

www.fourmilab.ch

MIDI in lesbaren Text konvertieren

mtrk(1) // track 2
/* U0 */ /* 0ms */ trackname "More strings at Refrain"
/* U0 */ /* 0ms */ program Ensmble1
/* U0 */ /* 0ms */ volume 127
/* U0 */ /* 0ms */ balance 46
/* U0 */ /* 0ms */ reverb 52
/* U0 */ /* 0ms */ chorus 65
7765; /* U7765 */ /* 34085ms */ +a4 $58;
42; /* U7807 */ /* 34269ms */ -a4 $40;
11; /* U7818 */ /* 34318ms */ +a#4 $52;
44; /* U7862 */ /* 34511ms */ -a#4 $40;

das meiste, was man so findet, macht die daten fast noch schlechter lesbar wie ein hex editor.

 

[GegenKlang]

fang einfach mal an damit, dann wirst du schnell merken, dass es nicht schwierig ist.

wenn du dich einfach auf 16 kanäle, noten, controller und von mir aus MTC beschränkst, dann ist das keine 30 minuten arbeit, selbst wenn du byteweise ausliest anstatt einen existierenden midi import parser für deine umgebung zu benutzen.

Wenn ich schlampig arbeite und einfach mal drauf los, habe ich in 30min ne Datei, die im Hexeditor nach MIDI ausschaut, ja. Ob sich der Content auch nach Musik anhört, wenn ich mich bei der Berechnung der Deltazeiten (Midi-Ticks lt. Clock) aus den Sekundenwerten vertan habe im Eifer des Gefechts, ist eine andere Frage.

Wer sich den vollständigen Miditext von meinem Beispiel im Eröffnungspost anschaut und runterscrollt, wird vielleicht erkennen, dass es bald so einige Tempoänderungen gibt. Die Tempoänderungen beziehen sich nur auf die Noteons- nicht auf die Note-offs. Weitere Probleme hab ich ja weiter oben erläutert. Aber so wird es in der Pianoroll eines MIDI-Editors eben ziemlich hässlich aussehen. Shit in, shit out.

 

[fanwander]

Ich kommentier mal ein paar Sachen.

Und wo ist da der Mehrwert gegenüber MIDI?

In der Lesbarkeit. Finde einen Fehler im Mailheader einer im outlook *.msg-(=binär)-Format raus und im Thunderbird'schen *eml-(=ascii)-Format.

+ richtiger Editor

Wenn ich einen "richtigen Editor" nehmen kann, dann kann ich auch gleich die Eventliste in Logic Pro nehmen...

Der Trick ist schon die Unabhängigkeit von der bearbeitenden Applikation.

ihre Unzulänglichkeiten [=die fremder Programme] schreien geradezu danach, mit selbstverbrochenen Unzulänglichkeiten ersetzt zu werden.

alleine dieser rpn/nrpn dreck ist doch vollkommen obskur und idiosynkratisch und entbehrt jeder inneren logik

Wieso? NRPN entspricht der klassischen seriellen Computerdatenübertragung schlechthin: erst die Adresse, dann die Daten.

das schwierigste daran ist sich zu entscheiden, was das eigenformat überhaupt leisten soll.

Sehr wahr.

Wie leider so oft, übertüncht die Begeisterung für das Werkzeug, den Mangel an sinnhafter Verwendung. Ich denke, dass @Neusiker s ironische Anmerkung zum ersetzen mit eigenen Unzulänglichkeiten, genau das erkennt.

 

[4t6ßweuglerjhbrd]

Was man an MIDI (Protokoll meine ich) kritisieren kann ist die recht geringe Parameterauflösung in manchen Fällen (wobei man da ja drumrumkommt)
und die relativ niedrige Datenrate (wobei die musikalisch weitgehend ausreichend ist) sowie die relativ geringe Anzahl an Kanälen
(wobei 16 schon recht viel sind wenn man sich das als Big Band vorstellt).

Wenn man dabei berücksichtigt daß es das war was damals ohne Raktenwissenschaft ging und der 8-Bit Heimcomputerboom erst noch bevorstand (und u.a. durch MIDI befeuert wurde) ist es nicht schlecht und macht immer noch was es soll.

Daß es immer noch Standard ist hat natürlich viele Gründe und einer ist daß es in Hardware verbaut ist die genutzt wird.
Ein anderer ist aber daß ein paralleler Standard wenig Mehrwert bei großem Aufwand bedeuten würde
und serh unegwiss ist was er leisten können soll.
Sollte der auch gleich Multi-Channel Audio streamen? Evtl sogar Video? Wäre Heutzutage ja denkbar.
Daneben wird MIDI auch noch für off--label Anwendungen wie Lichtsteuerung benutzt.

Nicht umsosnt setzen manche Lösungen die über den MIDI Standard hinausgehen dennoch auf MIDI als untreliegendes Protokoll.

Anders gesagt: das Format hat von Anfang an ein "Fenster in die Zukunft" aufgelassen und ich glaube das ist die eigentliche Stärke des Formats.

Es gibt ja Gründe warum MIDI 2.0 seit wieviel Jahren oder Jahrzehnten nicht vorankommt.