Bei der Entwicklung vom BetaTouch Client Version 1 bin ich seinerzeit ziemlich schnell an die Grenzen der Verwendeten Technologie gestoßen. Was will man machen, eine Entwicklungsumgebung, für die es damals schon seit ~15 Jahren keine Updates mehr gegeben hat, …. macht mindestens mal bei der täglichen Arbeit absolut keinen Spaß mehr. Deswegen habe ich um das Jahr 2013 (sofern ich mich richtig erinnere) damit begonnen, Eine bessere Version von Grund auf neu zu entwickeln.
Zu den gewollten Merkmalen gehörte eine möglichst große Flexibilität bei der Gestaltung der Oberfläche, einfache Erweiterbarkeit um neue Funktionen, Synchronisation via Netzwerk….. und wenn’s neben Windows auch auf Linux liefe, wäre auch nicht schlecht.
Herausgekommen ist der ΒTouch Client Version 2 ( … btw: Das ist nicht der Buchstabe ‘B’, sondern ein ‘Beta’ … #truestory ) .
Es ärgert mich übrigens maßlos, jawohl, dass ich es verpeilt habe, mit den Feldern wenigstens für das Foto irgendeine Form von ASCII-Art darzustellen. Scheibenkleister! Aber egal:
Die Software ist darauf ausgelegt, per Touchscreen bedient zu werden. Sie erlaubt die Steuerung unterschiedlichster Geräte(-kombinationen) durch nicht-geschultes Personal. Die Software eliminiert das Risiko von Fehlbedienungen und ist in der Lage, Multiroom-fähige Steuerkonzepte zu implementieren. Geräteabhängige Steuerprotokolle, Regelsätze, etc. können darüberhinaus verhältnismäßig leicht hinzugefügt werden.
Das Layout hat sich sehr früh herauskristallisiert und hat sich über die letzten Jahre in der Praxis wiederholt bewährt:
Nur mal ganz grob:
- Bei Pos. 1 ist der Bereich, an dem die unterschiedlichen Layer mit ihren jeweiligen Eingabemöglichkeiten dargestellt werden.
- Bei Pos. 2 befinden sich die sog. Layer-Select Buttons. Für jedes eingepflegte Layer (xml-Datei) wird automatisch ein Button angelegt.
- Bei Pos. 3 besteht die Möglichkeit, freien Text (z.B. Support-Nummern, o.ä.) einzupflegen.
- Bei Pos. 4 kann ein Logo des Kunden eingepflegt werden.
- Bei Pos. 5 ist der Settings-Button, über den man (ggf. nach Eingabe eines Passworts) in die Einstellungen kommt.
Jede Oberfläche / jedes Layer stellt eine prinzipiell sinnvolle Gruppierung von Funktionen zur Verfügung. Im Bild ist die Oberlfäche “Simple DMX Control” aufgerufen, die eine ( rudimentäre ) Lichtsteuerung erlaubt.
Auf einem Tablet-PC macht das einen ziemlich guten Eindruck.
Tatsächlich sind einige Oberflächen ganz klassisch zuerst auf dem Papier soweit gewachsen, bis ich das Gefühl hatte, mit einem jeweiligen Layout in die richtige Richtung zu gehen.
Hier das Beispiel für eine andere mögliche Oberfläche. Im Gegensatz zur Lichtsteuerung mit sehr vielen Buttons sind hier nur 4 Fader abgebildet. Diese Oberfläche wurde verwendet, um einen digitalen Mixer mit 8 Mono-Kanälen als “4 mal Stereo”-Gerät zu betreiben. Das dazu notwendige Protokoll, die Logik, Kommunikation mit dem Endgerät, etc erfolgt komplett im ΒTouch Client.
Gleiches Gerät, anderes Beispiel für eine Oberfläche: Quellenauswahl für das Eingangssignal eines Mixerkanals. Die Geräte im Hintergrund sind eine digitale Endstufe und ein Matrix-Switch unterschiedlicher(!) Hersteller, die sich mit der Software über eine einheitliche Oberfläche bedienen lassen.
Es ist kein Zufall, dass mehrere Rechner im Bild sind: Ein Feature, das ich entwickelt habe, ist die automatische Synchronisation der Geräte untereinander. Dabei ist es nicht notwendig, ein Gerät als Server o.ä. zu konfigurieren. Die Software-Instanzen bilden automatisch ein Mesh-Netzwerk und tauschen sich miteinander aus. Das Ganze ist so geregelt, dass der unvermeidliche Broadcast-Traffic auf ein Minimum reduziert wird. Jedes Gerät hat eine – im Sekundentakt aktualisierte- “Landkarte” aller anderen verfügbaren Geräte im Speicher und sendet Steuerdaten auch nur an diese Geräte.
Jede laufende Instanz der Software kann mit unterschiedlichen Geräten verbunden werden. Alle angeschlossenen Geräte können von allen Software-Instanzen gesteuert werden – sofern gewünscht. In Kombination mit der Quasi-Mesh-Funktion ergeben sich interessante Möglichkeiten bezüglich Multiroom-Konzepten, Redundanz, etc. Im Gegensatz zu klassischer Client-Server-Infrastruktur fügt jede neue Software-Instanz dem Gesamtsystem eben ein kleines Stück Stabilität hinzu, anstatt zusätzliche Last auf eine zentrale Komponente auszuüben. Es ist eine wahre Pracht.
In Ermangelung von Geräten habe ich das hier mal grob skizziert. Ein “Device” ist ein Rechner, auf dem Software läuft, die Pfeile stellen das Mesh dar. Die möglichen Geräte (Videomatrix, Audiomixer, …) sind auf die üblichen Wege (i.d.R. seriell) an einem der Rechner angeschlossen. Es ist bei entsprechend gewünschter Konfiguration selbstverständlich möglich, z.B. vom “Device 1” den an “Device 2” angeschlossenen Sat-Receiver zu steuern. Die einzig notwendige Konfiguration besteht darin, am jeweiligen Rechner einzustellen, welches Gerät angeschlossen ist. Den Rest macht das System von alleine.
Selbstverständlich können die Oberflächen auf den Geräten unterschiedlich dargestellt werden: Z.B. kann ein Rechner so konfiguriert sein, dass man nur die Lautstärke eines Gerätes steuern kann. In einem denkbaren Technikraum (oder beim Chef … logo) steht dann ein Tablet, das alle Funktionen zur Verfügung stellt. Jedes einzelne Oberfläche kann natürlich mit einem Passwort versehen werden. Der Dialog zur Konfiguration kann ebenfalls per Passwort gesichert werden. Gemacht für Menschen.
Ganz schön pfiffig. Läuft seit einigen Jahren z.B. im FitPark Bad Oyenhausen, beim ETW in Köln und in der Steakmeisterei in Osnabrück.
An der Software selbst habe ich seit etwa 2 Jahren nichts mehr gemacht. Der Geist ist willig, allein die Zeit ist knapp. Außerdem kamen noch ein Haufen anderer Projekte hinzu, die mich davon abgehalten haben, mehr Zeit zu investieren.
Vor ein paar Monaten hatte ich mir den Quellcode noch einmal angesehen und gemerkt, dass … es … durchaus … Dinge gibt, die man … anders hätte realisieren können. Zumindest mit heutigem Wissen. Aus dem Grund arbeite ich seit einer Weile an einer neuen Version – quasi Version 3- ohne zeitlichen Druck und mit sehr sehr vielen Überlegungen bezüglich Architektur, Erweiterung etc. Werde ich hier dann demnächst in entsprechender Detailtiefe veröffentlichen.
