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

G

GegenKlang

||||||||
Mir schwebt ungefähr so etwas vor:

Code: 
#OFFSET(s)    #CHANNEL    #KEYNUM    #LENGTH(s)    #STRESS (!= velocity, but dBFS + 100)
# VOICE(name='p', channel=0, instrument='dev/piano')
# CLOCK: 80.0 beats per minute
0.000000    0    36    55.000000 # Tfid: 1, Pitch: G#3=207.6523487899725, Release in 3.0s
0.000000    0    29    55.000000 # Tfid: 2, Pitch: C#3=138.59131548843595, Release in 3.0s
0.000000    0    17    55.000000 # Tfid: 3, Pitch: C#2=69.29565774421795, Release in 3.0s
0.250000    0    41    50.000000 # Tfid: 4, Pitch: C#4=277.182630976872, Release in 2.75s
0.500000    0    44    50.000000 # Tfid: 5, Pitch: E4=329.62755691286986, Release in 2.5s
0.750000    0    36    50.000000 # Tfid: 6, Pitch: G#3=207.6523487899725, Release in 2.25s
1.000000    0    41    55.000000 # Tfid: 7, Pitch: C#4=277.182630976872, Release in 2.0s
1.250000    0    44    55.000000 # Tfid: 8, Pitch: E4=329.62755691286986, Release in 1.75s
1.500000    0    36    55.000000 # Tfid: 9, Pitch: G#3=207.6523487899725, Release in 1.5s
1.750000    0    41    50.000000 # Tfid: 10, Pitch: C#4=277.182630976872, Release in 1.25s
2.000000    0    44    50.000000 # Tfid: 11, Pitch: E4=329.62755691286986, Release in 1.0s
2.250000    0    36    50.000000 # Tfid: 12, Pitch: G#3=207.6523487899725, Release in 0.75s
2.500000    0    41    50.000000 # Tfid: 13, Pitch: C#4=277.182630976872, Release in 0.5s
2.750000    0    44    50.000000 # Tfid: 14, Pitch: E4=329.62755691286986, Release in 0.25s
3.000000    0    36    0.00000 # release
3.000000    0    29    0.00000 # release
3.000000    0    17    0.00000 # release
3.000000    0    41    0.00000 # release
3.000000    0    44    0.00000 # release
3.000000    0    36    0.00000 # release
3.000000    0    41    0.00000 # release
3.000000    0    44    0.00000 # release
[...]
# Komplettes Listing s. https://neusik.de/2022-02-19/lvb_moonlight_sonata.premidi.txt

Das heißt, wenn es das nicht gibt, besteht vermutlich kein Bedarf an sowas?

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 wirds kompliziert und richtig technisch, wenn er solche Fotmate beherrschen will. Versuche von unabhängigen Entwicklern werden denn gern auch von den Herrstellern proprietärer Programme bewusst erschwert, sei es mit rechtlichen oder technischen Mitteln, oder beidem.

Ein Programm, das zwischen MIDI und dem Zwischenformat hin und her konvertiert, braucht man freilich auch. Das könnte auch von Dritten stammen, idealerweise unter einer freien Lizenz natürlich. Aber ein Programm, was dieses Zwischenformat liest oder schreibt und irgendwas sinnvolles damit anstellt, wäre dann doch eine gute Aufgabe für einen Informatik-Leistungskurs.

Wenn ich wieder Zeit und Lust dazu habe, programmiere ich einen Zwischenformat<->Midi-Konverter. Obiges Zwischenformat wurde vom Sompyler, meinem Offline-Synthesizer, aus dem Score der Mondscheinsonate generiert. Mit den enthaltenen Instrumenten ist klanglich noch kein Staat zu machen. Damit er unabhängig davon potenziell einen Mehrwert hat, hab ich ihm neben Audio-PCM diese alternative Ausgabemöglichkeit spendiert.

Händisches Instrumentenspiel ist ja sowas von gestern, gell? ;-) Macht aber auch Spaß, auf andere Art.
 
Es gibt doch Tracker, in Wikihausen auch Rastersequenzer genannt.

und Sequenzer haben gerne MIDI List Editoren - da sind dann die MIDI Events in Listenform.

