Kurze Antwort: nein, ich habe noch nix Fertiges vorzuzeigen, bin aber noch (wieder) dran und habe hoffentlich bald (Anfang Januar) eine erste Testversion.
Hier mal ein Teaser-Screenshot des ersten GUI-Entwurfs im Fullscreenmodus:
Lange Antwort:
Aaalso, wie immer, bei solchen Hobbyprojekten, ist, nachdem ich einige Zeit über die Idee nachgedacht habe, die Liste der geplanten Features erstmal explodiert.
Dann habe ich lange damit verbracht, zu schauen, ob sich das User Interface mit pyglet umsetzten lässt, bin aber irgendwann zu der Ansicht gekommen, dass ich damit zu viel Grundlagenarbeit leisten müsste und mich erstmal in OpenGL einarbeiten und praktisch ein ganzes GUI Toolkit von Grund auf programmieren müsste. Also blieb die Sache erst mal liegen.
Seit ein paar Tagen, wie's der Zufall will, habe ich die Sache wieder in Angriff genommen und setzte jetzt (nach ein paar Experimenten mit pyGTK) auf
wxPython als GUI-Toolkit und pyportmedia als MIDI-Framework. Letzteres ist jetzt Teil von
PyGame, kann aber unabhängig davon verwendet werden. Mit diesem Stack sollte es möglich sein, die Software plattform-übergreifend für Windows, OS X und Linux zu programmieren.
Wie man oben sieht, habe ich jetzt die grundlegende Struktur des GUIs fertig. Das Programm ist darauf ausgelegt, im Fullscreen-Modus betrieben und am besten per Touchscreen bedient zu werden. Natürlich wird es noch kleinere Änderungen im Layout und bei Farben, Schriftgrößen etc. geben. Wie man vielleicht sieht, habe ich mich beim GUI von Screenshots vom Korg Kronos inspirieren lassen.
Der MIDI-Stack ist auch fertig, das heißt, es gibt Funktionen, MIDI-Daten asynchron in separaten Threads zu senden und empfangen. Daten lassen sich dabei auch verzögert senden, ohne dass das Hauptprogramm sich darum kümmern muss, das Scheduling läuft dann MIDI-I/O-Thread. Im Prinzip könnte man damit also sogar einen MIDI-Player oder einen einfachen Sequenzer implementieren, aber dazu ist das Timing nicht genau genug, da gibt es noch Jitter im Bereich von 1 bis max. 10 ms.
Jetzt muss ich also nur noch die beiden Bereiche verbinden, dass heißt für die GUI-Controls Handler implementieren, die die MIDI-Daten an den MIDI-I/O-Thread übergeben, und Funktionen um die Konfiguration der GUI-Handler zu laden. Zum Schluss kommen dann natürlich noch GUI-Funktionen, um das Ganze bedienfreundlich und live-tauglich zu machen.
Als erstes werde ich wohl alle möglichen Arten von Buttons implementieren, also Trigger, On/Off-Buttons, Increment/Decrement, Momentary usw. Später sollen dann noch andere GUI-Controls wie Slider, Knobs, X/Y-Pads usw. dazu kommen. Diese Controls können dann vorkonfigurierte MIDI-Messages senden, und zwar jeweils einzelne Events oder auch Listen von Events, bei denen einzelne Events verzögert gesendet werden können. So kann man dann z.B. per Knopfdruck bei mehreren Geräten verschiedenen Programme einstellen und/oder z.B. vorher eine Sysex-Nachricht zur Modus-Umschaltung und dann verzögert Bank Select und Program Change senden. Im Prinzip also so etwas wie
TouchOSC auf iOS/Android aber halt für Desktop-Betriebssysteme und für MIDI (und ohne multi-touch). Das Programm soll
kein MIDI-Prozessor, -router, -filter o.ä. werden aber es soll zumindest irgendwann MIDI-Empfang für visuelles Feedback, Synchronisation und Steuerung geben.
Das ganze wird, wie oben erwähnt, wohl erstmal per Textdatei konfiguriert, ganz zum Schluss denke ich dann evtl. noch über einen GUI-Konfigurator nach.
Die Konfigurationdatei könnte z.B. folgendermaßen aussehen. Das GUI-Layout legt für jedes Control einen Namen fest und in der Konfigurationsdatei kann ich darüber den Controls dann Beschriftung, Farbe, etc. und Funktion zuweisen.
Code:
[button_1]
enabled = yes
type = pushbutton
label = Panic!
Send AllSoundOff + Ctl Reset
on all channels
label_align = top left
image = exclamation.png
image_align = bottom right
on_up = [ AllSoundOff(channel=-1), ResetAllControllers(channel=-1) ]
[button_2]
...
So viel erstmal, nach Weihnachten dann hoffentlich mehr...
Chris
