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

[einseinsnull]

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

klassisch? adresse?

du hast 127 controller, von denen du nur 121 also solche nutzen kannst, weil die anderen 6 was anderes machen.

davon sind im prinzip nur die ersten 32 definiert und die zweiten 32 nicht, so dass man nur diese ersten 64 - aber mit ausnahme der 6, bei denen man es doch nicth soll, zu 14 bit controllern zuammenfügen kann, wobei das auf mindestens 2 verschiedene arten gemacht werden kann, und dann hält sich nicht mal jeder dran.

die restlichen 57-61 stehen im prinzip unter vorbehalt von roland mit seinem GM scheiß, wobei GM devices wiederum dazu verplfichtet sind mindestens 16 davon auch zu benutzen.

und kein normal denkender mensch weiß warum das so ist und niemand kann sich das merken.

und dann lsb/msb. wozu um gottes willen? man hätte genauso gut den zweiten controller als offset multiplikator nehmen können. oder man könnte die zwei werte als fixed point interpretieren. wäre beides einfacher gewesen.


mit nrpn passieren so lustige sachen wie das hier: im kemper amp manual steht, 98/99 wäre msb/lsb, in der anleitung von logic hingegen steht es wäre umgekehrt. man probiert also beides - und beides scheint nicht zu gehen. geil oder?

Ich denke, dass @Neusiker s ironische Anmerkung zum ersetzen mit eigenen Unzulänglichkeiten, genau das erkennt.

das unterscheidet unsereins nicht von der industrie. industriestandards sind auch immer nur aus subjektiver sicht möglichst generisch angelegt.

dadurch wird das bedürfnis es lieber selbst schlecht zu machen ja oft erst erzeugt.

 

[4t6ßweuglerjhbrd]

Ach so und: der Siegeszug der elektronischen Musik wäre ohne MIDI undenkbar.

 

[einseinsnull]

Die Tempoänderungen beziehen sich nur auf die Noteons- nicht auf die Note-offs. Weitere Probleme hab ich ja weiter oben erläutert.

ich kann dir versprechen, dass wenn du nur lange genug darüber nachdenkst, du immer an einem punkt schließlich zu dem ergebnis kommen wirst, dass du in deiner eigenen software am liebsten gerne beides hättest: note off events und note events mit einem duration wert gleich dabei.

das ist bei so einem textformat genau wie bei jedem anderen eigenformat eine der entscheidungen, die man zu treffen hat, mit oder ohne note off - oder beides.

eigentlich gehe ich bei dir davon aus, dass physisches MIDI nicht dein hauptziel ist. da bietet sich das modell "duration" eigentlich an. das lässt sich immerhin einfacher wieder in MIDI verwandeln als umgekehrt.

 

[fanwander]

Das NRPN Thema ist zwar hier offtopic, aber...

im kemper amp manual steht, 98/99 wäre msb/lsb

...was hat die Faulheit von Herrn Kemper in der MIDI Spezifikation nachzusehen ( ) mit der Qualität und nicht Qualität von NRPN zu tun.

Und was haben die per Spezifikation festgelegten Fest-Definitionen und ebenso spezifizierten Nicht-Definitionen der RPNs mit den NRPNs zu tun?

NRPNs sind exakt ein Funktion im Bereich der RPNs, dass sich hinter der Funktion die Möglichkeit verbirgt, 16384 weitere Funktionen zu kontrollieren, hat doch nichts mit der Qualität der RPN-Definitionen zu tun, und ist ganz sicher noch weniger ein Defizit der NRPNs selbst.

 

[audiot.]

Spoiler: (Randbemerkung aus der Sicht eines SW-Entwicklers)

Hier geht es dem Threadersteller zwar "irgendwie" um Python, aber:
Warum werden hier Daten roh und auf komplizierteste Weise betrachtet (und diskutiert), wenn doch dafür geeignete Frameworks existieren, die ein ganz anderes Abstraktionsniveau böten? Aus "Nerdstolz"?
Hier, z.B. sowas - exemplarisch und längst implementiert:

Java Sound - Midi

Ich könnte mir durchaus vorstellen, daß ähnliche Frameworks auch für Python der C existieren (ist nicht meine "Kernkompetenz").

=> MIDI Daten 'rein und via Framework wieder 'raus sollte eigentlich kein Hexenwerk sein - und in welche (Text-/non-Binär-)Form auch immer (ich würde hier XML bevorzugen - alleine schon wg. DTD/Validierung/Typsicherheit) - JSON ist 'was für Frontend-Hipster
=> die rohen Daten zu betrachten, um da "irgendwie" etwas daraus zu extrahieren damit das in irgendein proprietäres selbst ausgedachtes "Text-Etwas" landet hört sich für mich nach fehlerträchtiger Frickelei an (wie will man das testen? Ein Framework hingegen sollte/muß gestestet sein)
=> hier wird meinem Dafürhalten nach krampfhaft versucht, irgendein bereits vorhandenes Rad neu zu erfinden. Dafür wäre mir meine persönliche Lebenszeit zu schade und gehe deshalb lieber in Villa Bajo feiern, während in Villa Riba noch gespült wird

 

