MIDI-Panel - welche Softwaretechnik?

Hallo,

da ich mich ja gerade im Bau meines Orgelspielschrankes befinde, möchte ich aus Platzgründen 2-4 Touchscreens (8"-Windows-Tablets, die ich günstig erworben hab) für die Registersteuerung einsetzen. Dazu brauch ich natürlich eine Software, die mir die Registerzüge auf den Tablets darstellt und mittels virtuellem MIDI-Kabel mit HW/GO unterhält.
Ich weiss, daß es hierfür schon verschiedene Ansätze gibt, aber leider nicht nichts wirklich fertiges. Bis da mal was fertiges auf den Markt kommt, wird es wohl noch eine Weile dauern... Daher möchte ich selbst was schreiben, damit ich möglichst schnell zu einem Ziel komme!

Damit auch andere HW/GO-User davon profitieren können, wollte ich nicht einfach mal schnell was zusammenstricken, sondern erst mal in die Runde fragen, welche Softwaretechnik hier (nicht nur für mich) sinnvoll wären.

Die Anforderungen an solch ein MIDI-Panel würde ich aus meiner Sicht mal folgendermaßen definieren:
- leichte Konfiguration (muss auch von Computerlaien zusammengestellt werden können)
- beliebige Anzahl und Anordnung von Touchscreens (auch Hoch- und Querformate gemischt)
- Darstellung unabhängig von der Pixeldichte der Touchscreens (skalierbare Größe der Registerzüge und Beschriftungen)
- einfache Installation
- muss mit Hauptwerk und Grandorgue funktionieren ohne Konfigurationsänderung
- sollte auf möglichst vielen Plattformen laufen
- möglichst geringer Programmieraufwand

Im Grunde würde solch eine Lösung folgende Komponenten beinhalten:
1) Bedienoberfläche (Registerzüge, Koppeln, Setzer)
2) Gateway zu HW/GO über ein virtuelles "MIDI-Kabel"
3) Serverkomponente zum Bereitstellen/Rendern der Grafiken und Konfigurationsdaten

So in etwa stelle ich mir das vor:
Es gibt eine zentrale Datenbank, mit Orgeldefinitionen. Pro Orgel gibt es ein Master-Definitionssatz, in dem die verfügbaren Bedienelemente aufgeführt sind. Also die Register mit Beschriftung und MIDI-Adresse, zugehöriges Werk der Register, Anzahl der Schweller, Koppeln usw. Auch Grafiken (für Hintergrund, Registerzug, Fußpiston sind hier hinterlegt). Aber noch keine Anordnung der Elemente. Dieser Definitionssatz ist statisch und kann oder sollte nicht geändert werden.
Dann installiert der User das Programm und wählt z.B. den Master-Definitionssatz seiner virtuellen Orgel, die er besitzt. Er kann dann über einen Assistenten eingeben, wieviel Touchscreens er besitzt und welche Auflösung diese haben, welche Werke (oder auch einzelne Register) auf welchen Touchscreens verfügbar sein sollen, in welcher Anordnung (horizontal oder vertikal), mit welcher Hintergrundgrafik (entweder standard oder auch seine eigene, die besser zum Spieltischdesign passt) usw...
Er startet nun auf jedem Touchscreen die Bedienoberfläche mit der jeweiligen Screen-ID und erhält dann die jeweiligen Komponenten auf den Touchscreens verteilt. Dank Midi-Learn in HW+GO muss er sich auch nicht mit MIDI-Kanälen und -Adressen rumschlagen...
Ideal wäre natürlich auch noch, wenn man dann denn "User-Definitionssatz" publizieren kann, die dann andere User mit gleicher Bildschirmkonstellation einfach laden und verwenden können.

Technisch gesehen gäbe es hier wohl viele Wege:

Das einfachste ist das Gateway. Es besteht eigentlich nur darin, das virtuelle MIDI-Kabel abzugreifen und die Informationen in beide Richtungen weiterzuleiten. als Übertragungsart zum Client würde ich das einfache und schnelle UDP-Protokoll wählen. Für Windows könnte ich das schnell bereitstellen, für Linux und OSX kann ich nicht dienen, weil ich nur in der Windows-Welt zuhause bin.

