Projekt MIDI-Steuerung

Fachbereiche: Web-Applikationen, Backend-Service, Linux

Um mehrere Musikeffektgeräte gleichzeitig und bequem steuern zu können, habe ich mit Hilfe der praktischen Erfahrung meines Vaters, der als begeisterter Amateur-Musiker eine akustische Gitarre mit Tonabnehmer spielt, einen soliden Steuerungscomputer entwickelt und daraus ein reifes Produkt erschaffen. Es kann als Reaktion auf neue Wünsche jederzeit flexibel weiterentwickelt und auch an die Bedürfnisse von Profi-Musikern angepasst werden.

Die Steuerung kann sowohl mit dem Fuß als auch mit der Hand erfolgen.

Anstoß für die Entwicklung eines neuen Produkts war das Fehlen einer Steuerung auf dem Markt, die eine übersichtliche Benutzer-Oberfläche und die folgenden wichtigen Funktionen zu bieten hat:

• Unterbringung verschiedener MIDI-Befehlstypen (z.B. Programmwechsel und Bypasswechsel) in einem Preset
• zentrale Konfiguration der individuellen MIDI-Daten je Effektgerät, auf die von allen Steuer-Presets aus einheitlich zugegriffen werden kann

Weitere Details:

• Frontend auf dem iPad, für edelste Touch-Hardware
  • maximiertes Benutzer-Erlebnis
  • es können auch beliebige andere Tablets und sogar das Smartphone für die manuelle Bedienung genutzt werden
• Die Kommunikation mittels MIDI-Standards erlaubt den Anschluss beliebiger MIDI-fähiger Geräte.
  • eingangsseitig: Steuergeräte
  • ausgangsseitig: Effektgeräte
• In Steuer-Presets, die auf dem Tablet-PC konfigurierbar sind, können verschiedene Effekt- und Klangszenarios zum Abruf vorbereitet werden.
• Benutzereinstellungen sind in übersichtlichen JSON-Dateien gespeichert
  • menschenlesbar
  • schnelles Backup/Restore
  • einfach versionierbar
• Betriebssystem-unabhängiges Backend dank Java Virtual Machine
  • neben dem Linux-basierten Steuerungscomputer, für den das System entwickelt wurde, können ebenso Windows- und MacOS-basierte Computer für den Betrieb genutzt werden
• immer störungsfrei im Einsatz, und das seit 2018

Grundsolides Produkt

Ursprünglich in Angular.js geschrieben, ist der Quellcode heute noch immer gut gepflegt, wartbar und wird auch aktiv weiterentwickelt, wie am ersten Tag. Damit wird er der wichtigen Anforderung der Langlebigkeit gerecht, und hat bereits unzählige Angular-Versionen überlebt, ohne dass eine aufwändige Umstellung von Angular.js auf das neuere Angular jemals notwendig gewesen wäre. Es musste also nicht wegen Googles Launenhaftigkeit kostbare Zeit verbraten werden. Upgrade-beständiger Code ist Silber 🥈 (und absolut notwendig), darüber hinaus aber auch langlebiger Code ist, wie ich finde, Gold 🥇, da er nicht nur den Anspruch der technischen Flexibilität für regelmäßige Versionsupgrades der verwendeten Programmbibliotheken erfüllt, sondern zusätzlich auch über Jahre hinweg verständlich geblieben ist.

Der Programmcode für die Java Virtual Machine wurde für ein zusätzliches Extra an Zuverlässigkeit mit der übersichtlichen Programmiersprache Scala entwickelt, die den Programmautoren durch schlaue Regeln gedanklich entgegenkommt. Dadurch sind unbeabsichtigte Fehlfunktionen weniger wahrscheinlich.

Viele spannende Erfahrungen und Erkenntnisse

 

Highly Resilient Geographic Map App

Fachbereiche: Cloud-Computing, Online-Landkarten
Ziel: Vervollständigung meines Wissens über Kubernetes
→ Projekt auf GitHub

Ich konnte in diesem Projekt bereits auf zahlreiche im professionellen Umfeld mit Kubernetes gemachte Erfahrungen aufbauen, die sich primär um die Deployments von Anwendungen und deren stabilen Betrieb im Cluster in der Cloud drehen. Der persönliche Nutzen für mich bestand daher in erster Linie darin, noch vorhandene Wissenslücken zu füllen.