[einseinsnull]

Das NRPN Thema ist zwar hier offtopic, aber...

...was hat die Faulheit von Herrn Kemper in der MIDI Spezifikation nachzusehen ( )

als ob er das selbst programmieren würde

nein aber solche fehler entstehen, weil es eben so umständlich ist.

ein gesunder mensch würde in seinem protokoll einfach von vorneherein zwischen 7 und 14 bit controllern unterscheiden, und neben einem control change befehl noch einen control change 2 befehl einbauen. diese hätte dann automatisch immer 3 bytes und man könnte seine aufmerksamkeit wieder anderen dingen widmen.

NRPNs sind exakt ein Funktion im Bereich der RPNs, dass sich hinter der Funktion die Möglichkeit verbirgt, 16384 weitere Funktionen zu kontrollieren, hat doch nichts mit der Qualität der RPN-Definitionen zu tun, und ist ganz sicher noch weniger ein Defizit der NRPNs selbst.

mama, der will mich nicht verstehen!

es geht doch nicht um die eine funktion, die ich oben beschrieben habe, sondern darum, das das gesamte system in theorie und praxis völlig chaotisch ist.

es fängt doch schon damit an, dass die 32 hauptamtlichen NRPN control change nummern ja eigentlich genau dafür gedacht sind, dass man sie für propiertäre zwecke einsetzen können soll - du kannst dir jederzeit auch aus vieren davon einen 28 bit wertebereich bauen wenn du willst - oder die wertebereiche von 4 controller nummern zu einem 10 bit wertebreich aufakkumulieren - es dann gleichzeitig aber diverse vorgaben und vorschläge dafür gibt, wie sie "richtig" zu benutzen sind.

ja was denn nun? sind die frei zu benutzen oder soll man sich nach vorgaben richten?

das ist in sich hochgradig widersprüchlich.

von der verrückten idee, dass man dann controller 99 dafür benutzen soll, andere controller quasi zu definieren und von solchem zeugs wie alle notes off mal ganz abgesehen.


für jeden, der eine device machen will, die gut in ein bestehendens, durchschnittliches setup passt, bedeutet dass, dass er am besten als controller nur 65-97, 101-121 usw (oder so ähnlich) dafür benutzt. sowas geht mir erheblich auf den keks, denn wir normale menschen fangen eigentlich bei 1 an zu zählen.

oder bau mal einen einen router, der zutreffend zwischen controller 99 mit und ohne darauf folgende 14 bit controller unterscheiden kann.

das macht alles so viel überflüssige mehrarbeit...


woanders hatte ich das schon mal erwähnt: bei MIDI gibt es 128 presets aber bank select ist dann 14 bit. kennst du ein gerät mit mehr als 8 bänken? wer braucht davon 65000? man schaut sich das an und hat nach 5 minuten keine lust mehr auf das system.

 

[fanwander]

mama, der will mich nicht verstehen!

Richtig Aber echt nur wegen OffTopic

woanders hatte ich das schon mal erwähnt: bei MIDI gibt es 128 presets aber bank select ist dann 14 bit. kennst du ein gerät mit mehr als 8 bänken? wer braucht davon 65000? man schaut sich das an und hat nach 5 minuten keine lust mehr auf das system.

Ich hab hier MIDI-steuerbare Präsentations Bild und Video Player, bei denen würde eine 7Bit-Addressierung für den Bankselect nicht genügen...

 

[GegenKlang]

ich kann dir versprechen, dass wenn du nur lange genug darüber nachdenkst, du immer an einem punkt schließlich zu dem ergebnis kommen wirst, dass du in deiner eigenen software am liebsten gerne beides hättest: note off events und note events mit einem duration wert gleich dabei.

Nun ja, das habe ich ja auch, wenn auch die Duration im Kommentar versteckt: Released in (3, 2, 1 - ) 0.0879334s. Die kann ich noch richtig(er)
formatieren mit "# ..., Duration: 0.088s" - und fertig ist die Laube. Was hinter dem Lattenzaun steht, sind tatsächlich mehr so Metadaten zum Note-On-Event, die mehr für den menschlichen Entwickler sind, den Konverter interessiert das schon nicht mehr, von MIDI-Empfängern ganz zu schweigen.

