MIDI-P the modular MIDI Processor

[Leef]

Ich möchte die Gelegenheit nutzen und mein kleines Midi Projekt mal etwas näher beleuchten. Ich arbeite schon eine Ewigkeit daran, allerdings war die erste Version mehr als Proof of Concept gedacht und hat sehr viele Einschränkungen.

Was ist MIDI-P?
MIDI-P ist Programm mit dem sich Midi Daten verändern oder erzeugen lassen.
Dabei wird großer Wert auf Flexibilität und Benutzerfreundlichkeit gelegt.

Wie funktioniert MIDI-P?
Jedes Element wird durch Module dargestellt, die sich untereinander verbinden lassen. Die Verbindungen stellen dabei den Signalfluß dar. Die einzelnen Module haben unterschiedliche Funktionen und können in ihren Parametern verändert werden.

Was kann man damit nun z.B. machen?
Damit läßt sich unter anderem der Midi Kanal dynamisch ändern (z.B. anhand von Anschlagstärke oder Notenwert), Keyboards lassen sich in Zonen splitten/layern, es können weitere Noten generiert werden und somit kann z.B. in einer Zone für jede Note ein Akkord erzeugt werden, die Anschlagsdynamik kann auf einen festen Wert gelegt oder angepaßt werden - prinzipiell läßt sich jeder nur denkbare Midi-Wert ändern.

Wo kann ich MIDI-P runterladen?
MIDI-P befindet sich im frühen Teststadium, es wird immer wieder kleine und größere Updates geben. Im Moment geht es hauptsächlich darum zu schauen, ob das Programm stabil läuft und Feedback zu sammeln. Mit dabei sind eine kurze Dokumentation und einige Beispiele. Die Dokumentation läßt sich übrigens direkt aus der Box heraus lesen. Das Programm läuft unter Windows.

Zu finden unter https://www.box.com/s/19533ee158f8fad97b54

Viel Spaß!

 

[Leef]

Und nun kommt auch schon das erste Problem. Ich bin im Moment dabei das Modify Modul neu zu schreiben. Das Modul hat die Aufgabe die Werte eines Midi Ereignisses zu ändern. Das heißt es wird z.B. die Anschlagstärke verändert.

Im einfachsten Fall sieht es also so aus:

Velocity = 40

Hierbei wird die Anschlagstärke auf einen festen Wert gesetzt. Will man die Stärke relativ ändern, braucht man etwas mehr:

Velocity = Velocity + 12

Nun kann es aber sein, daß die Anschlagstärke z.B. halbiert werden soll. Oder von 100 auf 127 skaliert. Oder gar mit einem Offset versehen werden soll, damit ein Minimum nicht unterschritten wird. Es wird also komplexer:

Velocity = 0.5 * Velocity + 63

Nun könnte man aber noch auf die Idee kommen, einen zweiten Parameter mit ins Spiel zu bringen. Z.B. die absurde Idee die minimale Anschlagstärke durch die Noten Nummer vorzugeben. Das sieht dann so aus:

Velocity = 0.5 * Note + 0.5 * Velocity

Es gibt also allerlei Szenarien, die bereits mit einer einfachen Modify Zeile Abgehandelt werden können. Um mehrere Parameter mit einem Modul zu verändern, lassen sich weitere Zeilen hinzufügen, die dann nacheinander abgearbeitet werden.

1. Note = Velocity
2. Velocity = 100

Dies würde die gespielte Note von der Anschlagstärke abhängig machen und die eigentliche Anschlagstärke mit einem festen Wert belegen. Mit einem einzigen Modul läßt sich also schon extrem viel anstellen.

Leider ist mir das ganze zu unübersichtlich geworden. Deshalb bitte ich um Ideen, wie man dieses Prinzip möglichst übersichtlich umsetzen kann. Im Moment habe ich folgende Lösung:

[Was] [Wie] [Womit]

z.B. [Note] [+] [20]

Wobei [Was] und [Womit] jeweils mit einem Skalierungsfaktor und einem Offset versehen werden können.

z.B. [0.5*Note] [+] [0.5*20]

Das macht jedoch erst Sinn, wenn [Womit] ein weiterer Parameter ist.

z.B. [0.5*Note] [+] [0.3*Velocity + 20]