Als Vorbereitung auf geplante Landkartenanwendungen mit einer Auswahl an möglichen Inhalten schlug ich im Rahmen der Lehrveranstaltung Cloud Computing ein Vorprojekt zu diesem Thema vor. Ziel war es, einen schnell aufsetzbaren, zuverlässigen, skalierbaren und visualisierbaren Betrieb in der Cloud in einem Gemeinschaftsprojekt mit zwei Studienkollegen zu analysieren. Unser Projektantrag ist hier zu finden: Proposal. Durch die engagierte Zusammenarbeit hielten wir innerhalb weniger Tage ein betriebsfähiges Ergebnis in unseren Händen und konnten die abschließende Präsentation in der Form eines Vortrags mit Live-Elementen vorbereiten.

Stabiler Betrieb mit Kubernetes

Das Open-Source-Produkt Kubernetes bietet sich als allgemein beliebtes und hervorragend wartbares Container-Orchestrierungs-System für Backend-Services an, da es als gut dokumentiertes und dank YAML auch vertrautes System direkt auf IaaS-Angebote verschiedener Cloud-Provider aufbaut. Kubernetes ermöglicht ein im Wesentlichen plattformunabhängiges Setup, da es unterhalb der PaaS-Ebene ansetzt und darauf ein standardisiertes System aufbaut.

Die Backend-Services im Fall einer Landkartenanwendung sind:

• Datenbank
  • PostgreSQL mit PostGIS
• Kachel-Server
  • Martin
• Frontend-Server
  • Leaflet (JavaScript)

Alle drei Services sind mit jeweils einer Instanz (Pod) als Workloads auf drei Knoten (Nodes) vertreten. Bei einem Knoten handelt es sich um einen virtuellen oder physischen Arbeitsrechner. Es können bis zu zwei der drei Knoten ausfallen, bevor der Betrieb zusammenbricht.

Die Wahrscheinlichkeit eines solchen Szenarios sollte aber als sehr selten bemessen sein, das heißt: Die Knoten werden so unabhängig voneinander betrieben, dass gleichzeitige Ausfälle äußerst unwahrscheinlich sind. Eine gute Wahl mehrerer Availability Zones, die jeweils einen Knoten enthalten, bietet sich dafür an.

Das folgende Bild zeigt die Verteilung eines Backend-Services auf die Knoten: Auf jedem Knoten läuft eine Instanz des Services als Pod. Die Instanzen sind nach außen hin als einzelnes Service mit einer IP-Adresse sichtbar. HTTP-Anfragen an das Service werden mit Hilfe eines Load-Balancers an einen der drei Pods weitergeleitet, wobei jeder Pod den gleichen Maschinencode für die Verarbeitung der Anfragen verwendet. In unserem Fall ist das der Google Cloud HTTP(S) Load Balancer.

Zwei „Gesundheitsaspekte“ des Betriebs waren für uns Kandidaten für mögliche Visualisierungen:

• Datenflüsse zwischen den Services
  • HTTP-Anfragen zwischen den Services
  • Datendurchsatz zwischen den Services
• Zustand der Sicherheitsbeschränkungen von Services

Die Datenströme zwischen den Services können mit Hilfe des von Kiali bereitgestellten Schaubilds übersichtlich visualisiert werden, wobei HTTP-Anfragen nicht einzeln betrachtet werden können, sondern nur deren statistische Eigenschaften wie z.B. die Menge der Anfragen pro Sekunde oder deren Antwortzeiten.

Für eine Problembehebung notwendige Inhalte der Anfragen bzw. der dazugehörigen Antworten sind nicht im Kontext der Visualisierung zu verorten, sondern könnten beispielsweise Betriebs-Logs entnommen werden.

Auf dem folgenden Bild sieht man ein aktives Antwortzeit-Filter. Die Einstellung rt > 10 („response time greater than 10“) hebt alle Datenverbindungen mit einer Antwortzeit von mehr als 10 Millisekunden mittels gelben Hintergrunds hervor. Dadurch können Flaschenhälse, die den Datenverkehr betreffen, einfach lokalisiert werden.

Sicherheitsbeschränkungen, die zusätzlich zur üblichen Netzwerktrennung, Verschlüsselung und Authentifizierung als weitere wichtige Verteidigungslinie gegen Angreifer im Einsatz sind, wurden von uns mittels Network Policies definiert.

Leider konnten wir dafür keine Visualisierungslösungen finden, weshalb dieser offene Punkt Potenzial für die Entwicklung einer neuen Software bietet, die diese Thematik adressiert, und die effektiven Network Policies in einer übersichtlichen Gestalt sichtbar macht, um Sicherheitslücken durch Fehlkonfigurationen schnell erkennen zu können.

Weitere gesammelte Erfahrungen

Eine Auflistung weiterer gesammelter Erfahrungen ist hier zu finden: Lessons Learned.

Pervasive Computing: Audio- und Bewegungsdaten-Auswertung