Für die Bedienoberfläche gäbe es verschiedene Möglichkeiten:
Version A: Windows RT App
(läuft halt nur auf Tablets oder Win8 - würde in meinem Fall reichen. Auf Win-Hauptwerk-Systemen, die 2 Touchscreens haben, kann eine App nur 1x gestartet werden, wäre ein KO-Kriterium)
Vorteil dieser App: ultraeinfache Installation und man könnte hier die Server-Komponente und die Bedienoberfläche in eine einzige App packen. Ich würde diese App mit XAML programmieren.
-> nur sinnvoll bei Spieltischen mit Win8-Tablets. Auf Windows-Orgel-PC nur einmal startbar.

Version B: Windows Desktop Applikation, also ganz normales Windows-Programm.
Hier kann ebenfalls Server und Client in eine Applikation gepackt werden. Die Installation ist in der Regel auch ganz einfach. Anwendung kann mehrmals gestartet werden (für jeden Bildschirm). Diese Software würde ich in C# mittels Dotnet-Framework programmieren (das natürlich dann Voraussetzung für die Installation ist)
- > möglich für Spieltische mit beliebig vielen Touchscreens am Windows-Orgel-PC und/oder beliebig vielen Windows 8-Tablets (mit vollwertigem Win8 natürlich). Läuft nicht unter Linux/OSX

Version C: Android App
selben Vor- Nachteile wie Version A. Hier können nur Android-Tablets verwendet werden. Orgel-PC-Touchscreens können nicht verwendet werden.

Version D: IOS App
dto. Es können nur iPads und iPhones zur Bedienung verwendet werden.

Version E: WebClient + WebServer (die wohl flexibleste Lösung)
Es muss einen Webserver geben, der die Master-Definitionssätze bereitstellt, aber auch die User-Definitionssätze und deren Aufbereitung. Es werden dann ganz einfache HTML-Dateien erstellt, die auf dem Client aufgerufen werden. Die Änderung der Grafiken der Registerzüge wird über javascript/jquery gelöst. Die Kommunikation zum virtuellen MIDI-Kabel über UDP könnte man dann wohl am einfachsten über die neuen HTML5-Websockets lösen. Somit ist eine Echtzeitsteuerung/Visualisierung möglich, die über ein Refresh der HTML-Seite eben nicht gegeben ist.
Vorteil dieser Version wäre, daß die Bedienung auf jedem HTML5-fähigen Gerät (Windows,IOs,Android,OSX,Linux) lauffähig wäre.
Allerdings gibt es hier auch eine Reihe von Nachteilen:
- Autostart der Webapp nach Hochfahren des Gerätes nicht unter allen Systemen möglich.
- Aktivierung des Vollbildmodus erfordert Benutzereingriff oder Script. Ausserdem ist es oft unschön, daß bei manchen Geräten dann immer noch Menü-Bars eingeblendet werden
- durch Gestensteuerung (fahren mit dem Finger) kann man eine Website immer um ein ganzes Stück verschieben, auch wenn sie nicht größer als eine Bildschirmseite ist. Das sieht unschön aus, wenn sich die Registertafel zur Seite schiebt
- der größte Nachteil ist die wohl aufwändigste Installation. Für den Client reicht zwar ein Browser, für den Server muss aber dann gleich IIS, Apache oder sonstiges installiert werden - für Normal-User, die Orgel spielen wollen, ein absolutes KO-Kriterium! Man könnte zwar für diesen Zweck ein Hosting anbieten, aber welcher Orgel-PC hängt schon am Internet, höchstens wenn Tablets verwendet werden. Ausserdem müsste man in diesem Fall wohl noch Sicherheitsvorkehrungen treffen.
- ziemlich hoher Programmieraufwand

Vielleicht hat jemand von euch noch andere Ideen, Ratschläge, Konzepte? Würde mich sehr interessieren.