Leider ist das für den Nicht-Programmierer sowas von unübersichtlich... Was könnte man hier ändern?

 

[JohannesD]

Hi,
cooles Projekt... Die Frage ist, ob man solche komplizierten Konstruktionen oft braucht und ob es deshalb der Übersichtlichkeit zuliebe nicht besser wäre, die Möglichkeiten eines einzelnen Modifiers zu begrenzen, sodass solche komplexeren Dinge nur durch ein Hintereinanderschalten möglich sind. Vielleicht kann man ja ein Advanced-Modifier machen, bei dem man alles per Code eingeben kann. Bei unübersichtlichen Sachen ist das nämlich (für mich) immernoch das Übersichtlichste

Es wäre spitze, wenn du das Ganze nicht nur als Standalone sondern auch als vst anbieten würdest, dann wäre es nämlich genau das, was ich schon länger suche bzw. demnächst selbst programmieren wollte.

Viele Grüße,
Johannes

 

[Leef]

Die Idee ist natürlich auch gut, zwei verschiedene Modifier Module anzubieten. Ein einfaches und ein komplexes. Ich hatte zuerst über eine Option nachgedacht "Simple" und "Advanced" Interface. Aber deine Lösung gefällt mir fast noch besser. Ein VST wird es vorerst nicht geben, weil ich mich noch nicht damit beschäftigt habe. Ich will es aber nicht ausschließen.

 

[synthos]

Hi,

Man könnte die ganze Formel weiter aufdröseln (dein letztes Beispiel, siehe Anhang).

Meine Idee wäre, dass im GUI jede Operation auf einer Zeile steht, wobei die Zwischenresultate in den folgenden Zeilen als Eingabe zur Verfügung stehen. Komplexere Formeln benötigen mehr Zeilen. Das Resultat von Zeile n kann als "in" in den folgenden Zeilen verwendet werden. Man würde dann z. B. schreiben/klicken:

0.3   Velocity   *        (Zwischenresultat i1)
0.5   Note       *        (Zwischenresultat i2)
i1    20         +        (Zwischenresultat i3)
i2    i3         +        (Zwischenresultat i4 == Endresultat, da letzte Zeile)

Wenn alle Operatoren binär sind (wie + und *), kann man die Spalte mit den Operatoren (hier 3.) auch zwischen den Argumenten platzieren.

Grüsse,
synthos

 

[Leef]

Im Moment tendiere ich zu der vereinfachten Lösung wobei ich ggf die Formel auf drei Operanten erweitern werde. Das kommt der klassischen Schulmathematik auch recht nah.

c = a + b

Also im Grunde auch das, was du anbietest. Ich werde neben den normalen Midi Werten auch eigene Felder z.B. User1 User2 etc. einbauen. Darauf ließen sich dann Zwischenergebnisse speichern. Komplexe Operationen werden durch Nacheinanderausführung realisiert. Dann könnte es so aussehen:

User1 = Velocity * 0.3
Note = User1 + 20
...

Wobei noch die Frage im Raum steht, ob die Skalierungsfaktoren und Offsets drinbleiben oder rausfallen? Immerhin spart man damit eine Menge Zeilen und im großen Maßstab auch Zeit bei der Modulabarbeitung. Aber es verwirrt stark denke ich. Schwierig, schwierig.



Edit: So sieht es im Moment aus. Ich denke ich werde die Skalierung / Offset Geschichte per [+] Button einblendbar machen. Das sollte eigentlich nicht allzukompliziert für den Benutzer aussehen. Kennt man ja z.B. aus Cubase, weitere Funktionen lassen sich bei Bedarf aufklappen.

Sind weder Skalierung noch Offset eingetragen, werden sie in der Darstellung ausgeblendet. Das selbe gilt für den zweiten Operanten somit ist es möglich auch Geschichten in der Form Note = Velocity darzustellen.

 

[JohannesD]

Ich werde neben den normalen Midi Werten auch eigene Felder z.B. User1 User2 etc. einbauen. Darauf ließen sich dann Zwischenergebnisse speichern. Komplexe Operationen werden durch Nacheinanderausführung realisiert.