Ist beides so ein Zwischending.
 
Neusiker schrieb:
Was mich betrifft, ich bin ein Fan von Textformaten. Textformate können relativ einfach mit relativ einfachen selbst entwickelten Programmen bearbeitet werden.
Zum Vergrößern anklicken....

Ich bin eigentlich auch ein Fan von Textformaten, aber Textformate haben den Nachteil, dass sie für die Verwendung geparst werden müssen.
Und da sehe ich bei dem beschriebenen Format keinen Mehrwerk.

Es gibt MIDI-Editoren für alle möglichen in der Musik üblichen Darstellungsformen:
- Event-Listen (Tracker)
- Piano-Roll (z.B. MidiEditor)
- Notensatz (z.B. MuseScore)

Und das MIDI-Format ist derartig regulär und gut dokumentiert, dass es für Eigenentwicklungen meines Erachtens nicht schwerer zu parsen oder zu generieren ist, als ein Klartext-Format.
 
@Neusiker wenn Du sowas entwerfen willst würde ich schauen das es XML kompatibel ist
 
Neusiker schrieb:
Mir schwebt ungefähr so etwas vor:
Zum Vergrößern anklicken....
Mich würde das auch interessieren, wie das MIDI Protokoll als Programm Code aussieht. Und ob dieses Protokoll aus 1982 bis heute in modernen DAWs so abläuft und ob die Pausen auch irgendwie dargestellt werden oder ob da einfach nur die Noten fehlen.
 
Neusiker schrieb:
#OFFSET(s) #CHANNEL #KEYNUM #LENGTH(s) #STRESS (!= velocity, but dBFS + 100)
# VOICE(name='p', channel=0, instrument='dev/piano')
# CLOCK: 80.0 beats per minute
0.000000 0 36 55.000000 # Tfid: 1, Pitch: G#3=207.6523487899725, Release in 3.0s
0.000000 0 29 55.000000 # Tfid: 2, Pitch: C#3=138.59131548843595, Release in 3.0s
0.000000 0 17 55.000000 # Tfid: 3, Pitch: C#2=69.29565774421795, Release in 3.0s
0.250000 0 41 50.000000 # Tfid: 4, Pitch: C#4=277.182630976872, Release in 2.75s
0.500000 0 44 50.000000 # Tfid: 5, Pitch: E4=329.62755691286986, Release in 2.5s
0.750000 0 36 50.000000 # Tfid: 6, Pitch: G#3=207.6523487899725, Release in 2.25s
1.000000 0 41 55.000000 # Tfid: 7, Pitch: C#4=277.182630976872, Release in 2.0s
1.250000 0 44 55.000000 # Tfid: 8, Pitch: E4=329.62755691286986, Release in 1.75s
1.500000 0 36 55.000000 # Tfid: 9, Pitch: G#3=207.6523487899725, Release in 1.5s
1.750000 0 41 50.000000 # Tfid: 10, Pitch: C#4=277.182630976872, Release in 1.25s
2.000000 0 44 50.000000 # Tfid: 11, Pitch: E4=329.62755691286986, Release in 1.0s
2.250000 0 36 50.000000 # Tfid: 12, Pitch: G#3=207.6523487899725, Release in 0.75s
2.500000 0 41 50.000000 # Tfid: 13, Pitch: C#4=277.182630976872, Release in 0.5s
2.750000 0 44 50.000000 # Tfid: 14, Pitch: E4=329.62755691286986, Release in 0.25s
3.000000 0 36 0.00000 # release
3.000000 0 29 0.00000 # release
3.000000 0 17 0.00000 # release
3.000000 0 41 0.00000 # release
3.000000 0 44 0.00000 # release
3.000000 0 36 0.00000 # release
3.000000 0 41 0.00000 # release
3.000000 0 44 0.00000 # release
[...]
# Komplettes Listing s. https://neusik.de/2022-02-19/lvb_moonlight_sonata.premidi.txt
Zum Vergrößern anklicken....

Ich würde schon mal die Zeiten nicht in Sekunden angeben, schon weil die ja von der Clock abhängig sind und 'ne Menge Kram vorher in so 'ner Art Header definieren - vielleicht pro Block, wie die Pitch der Noten etc., der Übersicht zuliebe.
Hast du Erfahrungen mit Programmiersprachen?
 