Mir selber angeregt vor einigen Posts, aber übrigens wieder verabschiedet hab ich mich derweil von der Unterscheidung der Hold- und Sustain-Länge (Teil der Dauer, die die note den gehobenen Dämpfern am Klavier verdankt). Die krieg ich nicht (elegant) ermittelt aus dem Ausgangsformat. Hat man zahlreiche aufeinander aufbauende Verarbeitungsebenen, will man nicht alle Details aus den tieferen Schichten durch die höheren routen, wenn das Verhältnis des Aufwands bzw. der Einschränkung der Einfachheit/Robustheit des Codes zum Nutzen nicht gut ist. Nicht für die Midi-Textausgabe und die Konvertierung, zumal nur ein Teil der MIDI-Empfänger (etwa Pianoteq) sich überhaupt um die Werte für ein Sustain-Pedal scheren dürfte. Auch MIDI

Seht ihr, deshalb mag ich das keinen Standard nennen, diese Brut von Kompromiss und Silodenken und dem Drängen nach der Überwindung desselben. Ein Standard wird nur dann unter mehreren Parteien vereinbart, wenn sich die Industriebosse in einer Sackgasse befinden, in die sich durch ihre eigenen Süppchen hinein manövriert haben. Wenn es den Kunden zu bunt wird, bleiben sie weg, die Gewinne sinken, etc. Erst müssen die Zahlen zeigen, dass Kooperation nützt, vorher versuchen sie es mit eigenen Süppchen.

Der ganz egoistische Kern, warum es ein - dann halt nicht-standardisiertes - Zwischenformat geben soll: Ich will MIDI-bezogenes Zeug als Abhängigkeit aus dem Kernprojekt Sompyler möglichst raushalten, umgekehrt soll der Konverter nach MIDI nicht vom Sompyler abhängen. Das ist ja der Clou von modularem Zeug: Keine Abhängigkeiten von Geräten oder Code schaffen, sondern von Konzepten, die wohldokumentiert sind, so das andere ihrerseits, jeweils von einer Person überschaubares Zeug machen können, das mit dem existierenden symbiotisch verbunden werden kann.

So kann das Format also aussehen, noch nicht vollständig implementiert, denn, wenn es berechtige Einwände gegen Einzelheiten gibt, würde ich es gerne vorher wissen, nicht erst, wenn die Referenzimplementierung steht und ich das RFC einreiche :

