Nachdem ich mein ShortPad erstellt habe, aber bisher zu wenig genutzt habe, überlegte ich, warum ich es so wenig nutzte. Einerseits sind mir die LEDs manchmal zu hell, wenn sie dunkler sind, sind sie jedoch tagsüber schwerer zu erkennen. Zudem ist die Möglichkeit des Feedbacks gering und auch das Thema Shortcuts ist nicht optimal gelöst.
All das waren Kompromisse, welche ich beim Erstellen der Software eingegangen bin. Allerdings liegen zwischen dem Erstellen des ShortPads und heute gut 1,5 Jahre, in denen ich immer mehr Erfahrung im Programmieren gesammelt habe. So konnte ich meine Kenntnisse in C# durch die Programmierung in der Spiele-Engine Unity verbessern. Mehr dazu siehe andere Projekte. Durch meine besseren Kenntnisse beschloss ich, einen Versuch zur Erstellung einer Software zur Verwaltung des ShortPads zu erstellen, den ShortPad-Controller.
Welche Features soll das Programm können?
Was ist dafür nötig?
Damit diese Features einigermaßen erstellt werden können, ist eine Planung nötig. Diese dient einer einfachen Erarbeitung der benötigten Skills und einer einfachen Überprüfung des Machbaren. Theoretisch sollte es machbar sein, große Hersteller schaffen das ja auch. Allerdings ist hier eher die Frage, ob ich das schaffe. Betrachtet man die Features, so sind grundsätzlich fünf Themen wichtig. Bidirektionale Kommunikation von ShortPad und PC-Programm, Hintergrundausführung am PC, Tasks, das Speichern von lokalen Daten und das UserInterface. Für die bidirektionale Kommunikation entschied ich mich schnell für die serielle Kommunikation. Diese ist auf Seiten des Arduinos einfach einzubauen und sollte in C# ebenfalls einfach einzubauen sein. Die Ausführung des Hintergrundprogramms ist Abhängig von dem Programm, welches ich nutze. Das Thema Tasks habe ich bereits in Unity verwendet um beim Projekt StringArt-Generator Multitasking zu implementieren, soweit ist dies auch bekannt. Das Speichern von Daten auf dem PC ist theoretisch kein Problem. Hier wird der einzige Knackpunkt die Verarbeitung der Daten zu einer JSON-Datei sein, da ich nicht auf die JSON-Utilities von Unity zugreifen kann. Der Punkt des grafischen UI führte mich dann anschließend zu der Verwendung von Windows WPF, welches ein recht einfaches Layout leicht erstellen lässt.
Ein erster Schritt – Kommunikation
Das gesamte Projekt steht und fällt mit der Kommunikation. Als erstes erstellte ich ein Skript, welches die verbundenen Ports erkennt und sich mit Geräten verbindet. Nachdem das funktionierte, benötigte ich eine Art Protokoll, damit ich sichergehen kann, dass ich nur mit einem ShortPad kommuniziere und nicht mit anderen Geräten. Ich habe mich dabei dafür entschieden, dass ich beim Ausprobieren der Verbindung anfrage, ob das Gerät ein ShortPad ist. Bestätigt das Gerät dies, so ist alles gut und es wird als solches geladen und kann nun für die weitere Kommunikation verwendet werden. Falls es nicht oder mit einer falschen Zeichenfolge antwortet, wird der nächste Port ausprobiert. Natürlich musste ich hierfür den Arduino-Code ebenfalls anpassen.
Nachdem dies soweit funktioniert und ich nun mit dem ShortPad kommunizieren kann, ging es an das weitere ausprobieren. Schnell musste ich feststellen, dass es zwei Szenarien gibt, in denen meine Methode nicht gut genug ist. Einerseits reicht es aus, wenn die Anwendung neu gestartet wird, während das ShortPad verbunden ist, geht der Arduino noch von einer Verbindung aus und zeigt mir dies nicht an. Zudem verweigert es ein erneutes Senden der ShortPad-Bestätigung, was den erneuten Verbindungsaufbau verhindert. Zum Anderen kann das ShortPad ausgesteckt werden, die Verbindung ist nicht mehr vorhanden aber mein Programm denkt, sie sei es. Letzteres ist einfach zu überprüfen. Mit einem Task überprüfe ich, ob der aktuelle Port noch verfügbar ist, falls nicht startet die Suche nach aktuell verbundenen Geräten. Somit kann das Programm schnell herausfinden, ob die Verbindung noch besteht. Da beim Ersten Problem die Verbindung ShortPad-PC noch besteht, nur der Gesprächspartner (Programm) nicht mehr da ist, musste ich hier etwas kreativer werden. Deshalb sendet das Programm beim Schließen ein EXIT-Signal an das ShortPad, welches diesem mitteilt, dass die Verbindung aufgehoben wird. Somit geht das ShortPad wieder in den Idle-Betrieb und wartet auf eine Verbindungsanfrage.
Obwohl ich zum aktuellen Zeitpunkt nur mein 33-Key-ShortPad habe, mir aber durchaus vorstellen kann, in Zukunft weitere zu erstellen, habe ich dies ebenfalls gleich in die Kommunikation eingebaut. Direkt nach der Bestätigung des ShortPads wird eine Versionsanfrage gesendet. Diese beantwortet das ShortPad einerseits mit der Version (z.B. 33-Key) und einer eindeutigen ID.
Das Duo – Versionshandling & Grundstruktur
Damit ich möglichst viel Flexibilität für zukünftige Anpassungen der ShortPads habe, erstellte ich nun die Grundstruktur. Diese besteht daraus, dass ein ShortPad ein Objekt ist, welches aus Keys besteht. Dabei ist ein Key eine virtuelle Abbildung einer reellen Taste. Ebenso wird die ID sowie das Layout der Tasten gespeichert. Das Layout ist im Konstruktor definiert, sodass hier über die Version verschiedene Layouts geladen werden können. Jeder Key hat nun eine Sammlung an Reaktionen. Es gibt verschiedenste Reaktionen, welche den Anforderungen entsprechen. Um ein paar Beispiele zu nennen: Anwendung starten, Skript, Shortcut.
Die serielle Kommunikation wurde nun so angepasst, dass das ShortPad keinen Shortcut mehr sendet, sondern den Index (laufende Nummer) der gedrückten Taste. Diese wird an das virtuelle ShortPad weitergeleitet und wandert dort über den virtuellen Key zu den Reaktionen. Diese werden nun ausgeführt. Die Grundstruktur steht.
Für was benötige ich nun ein Versionshandling und die ID? Grundsätzlich könnte ich das Ganze auch ohne machen, allerdings wäre dann der Featureumfang geringer. Da ich mehrere ShortPads (aktuell einzeln, später eventuell auch parallel) betreiben möchte, müssen die verschiedenen Einstellungen gespeichert und geladen werden. Außerdem muss das richtige ShortPad (sollte es mal andere Versionen wie ein 9-Key-ShortPad geben) geladen und die richtigen Voreinstellungen (wie die Keyanordnung) getroffen werden.
Hierzu wird die Antwort der Version & ID ausgewertet. Sind keine Settings zu einer ID vorhanden, so werden die passenden Voreinstellungen zur ShortPad-Version geladen. Ansonsten werden die entsprechenden Settings geladen.
Der dritte Schritt – Speichern/Laden der Settings
Ich konnte erst einmal mein Wissen des Speicherns von Dateien anwenden. Nach kurzem erstellte ich die benötigten Ordner und Dateien bei Bedarf. Allerdings zeigte sich schnell ein Problem beim Erstellen von JSON-Dateien. Meine selbst erstellten Interfaces und Klassen erwiesen sich als durchaus schwer umzuwandeln. Hauptproblem besteht hierbei in den jeweiligen Unterklassen der Reaktionen (Klassen welche das Interface der Reaktion eingebunden haben sowie ihre Subklassen).
Das Quartett – Ein erstes UI
Nun kommt der Teil, in dem ich mich selbst unsicher fühle. Ich bin kein Mensch, der kreative UIs erstellt, geschweige denn kreativ ist. Für mein UI entschied ich mich dafür, auf der einen Seite das Keylayout nachzubilden und beim drücken auf einen Key die Reaktionen auf der anderen Seite zu öffnen. Dort sollen dann anschließend alle Einstellungen vernehmbar sein und bei Änderungen diese direkt gespeichert werden. Über ein Dropdown am oberen Ende soll eine Auswahl zwischen verbundenen ShortPads getroffen werden können.