NoMoreWords schrieb:
@Neusiker wenn Du sowas entwerfen willst würde ich schauen das es XML kompatibel ist
Zum Vergrößern anklicken....
XML... warum grad das schlimmste aller formate, wenn es doch einfach sein soll? das ist ja noch nerviger und schwerer zu parsen als reines midi!
Wer benutzt denn heute noch ernsthaft xml? ;-)
 
  • Daumen hoch
M.i.a.u.: ZH
Ich habe mal gehört das xml veraltet ist. JSON ist quasi der Nachfolger.
XML Tags erzeugen auch eine Menge Daten. Ist gerade bei zeitkritischen Dingen Doof.
 
Wenn ich mir so ein Format überlegen müsste, würde ich auf jeden Fall Informationen, die identisch sind, nicht mehrfach in der Datei unterbringen. Überhaupt hätte ich jetzt aus der hohlen Hand ein paar Verbesserungsvorschläge:

(1) Du hast in jeder Zeile an zweiter Stelle 0 als "#Channel" und in Deiner "#voice"-Zeile auch noch mal. Stell Dir vor, Du willst das ändern. Womöglich von Hand. Vielleicht doch nur als Meta-Information?

(2) Dann die ganzen "0" hinter den Kommas. Vor lauter Nullen sieht man die eigentlich wichtigen Daten nicht mehr und sie blähen die Datei enorm auf. "Trailing zeros" weg (zur besseren Lesbarzeit eher mit Tabulator oder Spaces arbeiten).

(3) Dann Pitch in 17stelliger Genauigkeit. Vielleicht ist das eher eine Meta-Information, die meistens für einen ganzen Track gilt (wenn nicht sogar für ein Musikstück)? Und nun muss mal die Musik für einen Flügel einfach am Synth umgestimmt werden, dann stimmen all diese Zahlen nicht mehr. Also vielleicht eher relativ als Faktor angeben (wenn überhaupt, bzw. wenn von "gleichstufiger Stimmung" abweichend)?

Nichts für ungut: Ich finde Deine Idee sehr gut und wichtig. Aber es macht sehr viel Sinn, zunächst über allgemeine Anforderungen nachzudenken. Bin gerne bereit und interessiert, mir mehr konstruktive Gedanken dazu zu machen, wenn gewünscht.

Was ist z.B. mit Modulator-Bewegungen?

Oder Ritardandi/Accelerandi (Sollten die Zeitstempel vielleicht besser relativ zum Tempo, das eine Metainformation ist) angegeben werden?
 
DanReed schrieb:
Zu xml, json und yaml: Da ist gut zu sehen, wie im Laufe der Jahre die mit xml explosionsartig eingeführten Labels/Tags und andere Strukturierungssymbole wieder abgebaut werden. Konsequenterweise folgt als nächster Entwicklungsschritt "simple plain text" ("back to the roots" :selfhammer:)
Zum Vergrößern anklicken....

Womit wir also wieder bei CSV wären und der Kreis sich schließt.
 
Die Frage, die ich mir hier stelle ist, welches Problem willst du lösen? Nicht falsch verstehen, ich will dir hier nichts madig reden, ich muss nur diese Frage stellen, Berufskrankheit 😉
Geht es dir hier darum, das du eine neue Art von Sequenzer entwickeln willst, mit der du andere Seiten der Kreativität entdecken willst? Oder willst du eine einfachere Möglichkeit zum Austausch von Projekten zwischen den ganzen DAWs? Bei letzterem kann ein Textbasiertes Format als Zwischenschritt sinnvoll sein. Bei letzterem wäre das Format erst sekundär wichtig. So oder so wirst du für jedes neue Format einen "Konsumenten" benötigen. Und wenn du dir selber die Frage beantworten kannst, wirst du auch wesentlich einfacher an dein Ziel kommen.
 
Mann muss bei XML, wenn man es "quasi textbasiert" haben möchte, einfach die richtigen Tools/Editoren benutzen, um das ganze drumherum nicht sehen zu müssen, kann aber z. B. mittels XSD Wertebereiche definieren. Ist manchmal sehr sinnvoll ... rein textbasiert sollte längst überholt sein, da sehr fehleranfällig. Hängt aber halt immer von der Anwendung ab.
 
