Alle Beiträge von tom

vom Bild zum Sound- Wie aus Pixeln Töne werden (1/2)

Wie der aufmerksame Leser vielleicht weiß, können mit Midiola, auch physisch reale Notenrollen via Webcam/Handycam in Töne verwandeln. Das Grundprinzip ist das gleiche wie beim Abspielen der gescannten Rollen. Es werden 30xSekunde sehr schmale Bildausschnitte mit der Computer Vision Bibliothek trackingjs analysiert. Diese Bildauschnitte sind bei uns  wenige Pixel breit und werden entweder aus dem aktuellen Scrollbereich des Scans oder eben dem aktuellen Frame der Kamera extrahiert. Im ersten Teil soll es zunächst darum gehen wie aus den Farbwerten der Pixel letztlich Töne werden. Im zweiten Teil widme ich mich den Probleme die es dabei mit der Webcam und zitternden Händen gibt.

 

Jetzt haben wir also einen z.B. 15×2000 Pixel großen Bildausschnitt (siehe Bild 1), wie macht man daraus nun  Töne?

scanbereich_roh
Bild 1

 

Um sich dieser Herausforderung zu nähern müssen wir die Notation von der Papierfarbe und anderen unwichtigen Bildinformationen trennen. Optimalerweise bekommen wir am Ende eine Bounding Box die sich mit der Fläche der Note deckt.
Bei den gescannten Rollen sind diese Fläche meist Rot oder Grün.

scanbereich
Bild 2

Praktischerweise kann das erwähnte trackingjs genau das, also farbige Flächen als Rechtecke zurückliefern. Fürs Debugging, aber auch für den Benutzer ist es praktisch diese zurückgelieferten Rechtecke über das Bild der Rolle zu legen (Bild 2). So kann intuitiv man sehen ob eine Note richtig erkannt als solche erkannt wurde um ggf. an der Erkennung zu schrauben oder sich einfach zu freuen wenn Sound und Note synchron sind.

An diesem Schritt angelangt, besitzt Midiola eine Liste aller vermeintlich erkannten Notenfläche (bzw. deren Bounding Boxen). Das sieht dann so aus:
[{"width":264,"height":8,"x":0,"y":0,"color":"scannedNotationColor"},{"width":12,"height":8,"x":648,"y":0,"color":"scannedNotationColor"},{"width":12,"height":8,"x":801,"y":0,"color":"scannedNotationColor"},{"width":13,"height":8,"x":974,"y":0,"color":"scannedNotationColor"},{"width":11,"height":8,"x":1170,"y":0,"color":"scannedNotationColor"},{"width":12,"height":8,"x":1321,"y":0,"color":"scannedNotationColor"},{"width":12,"height":8,"x":1428,"y":0,"color":"scannedNotationColor"},{"width":276,"height":8,"x":1730,"y":0,"color":"scannedNotationColor"}]

Bild 3: Scanbereich mit erkannten Noten und beschrifteten X-Koordinaten
Bild 3: Scanbereich mit erkannten Noten und beschrifteten X-Koordinaten

An der width kann man erkennen, dass alle Noten im Mittel 12 Pixel Breit sind. Auffällig sind der erste und der letzte Eintrag. Deren Breite ist ~20-mal größer als der Rest. Hierbei handelt es sich um die beiden äußeren Ränder, die die gleiche Farbe wie die Noten besiten. Für die Tonerzeugung ist vor allem die X-Koordinate interessant. Diese kann durch Mapping auf eine andere Skala in für die Tonerzeugung relevante Werte transformiert werden. Je größer der X-Wert desto höher soll etwa der Ton sein usw.

Ein naives Mapping für MIDI-Töne (im Bereich von 21-108) sähe etwa so aus:

sei
function map(x, in_min, in_max, out_min, out_max) {
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

dann:
map(rect.x, 0, 2000, 21, 108)

mit
rect = {"width":11,"height":8,"x":1170,"y":0,"color":"scannedNotationColor"}

gleich MIDI-Note 72.

Da wir die Ränder recht unrpoblematisch identifizieren können, wie oben gesehen, können wir unser Mapping weiter optimieren. Statt die horizontale Ausdehnung des gesamten Bildes/Scanstreifens in die Mappingfunktion einzusetzen (0, 2000), ist es sinnvoller nur den Bereich zwischen den Rändern zu betrachten (264, 1730):
map(rect.x, 264, 1730, 21, 108)

Dieses Vorgehen führt zu einer robusteren Berechnung unserer Notenwerte, da Unregelmäßigkeiten beim Scan weniger ins Gewicht fallen.

Im zweiten Teil geht es im die Probleme die sich im Livemodus ergeben.

 

 

 

 

finales UI und neue Soundevents

Letzte Woche hat Momo unser UI soweit finalisiert, dass wir nun wissen wie and an welcher Stelle wir unsere Ideen genau umsetzen (  erster Prototyp (nicht funktional) ).
Joscha hat bereits einige der neuen UX-Elemente in unserer App in Code umgesetzt.

midiola_rendering

Aufgrund der immer näher rückenden Deadline mussten wir einige Features einstampfen um uns auf die wichtigeren Aufgaben zu konzentrieren.
So wird etwa eine Runterzieh-Animation vorerst durch ein einfaches Klickereignis ersetzt.

Weiterhin kommt die Liveansicht durch die im mobilen Gerät integrierte Kamera weiter voran. Dabei musste Tom sich einen Algorithmus zum Parsen der Noten überlegen und wie aus diesen Tönen erzeugt werden. Bisher, im statischen Abspielmodus (ohne Kamera, mit den gescannten Bildern), wurden Events ausgesendet sobald eine Note im Abspielbereich erscheint. Diese Events enthielten die Länge der Noten damit diese entsprechend lange  gehalten werden.

Wie Luca aber zurecht bemerkte wird das beim Livemodus  in dieser Form nicht mehr funktionieren. Da nicht die gesamte Rolle mit den gesamten Noten vorliegt sondern immer  nur ein Kameraausschnitt, ist es beim Aussenden eines Notenevents noch nicht klar, wie lang eine Note gehalten werden muss.
Deswegen, werden nun NoteOn() events gesendet, sobald eine Note in den sehr schmalen Kamerascanbereich kommen, und NoteOff() events gesendet, sobald eine Note nicht mehr im Bereich ist.

UI-Papierprototypen und die Eigenheiten von Notenrollen

Letzten Sonntag (17.05.2015) haben wir uns zu viert in der Mensa der KHB-Weißensee getroffen um unsere noch eher unkonkreten Ideen bzgl. UX mit Papierprototypen zu konkretisieren.

Wir wussten zwar bereits, was wir im groben den Nutzer ermöglichen wollen, aber ein detaillierter Ablauf wie der Flow im Detail funktioniert fehlte uns noch.

Mit der Hilfe von vielen, auf die Größe eines typischen Smartphones, zugeschnittenen Papierstücken planten wir einzelne Screens in die der Nutzer mit unterschiedlichen Gesten gelangen kann. Hier zeigte sich eine erste Herausforderung in Hinblick auf das Format und den Aufbau von Notenrollen.

Historisch werden diese von den selbstspielenden Klavieren in vertikaler Richtung gerollt und gezogen. Aufgedruckte Texte und Ziffern sind entsprechend dieser Leserichtung angeordnet. So fanden wir es sinnvoll, die gescannten Notenrollenausschnitte in eben dieser Richtung zu zeigen und abspielen zu lassen.

Ganz anders sieht es aber mit unserer zweiten geplanten Funktionalität aus, dem Echtzeit-Scannen von im Ausstellungsbereich physisch vorfindbaren und Notenrollen. Diese wären nicht sinnvoll in vertikaler Richtung abzuscannen, da die Rollen mehr als 10 Meter lang sind.

Am Dienstag kamen unsere gekauften Notenrollen per Post an. Dies ermöglichte uns realistischere Benutzertests am Objekt. Beim diesen ersten Nutzertest unserer Prototypen am Mittwoch dem 20.05.2015 zeigte sich erneut die Problematik der Abspiel-/Anzeigerichtung der Rollen bei allen drei Testern, die jeweils unterschiedlich auf den Richtungswechsel innerhalb der App reagierten.

Die Reaktionen und Hinweise darauf werden wir bis nächsten Woche evaluieren, damit wir mit der zügigen Umsetzung des UI beginnen können.

 

prototyping1 prototyping2