Zitat

Original geschrieben von martin

Du erhöhst unnötig die Komplexität. Egal, welche Lösung du machst, das Ding muss bidirektional mit GO/HW verbunden werden (Feedback von Setzer). Beim Wechsel der Orgel muss das auch auf allen Geräten geichzeitig passieren.

Bidirektionale Kommunikation möchte ich auf jeden Fall haben, darum ja der Datenaustausch über das virtuelle MIDI-Kabel! Darüber bekomme ich ja dann auch die Rückmeldungen von HW/GO mit. Wie sieht das übrigens bei GO aus mit Rückmeldungen von Orgelwechsel über MIDI? In Hauptwerk bekomm ich das über SysEx-Messages mit...

Zitat

Alle Bildschirme direkt am GO/HW PC und Erweiterung der Orgel um die Zusatzpanels in GO/HW ist die simpelste Variante, wo am wenigsten schief gehen kann.

Das ist richtig! Allerdings war es in meinem Fall höchst schwierig, für meinen kompakten Spieltisch ordentliche 8"-Touchscreens herzubekommen. Tablets sind mittlerweise Massenproduktion und sind mit hochwertigen IPS-Bildschirmen ausgestattet. Ich habe lieber rechts und links jeweils zwei kleine Touchscreens übereinander, die den Spieltisch nicht so monströs aussehen lassen - und die auch die Anzeige/Anordnung von virtuellen Manubrien "orginaler" und auch ergonomischer ermöglichen.
Man sieht in vielen Spieltischen die grünen LC-Displays mit 2x16 Zeichen: Wie wäre es in diesem Fall mit einem Billig-Smartphone, über das ich per Touchscreen Stimmung, Transpose, Sample-Wechsel, Hall-Einstellungen usw.. steuern könnte?

Zitat

Die Tablets könnte man auch als über das Netzwerk angeschlossener Bildschirm nutzen - für einen Linux Master-PC würde ich wahrscheinlich etwas mit VNC basteln.

Ich weiss, daß VNC Multimonitor-fähig ist, aber kann ich mehrere VNC-Clients mit einem VNC-Server verbinden und per Parameterübergabe sagen, welches GO-Fenster ich für die Session angezeigt bekomme? Wie sieht das weiterhin mit FullScreen-Mode aus - ich möchte nicht irgendwelche Fensterrahmen und Schaltflächen vom Betriebssystem sehen - ich lege auch auf die Optik großen Wert!

Natürlich möchte ich nicht unnötige Komplexität erzeugen - eher das Gegenteil. Erstens ist es nicht gerade einfach, sich mal eben paar neue ODFs für GO geschweige denn für HW zu erzeugen. In Hauptwerk sowieso nicht möglich, wenn das Set verschlüsselt ist (oder täusche ich mich da?). Wieviele der Sets sind bereits hochformat-fähig? 2 Hochkant-Monitore rechts und links sind sowohl optisch als auch ergonomisch vorteilhafter.
Möchte ich HW und GO nutzen, muss ich 2 ODFs erstellen, was viel mehr Aufwand ist.

Ich bin nach wie vor der Meinung: Aus ergonomischen und optischen Gründen, aber eben auch für Technik-Laien könnte man mittels solcher MIDI-Panels so manchen Spieltisch benutzerfreundlicher gestalten...

Hallo Michael,

das ist ja mal interessant! Man kann also GO installieren und ODFs erstellen ohne zugehöriges Sample-Set und dann GO nur als MIDI-Panel verwenden? Gibt es für die Weiterleitung der MIDI-Daten über das Netzwerk zum GO-Sampler-PC dann einen bestimmten Netzwerktreiber oder braucht man da noch Third-Party-Treiber?

Werde mich mal intensiver mit GO auseinandersetzen, hab noch nicht wirklich viel Ahnung davon. Bisher hab ich eigentlich nur HW verwendet.

Jetzt bau ich erst mal den Spieltisch fertig, dann werde ich mir die verschiedenen Lösungsansätze für die Bedienpanels ausprobieren...