Sehr gut wäre es, wenn es Felder geben würde, die global sind. Dann wäre zum Beispiel Folgendes möglich: Mit einem Regler stellt man die Velocity ein, der Wert wird global gespeichert. Bei jedem Tastendruck wird die Velocity dann durch diesen Wert ersetzt.

Viele Grüße,
Johannes

P.S. Es gibt ein Tutorial auf http://web.redio.de/, bei dem ein einfaches VST programmiert wird. In deinem Fall müsste es ja noch nicht mal Töne ausgeben, sondern nur MIDI Daten verändern. Dabei fällt mir gerade auf, dass es eigentlich kein VST-Instrument (also kein VSTi), sodern ein VST-Effekt sein muss, weil du ja Daten manipulierst und dann wieder ausgibst.

 

[Leef]

Sehr gut wäre es, wenn es Felder geben würde, die global sind. Dann wäre zum Beispiel Folgendes möglich: Mit einem Regler stellt man die Velocity ein, der Wert wird global gespeichert. Bei jedem Tastendruck wird die Velocity dann durch diesen Wert ersetzt.

Das ist für später geplant. Allerdings geht meine Idee für dieses Szenario eher andere Wege. Man kann jedem Controler beliebig viele Parameter aus den einzelnen Modulen zuweisen, ähnlich einer Modulationsmatrix. Ich plane soetwas wie einen "live Modus", wo die Zuordnung Parameter und aktueller Wert groß dargestellt werden. Die Verschaltung der Module ist dabei ja eher unwichtig.

Danke für den VST Link. Das schaue ich mir definitiv mal an, aber zuerst müssen die Grundlagen fertig sein. Es fehlt noch an zwei kritischen Modulen, dem Modify und dem Condition Modul. Also etwas abfragen und dann verändern. Damit sollte man schon etwas anfangen können. Dann geht ersteinmal öffentliches Testen und die Bugsuche los.

Ich habe bereits einen Konsolenmodus eingebaut, um das System z.B. auf leistungsschwachen PCs trotzdem nutzen zu können. Dabei werden die Module geladen und verarbeitet, aber nicht dargestellt. Eventuell auch sinnvoll, wenn man einen Workaround erstellt hat den man einfach per Batch mit aufruft.

 

[HaraldS]

Ich habe mal für den Privatgebrauch eine eigene Masterkeyboard-Software in Visual C++ programmiert. Die nimmt Daten von beliebig vielen MIDI-Ports entgegen, modifiziert sie nach vorgegebenen Regeln und gibt sie auf beliebig viele Ports wieder aus. Es sind dann Setups speicherbar, die per BankSelect/ProgramChange von bestimmten Ports aus aufgerufen werden können und neben den Modifizierungsregeln noch Initialisierungsdaten sowie Daten beim Verlassen des Setups senden können. Als Modifizierungsregeln gab es auch Velocity-Änderungen.

Da ich am gleichen Punkt stand und entscheiden mußte, welche Regeln ich zulasse, und das ganze möglichst variabel halten wollte, habe ich auf arithmetische Operationen verzichtet und direkt mit Tabellen gearbeitet. Der Eingabe-Velocitywert wird also als Index in eine Tabelle verwendet, aus der der Ausgabe-Velocitywert gelesen wird. Es werden also 127 Balken dargestellt, und mit der Maus kann man diese Tabelle bearbeiten und damit Velocitykurven malen. Der Eingabewert 0 muß allerdings natürlich immer auf den Ausgabewert 0 festgelegt bleiben, weil Velocity=0 ja im MIDI-Standard gleichbedeutend mit Note off ist.

Insgesamt ist das Arbeiten mit Tabellen IMHO dem berechnenden Ansatz überlegen, weil es variablere Ergebnisse liefert und Ein- und Ausgabewerte schneller in einen gedanklichen Zusammenhang zu bringen sind: man sieht schneller, was man beim Spielen auf der Tastatur als Ergebnis erwarten kann.

Harald

 

[Leef]

Diesen Ansatz werde ich ebenfalls einbinden, z.B. bei besagten Anschlagskurven. Allerdings möchte ich zusätzlich noch einfache Algorithmen einführen, es gibt unter anderem bereits die Möglichkeit Schleifen und ähnliches zu erzeugen. Dort ist mit festen Tabellen dann leider wenig zu machen.