Schwer zu sagen.
Struktur und menschliche Lesbarkeit würden mir einfallen.

Die Kernfrage ist aber hier glaube ich ob man Notenlängen beim Notenstart definiert, oder aber Note-off Events hat wie bei MIDI
 
MoogelPackung schrieb:
Und wo ist da der Mehrwert gegenüber MIDI?
Zum Vergrößern anklicken....
Zum Beispiel, dass man eine automatische Überprüfung der eingegebenen Werte bekommt, sollte es um manuelle Bearbeitung gehen (denn da passieren bekanntlich die meisten Fehler). Aber deswegen schrieb ich, abhängig von der Anwendung ... oben wird ja nur von textbasiertem Format gesprochen. Wo kommt das her? Schreibt das eine Anwendung? Wird das manuell erzeugt? ;-)
 
MoogelPackung schrieb:
Es gibt MIDI-Editoren für alle möglichen in der Musik üblichen Darstellungsformen:
- Event-Listen (Tracker)
- Piano-Roll (z.B. MidiEditor)
Zum Vergrößern anklicken....
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.

Der Converter, in Python geschrieben, wird etwa von MIDO abhängen. Das kann ich mir dort leisten, der tritt ja nur an der Grenze zu MIDI-Hard- oder -Software in Aktion. Aber eben nur dieser Converter, nicht die eben schnell mal gestrickten Programme zur Analyse oder Synthese, die agieren am einfachsten auf plain text. Der didaktische Aspekt, sowie die prozedurale Einfachheit und ein sparsamer Einsatz von Abhängigkeiten sind mir wichtig. Das betrifft auch Abhängigkeiten für Textformate. Plaintext stellt kein Problem dar, wenn über Systemgrenzen hinweg MIDI oder initial zu diesem Miditext konvertierbare musiksemantische Formate (XML/JSON/YAML; Sompyler Score kann in JSON oder YAML formuliert werden) in einer gegebenen Beschreibungssprache fließt, somit gilt immer der gleiche Zeichensatz und Zeilentrennung.

Sompyler Score code verhält sich zu MIDI-Text wie Java, Scala, Vala etc. zu JVM-Bytecode, oder C, C++, D etc. zu Assembler. Und MIDI-Text verhält sich zu MIDI wie Assembler zu Maschinencode. Die Epoche der Eierlegenden Wollmilchsäue (DAW) sollte mE beschränkt werden auf Szenarien, wo Echtzeit-Controller mit von der Partie sind, bei reinen Out-of-the-Box-Workflows sehe ich keine Notwendigkeit dafür, wenn man Komfort fundamental nerdig versteht. Nerdkomfort ist, wenn man seinen Workflow selber machen kann und nicht einfach gekaufte Module zusammenstöpseln muss. Nerdkomfort heißt, Dinge abzulehnen, bei denen "kinderleichte Bedienung" geworben wird, denn die kinderleichte Bedienung steht einem da meist im Weg. Nerdkomfort heißt, binäres Zeug so früh wie möglich zu Text konvertieren und so spät wie möglich zurück.

Die Unixphilosophie ist mir sympatischer: Tools lesen und schreiben Text (oder meinetwegen allerhöchstens JSONL, JSON List, wo jedes Element eine Zeile ist), den der Mensch notfalls in einem universellen Editor überprüfen und ändern/korrigieren kann. So kann jede Station im Workflow mit einem genau dafür entwickelten Tool umgesetzt werden. Ein Tool, eine Aufgabe, ist das Ideal.