1. Es gibt fünf Felder, tab-separiert: 1) Offset-Zeit in Sekunden, 2) Kanalnummer, 3) Tastennummer 0-127, 4) Betontheit in beliebiger Einheit. 5) weitere Angaben, beliebige Note-on-Metadaten. Die Ascii-Zeichen Line-Feed und/oder Carriage-Return schließen sie ab entsprechend den Konventionen des Systems.
2. Offset-Zeit in Sekunden wird erst bei der Konvertierung nach MIDI umgewandelt zu Deltatime in Ticks. Dafür muss nämlich die aktuelle Clock und die PPQN-Angabe berücksichtigt werden. Die PPQN, Pulses per Quarter Note sei eine obligatorische Angabe auf der Kommandozeile des Konverters, da diese in den Header muss. Die Offsetzeit muss fortlaufend sein und darf nicht in die Vergangenheit zurückspringen.
3. Betontheit wird einheitslos angegeben. Wie die Werte zu interpretieren sind, ob kanalweise oder global, muss dem Konverter ebenfalls vorab erzählt werden durch Kommandozeilenargumente oder anderweitige Konfiguration: Linear oder logarithmisch, welcher Wert korreliert mit velocity=0, welcher velocity=2^n-1. (MIDI v1 n=7 bit)
4. Eine Zeile kann 0 bis 4 Spalten mit ausschließlich numerischen Werten besetzen. Sind es weniger als 4, muss ein fünftes Feld definiert sein, das den Platz der fehlenden einnehmen kann, aber nicht muss. Es muss dafür immer mit einem Lattenzaun (#) beginnen. Das erste Wort nach dem Lattenzaun muss der Konverter kennen oder eine Warnung/Fehler ausgeben, wenn er das nicht tut, und an seiner statt 0, 1 oder mehrere MIDI-Events in den Ausgabestrom schreiben, die die Semantik dieser Angabe umsetzen. Nach dem ersten Wort folgt ggf. ": ", dann weitere komma-separierte Argumente bezogen auf den ersten Token. Benannte Argumente werden ebenfalls mit einem Wort und ": " eingeleitet. Der Funktionsname unterscheidet sich von den Bezeichnungen benannter Argumente somit nur durch seine Position. Eine öffnende Klammer statt dem ersten ": " leitet Argumente ein, die über mehrere Zeilen gehen können. In dem Fall muss die schließende Klammer das letzte Zeichen auf einer der folgenden Zeilen sein. Die umklammerten Zeilen dazwischen sind einzurücken. Nicht eingerückte Zeilen, die numerisch beginnen, sind als Syntaxfehler zu werten. Argumentwerte können mit Anführungszeichen versehen werden.
5. Zeilen mit vier numerischen Werten repräsentieren immer Note-On- oder - wenn der vierte Wert 0 ist - Note-Off-Events. Diese Zeilen können hinter einem Lattenzaun komma-separierte Angaben im "Name: Wert"-Schema nutzen. Vor Angaben, die der Konverter nicht kennt, unterstützt, kann er jeweils beim ersten Auftreten warnen, oder sie ganz ignorieren, idealerweise in Abhängigkeit von Kommandozeilenoptionen.
6. #-Funktionen, die nicht eingangs deklariert werden müssen, d.h. bekannt gemacht werden samt dem normierten Namensraum, wenn der Konverter sie aus bereitgestellten Bibliotheken dazuladen soll, oder Angaben darüber, welche MIDI-Events mit welchen ihrer Argumente generiert werden sollen, sind: Voice, Measure, Clock.
7. Funktions-/Makrodeklarationen immer am Anfang vor der ersten Zeile: # import path.segments.to.macroname as alias (Ja, das ist Python, aber der verlinkte Code hat nur Zugriff auf bestimmte ungefährliche Funktionen, die der Konverter bereitstellt) bzw. # emit when macroname ( ...; [...; ] ) - das erste Segment aus der "; "-separierten Kette in den Klammern, deren enthaltene Argumentreferenzen alle aufgelöst werden können, gilt. Die Geschichte ist rein deklarativ: If, For, etc. gibts nicht.
8. Voice: # Voice: N, label, description?: N Kanalnummer; label, das mit einer entsprechenden GM- oder Program-Nummer oder so, als Angabe auf der Kommandozeile zum Konverter korreliert
9. Measure: Offsetzeit # Measure: beats, orig_ticks_per_beat?, sheet_indication?, sheet_position? orig_ticks_per_beat bezieht sich auf das Ausgabeformat und ist rein Informativ, wie auch die sheet_*-Parameter. Auch beats ist eher zur Zwecken den Validation durch den Menschen, kann aber vielleicht auch zur Synchronierung dienen.
10. Clock: Offsetzeit # Clock: N bpm in Schläge die Minute, bezieht sich auf die bei Measure angegebenen Beats.

-

 

[einseinsnull]

Ich hab hier MIDI-steuerbare Präsentations Bild und Video Player, bei denen würde eine 7Bit-Addressierung für den Bankselect nicht genügen...

als ob man das nicht genauso gut mit einem 14 bit program change machen könnte. feut mich aber zu hören dass es wenigstens außerhalb von musikinstrumenten tatsächlich anwedungen dafür gibt.

 

[einseinsnull]

wieder verabschiedet hab ich mich derweil von der Unterscheidung der Hold- und Sustain-Länge

was es nciht gibt, kann man auch nciht übersetzen oder alternativ darstellen.

aber das ist eben wieder dieser punkt mit dem "warum"... ich meine wenn du meinst, dass das cool wäre, dann machs doch einfach so. machs doch einfach besser als bei midi, das ist ja nicht verboten.

2 attacks und 2 release werte (oder welchen time value pairs auch immer) direkt zum event dazuzuschreiben ist total sinnvoll, ich habe das auch schon so gemacht.

zumal nur ein Teil der MIDI-Empfänger (etwa Pianoteq) sich überhaupt um die Werte für ein Sustain-Pedal scheren dürfte.

sofern ein patch auf pedal reagiert musst du den gewünschten wert irgendwo einmal, z.b. ganz am anfang, gesendet haben. das vergisst man immer, weil klassische DAWs das von alleine machen.

aber was du brauchst liegt natürlich daran, was deine klangerzeugung so versteht. (hast du denn das für dich mal "standardisiert"? darf ich auf die vorteile von float 0.-1. linear "für alles" hinweisen?)

Ein Standard wird nur dann unter mehreren Parteien vereinbart, wenn sich die Industriebosse in einer Sackgasse befinden

eines tages hat ja jemand mal versucht einen neuen, ultimativen standard zu entwickeln, der alles kann und alle anderen überflüssig macht.

am nächsten tag gab es dann einen standard mehr.

 

[GegenKlang]

am nächsten tag gab es dann einen standard mehr.

Ein Standard ist ja auch was anderes als zu versuchen, einen Standard zu definieren. Genauso kannst du definieren, dass Schrank Tisch heißt, und Tisch heißt , das wird nur niemanden interessieren, solange du wie ich ein Normalsterblicher bist. Es sei denn, du bist auch so größenwahnsinnig wie ich. Ah, das Einhorn gefällt mir, das nehm ich als neuen Zeilentrenner in meinem Format, bei diesem Wirrwarr mit Carriage return und-oder Line feed sieht ja kaum einer mehr durch, gell.

Ne, ich bin nicht mehr zuversichtlich. Wenn ich auch ein Format entwickle, dann nenne ich es vielleicht doch besser nur

condensed, quite easily parsible logging format that sequences not only the beginning, but also the endings of the notes orderly in time. For those who intend to work around the included patience-demanding sound modelling/rendering engine, used to MIDI and their studio devices they want to feed a Sompyler score, that format could serve as input to a converter script or something.

Denn wenn ich selbst den Konverter schriebe, was ich müsste, damit das Format auch nur den Hauch einer Chance hätte da draußen sich zu etablieren neben MIDI - dann wäre ich ja praktisch auch verantwortlich für die ganzen Geräteweichen. Ziel A versteht den MIDI-Standard so, Gerät B so. Neusiker, würde jemand früher oder später auf mich zukommen, könnte man nicht konfigurieren, ob man MIDI-Geschmacksrichtung A oder B will?
Da fängts ja vielleicht schon an: Unterstützt ein Gerät Note Off oder nur Note On bei velocity 0 - wie verhält es sich da? Folgt man da auch in der realen Welt dem Grundsatz "Be permissible in what you get, but strict in what you pass"?

Ne, ehe ich mich in ein weiteres Softwareprojekt stürze, wäre ich bestimmt gut beraten, meine begonnenen Projekte zu beenden. Und dann endlich ... damit Musik zu machen .

 

[einseinsnull]

ich wäre vermutlich der letzte, der anderen vorwerfen könnte, sich einen standard nur zum eigengebrauch zu schaffen.

however, du scheinst jetzt erkannt zu haben, dass man sich keine problemlösung für ein problem basteln kann, das man gar nicht wirklich kennt. schritt 1 ist auf jeden fall immer erst mal einen bestimmten funktionsumfang, aussehen usw. von etas zu benötigen, bevor man es sich dann baut.

 

[GegenKlang]

ich wäre vermutlich der letzte, der anderen vorwerfen könnte, sich einen standard nur zum eigengebrauch zu schaffen.

Schon weil es lächerlich wäre, überhaupt das Wort "Standard" für ein Format in den Nund zunehmen, das man sich für den Eigenbedarf schafft.

Um noch kurz zurückzukommen auf:

(hast du denn das für dich mal "standardisiert"? darf ich auf die vorteile von float 0.-1. linear "für alles" hinweisen?)

Und die Nachteile verschweigen? Der Texteditor meines Vertrauens ist Vim und der kann Ganzzahlen inkrementieren und dekrementieren mit einer einfachen Tastenkombi. Daher nutze ich lieber Ganzzahlen und interpretiere sie logarithmisch oder als Verhältnisse n:m. Du siehst, an meinem Horizont beginnt der pragmatische Ozean.

 

[einseinsnull]

du musst doch eh z.b. linear in frequenzen übersetzen und sowas, da kannste auch gleich noch einen dritten wertebereich mit ins boot holen, der sich dann wenigstens leichter in sonstwas umrechnen lässt - und vor allem immer gleich ist.

ich trenne immer streng zwischen (re)präsentationsebene (GUI?), speichern/verarbeiten und ziel.


notenwerte in ganzzahlen (oder fractions) zu beschreiben ist sooo achtziger.

kannst du das lesen, wenn in reiner stimmung als nächstes eine 60*(45/32) kommt? bei mir ist das einfach 65.902237, und dann weiß ich woran ich damit bin.

(und arbeite natürlich so lange mit der notennummer 66, bis ich zum schluss das truning festlege/ändere.)

 

[GegenKlang]

kannst du das lesen, wenn in reiner stimmung als nächstes eine 60*(45/32) kommt?

In "meiner" Welt agiere ich mit Pitch classes, Änderung des Grundtons im Rahmen ungleichstufiger Stimmungen (für ganze Taktteile, Harmonien), Tastennummern und -abstände (diatonische/chtomatische Intervalle), bis hin zu Centabweichungen. "C2" also kann ich leichter verstehen als nackte Frequenzen. Wie das C2 gestimmt ist, notiere ich nicht an der Note. Ich könnte, wenn ich wollte, aber meist ist das nicht sinnvoll. Tonhöhen werden auch bei mir irgendwann nach Fließkomma-Frequenzen umgerechnet, dann sind sie für mich aber read-only. Floats in Nur-lese-Kontexten stören mich nicht, die muss ich nur noch kontrollieren und ggf. ihre Berechnung korrigieren.

Aber das ist hier am Ende off-topic. Wichtig festzuhalten ist, dass es mir nicht leicht fällt eine Brücke zu schlagen zwischen der Musiktradition auf Grundlage der notierten Literatur auf der einen Seite, und der "technologischen", elektronischen Musikproduktion auf der anderen. Mein Wunsch nach einem programmneutralen Format ist der Motivation geschuldet, möglichst wenig, am besten nur das mir bekannte Interface drumherum zu haben, um damit eben zu arbeiten ohne Einarbeitung. Damit vergesse bzw. ignoriere ich typischerweise, dass dafür so ein selbstentwickeltes Format für Dritte wiederum einen Lern- und Umlernaufwand darstellen würde.

Ein noch so guter Cessna-Pilot wäre kein guter Pilot mit einem Touchscreen vor sich.

 

[GegenKlang]

Ich weiß nicht, ob es ein neues Thema verdient, jedenfalls bin ich in meinem Bemühen um ein Format zwischen der notenbasierten und der eventbasierten Codierung auf ein weiteres Problem gestoßen. Mein Versuch, aus den Notenlängen eine Pedalisierung abzuleiten, um damit die richtigen Controller anzusteuern, ist ja schon gescheitert - siehe weiter oben.

Wenn ich MIDI richtig verstehe, muss ich mich leider auch von Plan B verabschieden: Oder legt der MIDI-Standard irgendwie fest, was passieren soll, wenn zwischen zwei Note-On-Messages für den gleichen Kanal und denselben Ton kein Note-Off mit diesem Kanal und Ton erfolgt, der den ersten Note-On aufhebt? In dem Fall hätte ich gedacht, braucht es dem entsprechend ein Note-Off für das erste Note-On und ein weiteres für das zweite.

Blöd, dass aber keine Fallunterscheidung stattfinden könnte. Schließlich kodiert ein Note-Off m.W. ja nicht, ob es sich auf das eine oder andere Note-On mit demselben Kanal und Pitch-Value bezieht.

Heißt in der Konsequenz: Sobald ein und dieselbe Taste wiederholt angeschlagen werden soll, ohne dass ihr Klang zuvor per Loslassen gedämpft wurde, brauche ich den Controller für Sustain. Nur so geht Release ohne oder nur mit partieller Dämpfung.

Scheibe. Ich glaub, ich gebs auf. So ein gescheites Kerlchen bin ich halt doch nicht. Klar, es ginge wohl irgendwie, aber die Kosten sind für mich nicht vertretbar vermutlich: den Code müsste ich zu stark umorganisieren, und fraglich, ob wiederum der bisherige Direktweg vom Text zu Klang, am Nadelöhr der Echtzeitfähigkeit vorbei, elegant realisierbar wäre, der ist schließlich die Hauptsache, besagtes Zwischenformat zwecks MIDI-Export nur Beiwerk.

Ich poste das nur, damit andere nicht in die gleiche Falle laufen - Lesson learned. MIDI ist eben sehr nah an der signalbasierten, echtzeitfähigen Technik entwickelt. Es ist nicht kompatibel zu Szenarien, die auf anderen Abstraktionen beruhen, wie solchen, in denen es Notenobjekte gibt, die einander überlappen können, selbst wenn sie die gleiche Taste betreffen. Das ist tatsächlich der Fall in der Beethoven'schen Mondscheinsonate, hier mal umgesetzt mit einem Piano oder Xylophon aus Glas oder so, wer mag, und es kann sein, dass keine MIDI-Datei im Internet erhältlich ist, die eurer Studiotechnik so eine Leistung entlockt, unabhängig vom Klang:

 

[DanReed]

Notenobjekte, die einander überlappen können, selbst wenn sie die gleiche Taste betreffen. Das ist tatsächlich der Fall in der Beethoven'schen Mondscheinsonate

Jetzt bin ich wohl zu blöd: wie soll Beethoven ein und dieselbe Note auf einem Klavier überlappen lassen? Um die Taste ein zweites Mal erklingen zu lassen, muss man zwingend vorher loslassen, oder nicht?

 

[einseinsnull]

Wenn ich MIDI richtig verstehe, muss ich mich leider auch von Plan B verabschieden: Oder legt der MIDI-Standard irgendwie fest, was passieren soll, wenn zwischen zwei Note-On-Messages für den gleichen Kanal und denselben Ton kein Note-Off mit diesem Kanal und Ton erfolgt, der den ersten Note-On aufhebt?

midi legt das nicht fest, das ist sache des empfängers. theoretisch kann jeder empfänger auch einfach die gleiche note 2 mal starten lassen.

ich denke es ist korrekt zu formulieren: eine midi nachricht wird nicht falsch dadurch, dass sie nicht verstanden wird oder nicht zum gewünschten ergebnis führt.

so haben ja geräte z.b. auch eine begrenzte polyphonie. trotzdem ist auch das 17te note on, was du hinschickst, dadurch noch immer dem standard folgend.

In dem Fall hätte ich gedacht, braucht es dem entsprechend ein Note-Off für das erste Note-On und ein weiteres für das zweite.

im regelfall wird der empfänger einfach verweigern das zweite note on entgegenzunehmen (ergo es an die klangerzeugung weiterzuleiten) oder er erzeugt das note off einfach selbst.

das ist so ein bischen wie die geschichte mit dem running status: wenn du kein status byte sendest, werden die meisten empfänger einfach davon ausgehen, dass es sich nicht geändert hat und nehmen das bestehende/letzte aus ihren midi-in buffer.

Blöd, dass aber keine Fallunterscheidung stattfinden könnte. Schließlich kodiert ein Note-Off m.W. ja nicht, ob es sich auf das eine oder andere Note-On mit demselben Kanal und Pitch-Value bezieht.

das ist sozusagen der grund warum es gar nicht "geht"/gemacht werden soll.

wenn ich es aber in einer software oder in einem gerät so haben will, dann kann ich das so implementieren - muss mich dann dabei natürlich entscheiden, was passieren soll wenn das erste note off kommt während die note schon zwei mal spielt - und das ändert aber alles nichts daran, dass die nachrichten die ich hin und her schicke immer noch dem midi standard entsprechen.

Heißt in der Konsequenz: Sobald ein und dieselbe Taste wiederholt angeschlagen werden soll, ohne dass ihr Klang zuvor per Loslassen gedämpft wurde, brauche ich den Controller für Sustain. Nur so geht Release ohne oder nur mit partieller Dämpfung.

warum sollte das so sein?

du musst mal so denken: einen release phase hat das empfangsgerät ohnehin. note off beendet als das ereignis also gar nicht.

MIDI ist eben sehr nah an der signalbasierten, echtzeitfähigen Technik entwickelt

midi ist eine starke einschränkung gegenüber dem, was rein theoretisch denkbar ist, das ist klar.

selbst viele der mitgelieferten funktionen wie tuning oder release velocity benutzt kaum jemand, vermutlich weil sie einfach scheiße sind.

 

[einseinsnull]

Jetzt bin ich wohl zu blöd: wie soll Beethoven ein und dieselbe Note auf einem Klavier überlappen lassen? Um die Taste ein zweites Mal erklingen zu lassen, muss man zwingend vorher loslassen, oder nicht?

es gibt nichts, was dich davon abhalten kann ein instrument mit zwei tasten und zwei hämmern pro saite zu bauen.

oder einfach zwei klaviere zu benutzen.

 

[fhdgjrtjrj5745745737357]

es gibt nichts, was dich davon abhalten kann ein instrument mit zwei tasten und zwei hämmern pro saite zu bauen.

oder einfach zwei klaviere zu benutzen.

Haha, Klaviere layern mal rein physikalisch^^

 

[GegenKlang]

Jetzt bin ich wohl zu blöd: wie soll Beethoven ein und dieselbe Note auf einem Klavier überlappen lassen? Um die Taste ein zweites Mal erklingen zu lassen, muss man zwingend vorher loslassen, oder nicht?

Stimmt natürlich, der originale Beethoven hatte ein Klavier und dieses Klavier hatte Pedale.

Die Abstraktion, die mir hier zum Verhängnis für Plan B worden ist: Jedes Pedal ein Fingerpedal. Hat man vom physisch zu spielenden Instrument abstrahierte Noten, deren Länge die Technik vorweg weiß und die sie bei gleicher wie bei unterschiedlicher Tonhöhe einfach layern kann, ist es folgerichtig, das Sustain in die Notenlänge mit eingehen zu lassen, dabei auf die akustischen Implikationen - alle ungedämpften Saiten resonieren im Chor mit dem Resonanzboden als Brücke - eines richtigen Pedals am richtigen Klavier zu verzichten (dafür hat man ja wiederum unendliche Klangvielfalt mit einem einzigen Werkzeug, gell). Und eben diese Entscheidung macht das Thema MIDI-Export nun zu einem echtem Spießrutenlauf.

Ich könnte Note-Ons auf Pitchnummern, die durch ein offenes Note-On belegt sind, natürlich auf einen anderen MIDI-Kanal legen (solange es einen gibt, der nicht durch ein offenes Note-On belegt ist), nachdem er genauso intialisiert wurde wie der primäre. Diese Funktion eines dynamischen Mappings muss es eh geben, damit man mehr Instrumente haben kann als 16. Aber wie ich die Realität kennen gelernt habe, hat sie auch für dieses Szenario ungünstige Überraschungen, die den Einsatz einfacher analoger Mixer erschweren könnten.

Addendum: Zwischenformat Beispiel. Besagtes Problem habe ich hier "gelöst", indem auch die Releases die Intensitäten der loszulassenden Töne angeben. Weiß nicht, ob es schlimm ist, wenn man sie zwangsläufig verwechselt mit der Velocity von Note-Offs. Jedenfalls glaube ich, dass man auf dieser Grundlage nun einen Konverter zu MIDI schreiben könnte. Oder? Dieses Format ist zumindest dazu besser geeignet als das ursprüngliche, weil das syntaktisch doch sehr viel komplexer ist, dafür auch aber viel leichter auf musiksemantischer Ebene zu lesen und zu schreiben.

 

[DanReed]

Und eben diese Entscheidung macht das Thema MIDI-Export nun zu einem echtem Spießrutenlauf.

Du hast also quasi das Sustain-Pedal wegoptimiert, wenn ich das richtig verstehe?

Dann könnte ich mir als Lösung vorstellen, dass man bei einem Note On, der einem Note On ohne Note Off nachfolgt, einfach den fehlenden Note Off vorzieht und unmittelbar (1ms?) dem neuen Note On vorausgehen lässt. So dürfte trotzdem der Eindruck entstehen, das Pedal sei getreten.

 

[2bit]

Fingerpedal

Es gibt keine Pedale für Finger. Das ist ein Widerspruch in sich selbst, ein Oxymoron.

 

[GegenKlang]

2bit: Der Pianist nennt es nun mal so, wenn Finger liegen bleiben, während andere Finger derselben Hand neue Töne anschlagen. Das Pedal hat nämlich den Nachteil, dass es die Töne verbreit.

@DanReed : Ja, das ist eine Möglichkeit, die ich erwäge.

 

[einseinsnull]

Es gibt keine Pedale für Finger. Das ist ein Widerspruch in sich selbst, ein Oxymoron.

ein "fingerpedal" ist eine technik beim spielen von tasteninstrumenten, die darin besteht eine taste stumm anzuschlagen, damit die saite mitschwingt wenn eine andere angeschlagen wird.

gehört zu den vielen dingen, die man selbst programmieren muss, weil sie mit midi und handelsüblichen snythesizern nicht realisierbar sind.

edit: oh, ich bin mal wieder zu spät.

 

[2bit]

Cool. Der Begriff ist in sich immer noch Unsinn und nun gibt es sogar schon ZWEI Definitionen, die einander widersprechen.

Entweder wird die Taste stumm angeschlagen (Wikipedia), oder sie wird normal angeschlagen und gehalten (Torsten Eil). Beides geht nicht.

Was ist hier gemeint?

 

[recliq]

Kommt beides aufs gleiche raus, sie wird nicht gedämpft und schwingt daher mit bzw. weiter.

 

[2bit]

Kommt beides aufs gleiche raus, sie wird nicht gedämpft und schwingt daher mit bzw. weiter.

Bei Midi? Nö. Ersteres hängt gar nicht an Midi, sondern am Synth* dahinter, und Zweites braucht man überhaupt nicht implementieren. Das kann Midi nämlich schon.

*Der muss das auch verstehen und vor allem technisch umsetzen können. Monophone fallen da grundsätzlich raus, Sampler und Rompler auch. Das Mitschwingen von Saiten kriegen wahrscheinlich, wenn überhaupt, nur noch Physical-Modelling-Spezialisten wie Pianoteq auf die Reihe.

 

[recliq]

Es ging ums Klavier... Wie schon gesagt gibts bei Midi Note On und Note Off und das nur einmal pro Ton.

 

[einseinsnull]

Bei Midi? Nö. Ersteres hängt gar nicht an Midi, sondern am Synth* dahinter, und Zweites braucht man überhaupt nicht implementieren. Das kann Midi nämlich schon.

natürlich ast du recht, dass das eine sache der interpretation der eingehenden daten ist, ergo der synth sdas erst mal selbst können muss.

neusiker allerdings geht es ja um die frage, wie man so etwas, wenn man es denn bereits hat, als midi exportieren kann. und da gibt es leider nichts, was auch nur annähernd so etwas leistet. mit ausnahme der benutzung paralleler kanäle, die aber kein standard sind (und zwar auch nicht bei mpe)