Das ist im Moment allerdings noch alles Zukunftsmusik, ich sitze noch am Modify Modul. Überhaupt wird später noch eine Menge überarbeitet werden. Es fehlt mir dazu einfach an Erfahrung. Ich bin in erster Linie Programmierer und erst danach Hobbymusiker. Freue mich schon auf rege Diskussionen

 

[strogon14]

@Leef: Du könntest auch mal Ideen mit dem Autor von mididings austauschen, der auch hier im Forum unterwegs ist. Mididings is rischtisch goil aber leider nur für Linux/ALSA.

 

[Leef]

Leef, deinem Vorhaben wünsche ich allerdings einen hohen Verbreitungsgrad, ich habe die Vorversion ERSA hier mal ausprobiert und bin beeindruckt, insbesondere von der Bedienoberfläche.

Danke! Leider kämpfe ich aktuell mit genau dieser Sache. Ich bekomme hier lauter kleine Parametermonster, die ich irgendwie bändigen muß. Eventuell kann ich noch Farben einsetzen um das Ganze etwas zu entschärfen, mal sehen.

 

[fubar]

Noch ein bißchen was zum eigentlichen Thema dieses Threads:

Sind Offset und Skalierung der Werte wirklich so wichtig/häufig, daß es sich lohnt, dafür zusätzliche Eingabefelder zur Verfügung zu stellen? Das selbe sollte ja auch durch Hintereinanderschaltung mehrerer Modifier realisieren lassen. Oft genug hat man sowieso Situationen, wo eben gerade Offset oder Skalierung schon die eigentliche Rechenoperation ist, und man sonst gar nichts weiter braucht.

Ist es möglich oder angedacht, daß man mehrere Modifier zu einem größeren Modul kombinieren kann? Also quasi als wiederverwendbare Bausteine, ein bißchen so wie Subpatches in Pd, falls dir das etwas sagt? Spätestens dann könnte man die einzelnen Modifier sehr einfach halten, und komplexere Funktionen wären durch Kombination mehrerer Modifier realisierbar.

 

[Leef]

Meine Grundidee war es, die einzelnen Module so flexibel wie möglich zu gestalten um somit die Gesamtanzahl an Modulen zu reduzieren. Alles was innerhalb eines Moduls verarbeitet wird, ist schneller als der Overhead durch die Weiterleitung und erneute Aufbereitung in einem zweiten Modul. Ja, ich spiele mit der Idee Module zusammenzufassen, allerdings kommt hier genau das Problem zum tragen. Wenn ich ein Modul aus 20 kleinen zusammenfasse, kann ich das Modul auch gleich selbst schreiben und generell hinzufügen.

Ich habe mich leider noch nicht näher mit mididings beschäftigen können, hast du dort ebenfalls grafische Sachen eingearbeitet? Auf den Screenshots sind ein paar zu sehen, aber das sieht mir nach weiteren externen Programmen aus oder?

Mein Projekt ist im Moment eher "Grundlagenforschung". Ich möchte austesten was wirklich sinnvoll ist und was zwar auf dem Papier gut aussieht, aber praktisch kein Mensch braucht. Ich freue mich vor allem über die persönliche Herausforderung so ein System zur Abwechslung mal grafisch zu entwerfen.
Besonders schlimme Kopfschmerzen werde ich wahrscheinlich bekommen, wenn es um den Programmfluß geht. Im Moment wird lediglich der Signalfluß betrachtet. Stichwort Rückkopplung, Schleifen, Oszillatoren usw. Es spricht ja nichts dagegen Module zu entwerfen, die getriggert werden können und selbständig getimte Aktionen ausführen.

Aber das ist wie gesagt alles Zukunftsmusik, ich muß ersteinmal meine kleinen Grundmodule fertigbekommen. Die Diskussion hier hilft mir dabei ungemein, viele Sachen sieht man selbst gar nicht. Stichwort Wald vor lauter Bäumen...

 

[Distance]

Die Diskussion über Hardware-Umsetzungen eines Midi-Prozessors wurde ausgelagert: https://www.musiker-board.de/techni...07025-hardware-midi-prozessor-aus-midi-p.html

 

[fubar]