Der Konverter erst kümmert sich in Text-MIDI-Richtung um die hier schon teilweise vorgebrachten Probleme:
  • Konvertierung der Sekundenwerte zu MIDI-Ticks und Setzen passender Clock-Events anhand der "# Clock: ..."-Angaben im Text
  • Assoziation Kanal und Instrument anhand der auf der Kommandozeile angebenen Kanäle und ihre initialen Program-Nummern, die der Benutzer intellektuell festlegt entsprechend der VOICE-Zeilen am Anfang. Beherrscht das Problem, daß es mehr als 16 Stimmen geben kann. So lange zu keiner Zeit mehr als 16 Stimmen gleichzeitig Noten anschlagen/fortklingen lassen, kein Problem, der Konverter kann umdisponieren, Kanäle remappen und umkonfigurieren.
  • Konvertierung der "Stress"-Werte zu Velocities. Im Ursprungs-Score ist stress=80 das Maximum, warum hier nicht 100, das hat historische Gründe, da hab ich was probiert, glaub ich. Jedenfalls entspricht stress=80 somit velocity=127 (MIDI ver1), stress=60 - Achtung, log. Skala - ergo velocity=13.
Aber der MIDI-Text ist noch nicht ganz so, wie er sein soll:
  • Noten sind ggf. in die Vergangenheit vorzuverlegen. Im Gegensatz zu MIDI-Text wird im Sompyler Score noch Takt für Takt, Stimme für Stimme, Akkord für Akkord, Note für Note evaluiert. Da kümmert sich jede Measure-Instanz auch um die Noten, die vorhergende Measures an sie weitergereicht haben, weil sie noch abzuzählende Ticks offen haben. Diese Ticks muss jeweils immer das aktuelle Measure abzählen und am Ende entweder an die weitere Verarbeitung oder ans wiederum nächste Measure weiterreichen. Und natürlich die Sekundenlänge der Note, die erst der Synthesizer in Frames umrechnet, entsprechend dem aktuellen, möglicherweise kontinuierlich und/oder von Tick zu Tick variierenden Tempo erhöhen. Wenn also eine Note fertig ist und gelistet werden kann, kommt sie eigentlich zu spät. Die Liste muss also von Beginn an neu iteriert und an der richtigen Stelle der/die Spätkommer einsortiert werden. Nur dann ist die Kontextfreiheit jeder Zeile gegeben.
  • Netto- und Bruttodauer der Noten sind zu unterscheiden, damit die Events des Sustainpedals richtig gesetzt werden können. Hold- und Sustainphase auf Tonebene. Sustain-Controllerwerte beziehen sich auf alle offenen Noten.
 
Zuletzt bearbeitet:
Wenn der Sinn eines solchen Formates sein soll, dass man das auch von Hand bearbeiten / schreiben kann, dann wuerde ich alles nehmen, nur kein XML.
Wie sagt man so schoen: XML vereint die Nachteile von Textformaten mit den Nachteilen von Binaerformaten.

Eine leicht selbst zu schreibende "MIDI-Programmiersprache" waere schon was cooles. Ich wuerde den Weg gehen, ein Format zu suchen, bei dem man moeglichst wenig schreiben muss, beispielsweise auch nur Noten schreiben kann, ohne Velocity und Duration und Co, und dass in solch einem Fall einfach die vorherigen Werte uebernommen werden. Oder dass man einen Block definieren kann, mit Velocity und Duration, und in dem dann eine Folge von Noten kommt, die alle mit diesen Werten gespielt werden, etc.

Ich habe mir selbst mal in Python einen kleinen Sequencer geschrieben, der hat anfangs auch einfache Textdateien gelesen um die Sequenz abzuspielen. Das war zwar kein vollendetes Format, eher was schnell hingeklatschtes, aber ich fand das ganz praktisch. Da habe ich mich der Einfachheit halber am Tracker-Format orientiert. Hier kann man das in den ersten paar Sekunden (0:04 - 0:09) sehen:


https://www.youtube.com/watch?v=2WPFb6Oro-A
 
ZH schrieb:
Wie sagt man so schoen: XML vereint die Nachteile von Textformaten mit den Nachteilen von Binaerformaten.
Zum Vergrößern anklicken....
Wieso verbreiten manche Leute solchen Unsinn? XML + XSD + richtiger Editor ist wie Text (man sieht nichts von den XML-Tags), nur mit Werteüberprügung! Und man kann daraus alles mögliche generieren, auch Text! Mach das mal mit Text.
 
Zuletzt bearbeitet von einem Moderator:
ZH schrieb:
das geile an Text ist halt, dass ich keinen "richtigen Editor" brauche, sondern dass ich jeden x-beliebigen Text-Editor nehmen kann ;-)
Zum Vergrößern anklicken....