Smartphone-Sensorik, Entscheidungsbäume, Regressionsanalyse, Neuronale Netze, Data Science

Im Rahmen der Pervasive-Computing-Kurse an der Universität Linz konnte ich das Zusammenspiel von Smartphone-Technik und verschiedenen Klassifikationsalgorithmen im Detail erforschen. Ich arbeitete mit den folgenden Sensoren:

• Auditiver Sensor: Mikrofon
  • Aufzeichnung von Fahrzeug-Geräuschen
• Visueller Sensor: Kamera
  • Aufzeichnung von Fahrzeugen, um die gleichzeitig aufgenommenen Fahrzeug-Geräusche entsprechend vordefinierter Fahrzeugklassen manuell zu etikettieren
• Beschleunigungssensoren
  • Aufzeichnung von Bewegungsdaten beim Gehen oder bei der Nutzung eines Schraubendrehers
  • Beschleunigungswerte in drei orthogonale Richtungen im dreidimensionalen Raum

Fahrzeugkategorien und ihre Geräusche

Für die Aufzeichnung der Audio- und Video-Daten konnte ich mit der Kamera-App des Smartphones arbeiten. Die Etikettierung der Fahrzeuge im Video führte ich mit WaveSurfer durch. Im Hauptbereich des Fensters sieht man das Audiofrequenz-Spektrum über die Zeit; in der Zeile mit dem Titel „.lab“ sieht man die Etiketten (Beispiel: „Hr“ = heavy vehicle coming from right = schweres Fahrzeug von rechts):

Grundsätzlich handelt es sich dabei um ein sehr nützliches Werkzeug für manuelle Etikettierung, allerdings lässt es sich nicht intuitiv bedienen und ist für Anwendungsfälle, in denen die Videospur als zusätzliche Informationsquelle gebraucht wird, kaum geeignet (man muss das Video in einem separaten Programmfenster geöffnet haben und manuell synchronisieren). Es bietet sich daher an, einen modernen und vielseitigeren Ersatz für dieses Werkzeug zu entwickeln.

Ein besonders spannender Teil der Geräuschanalyse war die Kodierung als Mel Frequency Cepstral Coefficients, die auch bei Spracherkennungsaufgaben verwendet werden. Ich habe sie genutzt, um Fahrzeuge anhand der Sprüche ihrer Motoren und ihrer sonstigen Fahrgeräusche algorithmisch klassifizieren zu lassen. Die Python-Programmbibliothek librosa hat mir dabei gute Dienste geleistet.

Fahrzeugklassifikation: Ergebnisse

→ Laborbericht

• Die Einordnung nach Fahrzeug-Größe war nicht von Erfolg gekrönt, was den schwierigen Entscheidungen bei der manuellen Etikettierung geschuldet sein könnte, ob ein Fahrzeug leicht, mittelschwer oder schwer ist. 43 % der Fahrzeuge wurden falsch klassifiziert. Die meisten Fahrzeuge wurden vom Multi-Layer-Perzeptron als mittelschwer beurteilt, und keines als schwer.
• Die maschinelle Klassifizierung als von rechts oder links kommendes Fahrzeug war bedeutend erfolgreicher: 93 % wurden korrekt eingeordnet. Natürlich gibt es aber auch hier Luft nach oben, die in zukünftigen Projekten genutzt werden kann: Es wurden in Summe nur 132 Fahrzeuge für das Training der Algorithmen verwendet.

Bewegungsdaten

Für die Bewegungsdaten-Aufzeichnung verwendete ich die App Phyphox, die mir zuvor völlig unbekannt war und die freie Nutzung von Bewegungsdaten eines Smartphones so einfach wie möglich gestaltet. Die von Phyphox aufgezeichneten Rohdaten eines Spaziergangs haben die folgende Form:

Die Anwendung eines Tiefpassfilters führte zu folgendem Aussehen mit einander deutlich ähnlicheren Wiederholungen. Das deutet darauf hin, dass der Tiefpassfilter erfolgreich höherfrequentes Rauschen entfernt hat, ohne dabei relevante Informationen zu zerstören:

Das spiegelt sich auch im folgenden Korrelationen-Vergleich wider. Es wurde die Korrelation zwischen der Bewegung des Handys in der Hand auf der x-Achse und der Bewegung des Handys in der Hosentasche auf der x-Achse betrachtet.

Verwendete Regressionsverfahren: Lineare Regression, Gauß-Prozesse, Multi-Layer-Perzeptron

• Ungefiltert beträgt die Korrelation weniger als 0.19.
• Tiefpass-gefiltert beträgt die Korrelation dagegen mindestens 0.38, also das Doppelte.