Meine Grundidee war es, die einzelnen Module so flexibel wie möglich zu gestalten um somit die Gesamtanzahl an Modulen zu reduzieren. Alles was innerhalb eines Moduls verarbeitet wird, ist schneller als der Overhead durch die Weiterleitung und erneute Aufbereitung in einem zweiten Modul. Ja, ich spiele mit der Idee Module zusammenzufassen, allerdings kommt hier genau das Problem zum tragen. Wenn ich ein Modul aus 20 kleinen zusammenfasse, kann ich das Modul auch gleich selbst schreiben und generell hinzufügen.

Ok, der Ansatz ist mit Sicherheit auch nicht falsch, es hat eben alles Vor- und Nachteile. Bei mididings bin ich quasi den genau entgegengesetzten Weg gegangen, daß die einzelnen Module so klein wie möglich sind. Wenn man als Ergebnis dann sehr viele Module nacheinander verarbeiten muß, dann muß genau das eben entsprechend effizient implementiert werden.

Natürlich kannst du ein komplexeres Modul auch mal eben schnell schreiben, aber kann das auch ein Benutzer? Bei mididings besteht auch ein großer Teil der mitgelieferten Module aus mehreren kleineren. Zugegeben, ein kleines bißchen Python muß man können, um eigene Module zu schreiben, aber zumindest den in C++ geschriebenen Kern des Programms muß man dafür nicht anfassen.

Ich habe mich leider noch nicht näher mit mididings beschäftigen können, hast du dort ebenfalls grafische Sachen eingearbeitet? Auf den Screenshots sind ein paar zu sehen, aber das sieht mir nach weiteren externen Programmen aus oder?

Genau, mididings selbst hat keinerlei grafische Oberfläche. Das einzige mitgelieferte GUI ist livedings (2. Screenshot), damit läßt sich aber nur zwischen verschiedenen Patches umschalten. Zum Erstellen von Patches führt bisher kein Weg an Python-Skripten und/oder der Kommandozeile vorbei. Besonders einsteigerfreundlich ist das vielleicht nicht, aber wenn man einmal dahintergestiegen ist, sind sehr komplexe Sachen mit relativ wenig Aufwand möglich.

Besonders schlimme Kopfschmerzen werde ich wahrscheinlich bekommen, wenn es um den Programmfluß geht. Im Moment wird lediglich der Signalfluß betrachtet. Stichwort Rückkopplung, Schleifen, Oszillatoren usw. Es spricht ja nichts dagegen Module zu entwerfen, die getriggert werden können und selbständig getimte Aktionen ausführen.

Falls es dich beruhigt, Schleifen sind auch in mididings bisher nicht möglich, und es ist sehr fraglich, ob ich sowas jemals einbauen werde. Irgendwie wäre das schon ein ziemlich cooles Feature (wenn nur die Kopfschmerzen nicht wären), aber wofür braucht man das überhaupt? Der einzige konkrete Anwendungsfall der mir jetzt einfällt wäre sowas wie ein Arpeggiator, und selbst dafür reicht eine relativ kleine Menge von erlaubten Konstrukten.

Irgendwo stellt sich dann früher oder später die Frage, ob man einen MIDI-Prozessor programmieren will, oder eine Touring-vollständige Sprache. Letzteres gibt es ja auch schon zur Genüge, und wenn es grafisch sein soll, dann halt Pd o.ä...

 

[wrdlsn]

Interessante Sache, die Du da vorhast.
Aber kennst Du den "Logical Editor" von Cubase? Oder den "Interactive Phrase Synthesizer" - ebenfalls in diesem Sequenzer. Beide Module waren schon Ende der Achtziger Jahre in den Atari-Versionen der Software dabei und können, soweit ich das hier sehe, genau das, was Du willst: beliebigen Midi-Input zu beliebigem Midi-Output verwursten. Meine Frage: Was wird mit Deinem Programm möglich sein, was diese Module nicht können? Oder geht es Dir nur um eine zeitgemäße Variante davon (mit Anfassen und Rumschieben und virtuelle Kabel stöpseln und so ...)?
Noch etwas zur Programmierung: Die bereits angesprochene Tabellenform, also eine Matrix, erscheint mir in jedem Falle geeignet, komplexe Transformationen visuell erfassbar zu machen. Man könnte das weiterspinnen - etwa in die dritte Dimension, also einen Parameter-Kubus etwa. Oder aber man bleibt bei der zweidimensionalen Matrix, und legt mehrere davon an, die dann geschichtet werden können, also Transformations-Layer ...
Was die Parameter-Werte betrifft, täte man vielleicht gut daran, sich von den begrenzten MIDI-Bytes zu trennen und alle Berechnungen abstrakt in einem größeren Zahlenbereich durchzuführen - etwa Integer oder Long, vielleicht auch Float für Komma-Prozentangaben etc. - und erst am Ende in den fixen Zahlenbereich der MIDI-Controller-Welt rücktransformieren (bei gleichzeitigem Check auf Max- und Min-Werte).