Ja, und auch alles an Fehlern reinhauen kann, was in den letzten 40 Jahren so an Fehlern reingehauen wurde, in reine Textformate. Finde ich auch total geil ... ;-) Übrigens kann man so etwas sicherlich auch mit Emacs oder Vi(m) machen, würde ich vermuten (ohne es versucht zu haben), damit dürfte doch ein Großteil der "Unix-Gemeinde" zufriedenzustellen sein.
 
Die Diskussion über Pro und Contra diverser Formate könnte sicherlich einen eigenen Thread gebrauchen, aber letztlich wird auch da nur ein Grabenkrieg ausgetragen werden, wie bei allem anderen auch (Analog/Digital, Mac/Win, Dur/Moll, Tag/Nacht, etc...).
 
SynthGate schrieb:
Ja, und auch alles an Fehlern reinhauen kann, was in den letzten 40 Jahren so an Fehlern reingehauen wurde, in reine Textformate. Finde ich auch total geil ... ;-) Übrigens kann man so etwas sicherlich auch mit Emacs oder Vi(m) machen, würde ich vermuten (ohne es versucht zu haben), damit dürfte doch ein Großteil der "Unix-Gemeinde" zufriedenzustellen sein.
Zum Vergrößern anklicken....
Naja es hindert einen ja trotzdem keinen dran, ein Syntax-Highlighting zu definieren oder gar einen eigenen, speziellen Editor dafuer zu schreiben - aber je simpler das Format ist, desto leichter ist es halt auch mit einem gewoehnlichen Texteditor zu bearbeiten. XML hingegen benoetigt hingegen je nach Komplexitaet der Daten fast zwingend einen speziellen XML-Editor. Es wird zwar gerne als "human readable" bezeichnet, aber so gesehen sind Hex-Dumps auch "human readable", und ich habe schon genuegend XML-Files gesehen, die ich eher in diese Kategorie einsortieren wuerde ;-)

Naja wie dem auch sei - Ziel des Threads war ja gerade (wenn ich es richtig verstanden habe) ein solches Format zu haben, damit man eben KEINEN speziellen Editor braucht, denn wenn man eh auf einen speziellen Editor angewiesen ist, dann kann man ja auch gleich das binaere MIDI-Format nehmen.
 
für längere Songdaten hat XML meiner Meinung nach zu viel Overhead im Verhältnis zu den Nutzdaten. Da würde ich auch eher CSV (oder um der Lesbarkeit willen etwas Tabulator-separiertes) nehmen.

Bei XML vs. JSON würde ich (neben Fragen der Validierung) auch in Betracht ziehen, ob Kommentare oder mehrzeiliger Freitextcontent benötigt werden (bei Midi wohl nur als Metadaten sinnvoll).
 
Midi-Files unterstützen grundsätzlich mehrere gleichzeitig ablaufende Tracks. Dies mit reinen Textwerkzeugen in XML oder JSON umzusetzen, wird einfach nur ein unnötig langer, qualvoller Alptraum sein.

In der selben Zeit hat man dann ne Partitur mit nem Bleistift auf Notenpapier gebracht, zwölf mal am Klavier durchgespielt und verbessert und anschließend in eine DAW eingetickert. Und ein Midi-File draus erstellt.

Nicht jedes Rad muss neu erfunden werden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Similar threads

rofilm
Die ARP 2500 Show
Antworten
11
Aufrufe
2K
Tom der Wessi
Tom der Wessi
DiSc
Synthesizer Selbstbau im Xilinx-FPGA mit MIDI-Ansteuerung
2 3 4
Antworten
100
Aufrufe
13K
DiSc
DiSc
marco93
Kernel Bug
Antworten
6
Aufrufe
1K
marco93
marco93
tholan
MIDI-Sequencer seq24
Antworten
3
Aufrufe
2K
tholan
tholan
Moogulator
  • Angeheftet
Stream 2025-03-18 Youtube, SequencerTalk Musik Videocast, 20:30
101 102 103 104 105 106
Antworten
3K
Aufrufe
669K
Moogulator
Moogulator


Neueste Beiträge

News

Zurück
Oben