Jeder Bewegungsablauf im dreidimensionalen Raum lässt sich auch als Frequenzspektrum darstellen. Die spektrale Darstellung bietet zwei Vorteile: Erstens lassen sich aus den einzelnen Frequenzen auf einfachem Weg beliebig lange Feature-Vektoren für die maschinelle Verarbeitung generieren (Vektor-Länge wird durch mehr oder weniger Zusammenfassung nebeneinander liegender Frequenzen bestimmt); zweitens lassen sich die Spektren unterschiedlicher Bewegungsabläufe im Gegensatz zu ihren zeitlichen Darstellungen schon auf den ersten Blick vergleichen. Für die Klassifikation von Bewegungen anhand ihrer Frequenzspektren ist es aber auch bedeutend, dass die Spektren über die Zeit ihren Charakter beibehalten, das heißt: immer gleich aussehen. Ich habe also den folgenden Versuch gemacht, und einen guten Eindruck bekommen:

Die Linien im obigen Video verbinden akkumulierte Frequenzen, die sich in der Nähe voneinander befinden. Von oben nach unten betrachtet stellen die Linien die Frequenzspektren der folgenden Bewegungsabläufe dar:

• BLAU  Handy in der rechten Hosentasche
• ORANGE  Handy in der linken Hosentasche
• GRÜN  Handy in der rechten Hand
• ROT  Handy in der linken Hand

→ Link zum ganzen Laborbericht

Die Darstellung als Video bringt die Zeit als dritte Dimension in das Diagramm und erlaubt eine Beurteilung der Daten innerhalb von Sekunden, noch bevor die ersten Berechnungen gemacht werden.

Im Gegensatz zur perspektivischen 3D-Darstellung läuft dieses Video nicht Gefahr, wegen optischer Täuschungen Fehleinschätzungen zu bewirken.

Es zeigen sich vier Eigenschaften der Bewegungsdaten sehr deutlich:

• In einer Hosentasche produziert das Handy beim Gehen stärkere Magnituden im höherfrequenten Bereich als wenn es in einer Hand getragen wird.
• Linke und rechte Hosentasche haben zwar ein ähnliches Spektrum, sind aber dennoch gut unterscheidbar.
• Linke und rechte Hand produzieren ein sehr ähnliches Spektrum, und sind daher weniger gut unterscheidbar.
• Die Spektralmuster der Bewegungsdaten sind ausreichend zeitstabil, um unterscheidbar zu bleiben.

Das Analyse-Ergebnis des WEKA-Tools bestätigt meine Beobachtungen: Nach dem Training eines Multi-Layer-Perzeptrons konnte dieses alle von dem in der rechten Hosentasche getragenen Handy stammenden Bewegungsdaten (right_pocket) fehlerfrei von jenen unterscheiden, die von dem in der linken Hosentasche getragenen Handy stammen (left_pocket). Außerdem gibt es keine Fehlzuordnungen zwischen Hosentasche und Hand. Die Unterscheidung zwischen linker und rechter Hand fiel nicht nur mir, sondern auch dem Multi-Layer-Perzeptron schwer: Es gibt zwischen rechter und linker Hand je zwei Fehlzuordnungen.

Wahrheitsmatrix-Ausgabe des WEKA-Tools am Ende der Analyse mit dem Multi-Layer-Perzeptron:

Generell erwies sich das unscheinbare Programm WEKA als umfassendes und zuverlässiges Werkzeug für die finalen Analysen, nachdem ich die Daten im JupyterLab mittels Python-Code in Diagrammen voruntersucht und mit Hilfe von Python-Programmbibliotheken vorverarbeitet hatte.

Laborberichte

Die oben angeschnittenen Themen sind ausführlich in meinen vier Laborberichten beschrieben. Die Arbeit an diesen Themen hat mir großen Spaß gemacht und mich sehr motiviert. Es genügt also ein kleiner Impuls, um mich zum Weiterforschen anzuregen.

• 1. Laborbericht: Fahrzeug-Kategorisierung
  • Download des 1. Laborberichts
• 2. Laborbericht: Bewegungs-Klassifikation
  • Download des 2. Laborberichts
• 3. Laborbericht: Schraubprozess-Erkennung
  • Download des 3. Laborberichts
• 4. Laborbericht: Regressionsanalyse
  • Download des 4. Laborberichts

 

Weitere Themen

Fotoverwaltung, Fotobucherstellung und Foto-Langzeitspeicherung

Parallel zu den anderen Projekten arbeite ich in meiner Rolle als Amateurfotograf an Ideen und Prototypen zum Foto- und Videomanagement.