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.
)
rechts und links der Orgel in Ohrenhöhe konstruieren. Ich werde mich dabei auf eine ganz einfache Variante beschränken: Einfach 2 L-förmige Konsolen, die oben in die Orgel eingehängt werden können und wo das Auflagebrettchen vielleicht noch in der Höhe verstellbar ist. Dort können dann die Nahfeldmonitore installiert werden. Mal sehen...