Bei der Cubase-Konkurrenz Emagic bennent man diese Funktion als RMG - Realtime Midi Generator. Ist auch so ein Zauberding, was alles Midi-mäßige verschwurbelt und zerknäueln kann ...

 

[HaraldS]

Aber kennst Du den "Logical Editor" von Cubase? Oder den "Interactive Phrase Synthesizer" - ebenfalls in diesem Sequenzer. Beide Module waren schon Ende der Achtziger Jahre in den Atari-Versionen der Software dabei und können, soweit ich das hier sehe, genau das, was Du willst: beliebigen Midi-Input zu beliebigem Midi-Output verwursten.

Der Logical-Editor und der Intercative Phrase Synthesizer in Cubase haben aber keine MIDI-Ports als Parameter. Man kann also nicht bestimmte Daten von einem bestimmten Eingang auf bestimmte Daten bestimmter anderer Ausgänge routen bzw. ändern. Das schränkt ein (zumindest was meine Zielrichtung mit Masterkeyboard-Setups angeht).

Harald

 

[Leef]

Meine Frage: Was wird mit Deinem Programm möglich sein, was diese Module nicht können? Oder geht es Dir nur um eine zeitgemäße Variante davon (mit anfassen und rumschieben und virtuelle Kabel stöseln und so ...)?

Mein Programm ist zum einen kostenfrei und zum anderen bin ich im Moment für viele Einflüsse offen. Es ist mein Ansatz das ganze möglichst visuell und intuitiv zu gestalten, das kann man schon so sagen. Es gibt auch andere Projekte in der Richtung, MPL Midi Programming Language, Mididings oder Building Blocks, aber irgendwie habe ich doch meine eigene Vorstellung wie ich an das Problem rangehen möchte. Und mehr Auswahl schadet sicher nie

Die Geschichte mit der Berechnung ist übrigens gar nicht mal so einfach gelöst. Man nehme folgendes Beispiel:

Velocity = [Velocity + 24] - [Note] (Über den Sinn läßt sich jetzt mal streiten...)

An welcher Stelle soll die Normierung vorgenommen werden? Kommt die Velocity+24 über 127, wird sie auf 127 normiert. Und dann die Note abgezogen. Es kann aber auch sein, daß Velocity+24 - Note gar nicht über 127 gekommen wären. Das Ergebnis beider Operationen ist grundverschieden! Ich denke hier kann man z.B. eine Option einführen die der Nutzer setzen kann wie er mag. Ob nun jede einzelne Komponente limitiert wird oder erst das Gesamtergebnis.

Eine kleine Sache zum Status, ich bin im Moment arg in Projekte eingespannt und MIDI-P steht hinten an, trotzdem komme ich langsam voran. Hier mein Vorschlag für die Edit Felder.

1. In der einfachsten Form erfolgt die Zuweisung Parameter = Wert.
2. Durch Aufklappen der Parameter läßt sich dann auch Parameter = Parameter zuweisen.
3. Dazu lassen sich dann die weiteren Einstellungen (Multiplier und Offset) anzeigen, z.B. um den Parameter zu skalieren.
4. Erst wenn ein Rechenoperator ausgewählt wurde erscheint die zweite Hälfte.
5. Es läßt sich ebenfalls zwischen Wert und Parameter wählen.
6. Und zum Schluß das fertig "aufgeklappte" Parametermonster

 

[Leef]

So langsam nimmt es Form an... fehlen noch die Buttons / Funktionen um Zeilen zu verschieben und zu löschen.
Der Teufel steckt wie immer im Detail...