Kategorie-Archiv: Midiola

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.

 

 

 

 

Puccini, my old enemy

puccinirolle

Bis vor einigen Wochen hieß es ja von Seiten des Deutschen Museums, dass von allen Notenrollen nur die ersten 60 cm abfotografiert seien. Bestimmt auf Nachfrage einer der anderen drei Notenrollengruppen haben sie nun eine komplette Rolle digitalisiert, und zwar das Solo „In quelle trine morbide“ aus der Puccini-Oper Manon Lescaut . Die Datei ist in der vollen Auflösung 250MB groß, schließlich ist die Rolle mehrere Meter lang.

Ich bin ja bei MIDIOLA für alles verantworlich, was mit Sound zu tun hat, also war es meine Aufgabe, unseren Auslese-Algorithmus so anzupassen, dass beim Scannen der Rolle nicht irgendein Nonsens sondern das eigentliche Stück zu hören ist. Leichter gesagt als getan. Statt eine MIDI-Klaviatur zu benutzen, setzt unsere Software den Grundton des mittleren A (440Hz) einfach in die Mitte der Rolle. Die Noten rechts von der Mitte sind dann einfach nur durch +1, +2, +3 codiert, die links daneben mit -1, -2, -3 (also nichts von der schönen musikalischen Notation mit C, C#, D, etc). Zu allem Überfluss war auch die Anzahl der „Tasten“ unseres Instruments nicht klar und musste willkürlich gesetzt werden. So konnte die ganze Rollenbreite quasi als 12 oder aber als 88 Tasten ausgelesen werden. Was blieb, war eine Youtube-Aufnahme von Maria Callas, die ich folglich rauf und runter hörte.

Was tun? Zumal ich die letzte Woche ja keinen kühlen Kopf in Berlin bewahren konnte sondern bei 30°C+ auf Exkursion in Assisi und Umbrien schmorte, dem MIDIOLA Team jedoch versichert hatte, das Problem zu lösen.

_MG_0648

pucciniscore

Der Schlüssel war eine Partitur, die ich umsonst im Internet fand. Die paar Jahre Klavierunterricht haben sich ausgezahlt, indem ich die Noten des Stückes in die von unserer Software benutzten Nummern übersetzen konnte.  Das hohe Es von In quelle war hochgerechnet vom Grundton A also +18, das tiefe Ges aus dem Klavier-Intro -27. Durch Herantasten mit willkürlichen Werten (nervig!) musste ich die Klaviatur unserer Software so „spreizen“, dass die beiden Töne von unserer Software als ebendiese Werte ausgelesen wurden. Heraus kam, dass MIDIOLA statt den üblichen 88 Tasten des Klaviers ganze 106 hat, da auch der äußerste Rand der gescannten Rolle als mögliche Note ausgelesen werden kann.

Leider hatte ich ja diese Woche die Generalprobe verpassen müssen, dafür habe ich trotz der italienischen Hitze und mit Maria Callas als gebührenden Soundtrack diese Woche einen Beitrag geleistet, der dem Namen „Coding DaVinci“ alle Ehre macht.

MIDIOLA Codingtreffen FU

dsc_0242_1024Nach unserem erfolgreichen Codingfrühstück haben wir uns für eine Woche später gleich zum nächsten Codingtreffen verabredet. Ort war diesmal aus praktischen Gründen das Informatik-Institut der FU, Ziele waren Arbeiten am Interface und ein großes Problem mit dem Live-Scan: Einige Noten die abgespielt wurden, wurden ewig gehalten und nicht mehr zum stoppen gebracht. Nach einer Suche nach der Lösung, die bereits in der Woche zuvor begonnen hatte, fanden wir endlich das Problem:

Zentral für unsere Live-Ansicht ist ja, dass man beim Abscannen der Rolle von links nach rechts auch einen gewissen Spielraum für Bewegungen nach oben und unten hat, da ja niemand den Arm wie eine Wasserwaage bewegt. Tom hatte schon einen gekonnten Algorithmus geschrieben, der eine gewisse Abweichung nach oben und unten zulässt indem er die gerade gehaltene Note beim „Slipping“ mitnimmt. Diese Note verschwand jedoch von der Liste der aktuell gehaltenen Töne, was sie nicht den NoteOff-Befehl erhalten lies.  Mit wenigen Zeilen Code konnte auch dieses Problem behoben werden und die Noten verhielten sich auch trotz „Slipping“ wieder normal.

Danach irrten wir noch ein wenig durch die FU auf der Suche nach einem Schokoriegel und verabschiedeten uns in den Nachmittag.

MIDIOLA Coding-Frühstück

_MG_0393

Heute haben wir uns zum MIDIOLA Coding-Frühstück getroffen.  Erklärte Ziele waren es, das Menü nach Momos schicken Entwürfen zu gestalten, die Live-Kamera-Ansicht auf die Startseite zu bringen und den von Tom im letzten Blogpost beschriebenen NoteOn/Off Mechanismus einzubauen um auch das Abspielen im Live-Scan-Modus zu ermöglichen.

_MG_0394

Nach einem reichhaltigen Büffet und einer Tasse des wohl stärksten Filterkaffees der westlichen Hemisphäre begann unsere mehrstündige Programmiersitzung. Da wir keine Notenrolle zur Hand hatten, mussten wir für die Arbeit am Live-Scan ein letztes Mal auf einen Papier-Dummy zurückgreifen.

_MG_0395b

Es war super produktiv, sich gegenseitig zu motivieren und unter die Arme zu greifen. Wir haben es geschafft, einige der loose ends unseres Projekts zusammenzustricken und haben auch bei Notenrollen-Dauerpfeifen (NoteOn war einfach, NoteOff machte Probleme 😀 ) unseren Verstand bewahrt. Die Live-Ansicht ist nun dank Toms sagenhafter Arbeit ein Spektakel, das sich schon ziemlich sehen und hören lassen kann!

 

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.

MIDIOLA – Paper Prototype Walkthrough

MIDIOLA Prototype

Nach einem Startbildschirm mit dem MIDIOLA Schriftzug kommt man in das dreigliedrig aufgebaute Menü mit Knöpfen für Live View, die Library und den QR-Code Reader.

1.) Mit dem QR-Code-Reader kann man Codes an nicht ausgerollten  Exponaten scannen um direkt zu deren Eintrag in der Library gelangen.

2.) Drückt man auf den oberen Teil des Screens öffnet sich der Live View Modus: Die Kamera wird aktiviert und das Kamerabild auf dem Bildschirm sichtbar. Eine kleine Animation weist darauf hin, nun mit dem Handy über die ausgerollten Notenrollen-Exponate zu scannen. Ein schmaler Strich in der Mitte des Fensters weist auf die Stelle hin, an der die Notenstriche abgespielt werden. Oben rechts findet sich das Symbol für die Klangeinstellungen (s. unten).

3.) Drückt man im Startmenü auf den Library-Knopf gelangt man in die Notenrollen-Bibliothek. Hier sind man von den Notenrollen deren charakteristisches Endstück. Mit Wischen nach links und rechts kann man so die Rollen wechseln, welche durch ein Text-Overlay mit Titel und Komponist identifizierbar sind. Ein Hinweis „Pull to Play“ weist auf deren Abspielbarkeit durch ein Wischen nach unten hin. Nun wird die Rolle abgerolllt und die Töne beim Erreichen der Bildschirmmitte abgespielt. Wischen nach oben und unten lässt den Benutzer durch die Rolle scannen und regelt außerdem die Abspielgeschwindigkeit. Die Ansicht funktioniert in vertikaler sowie horizontaler Ansicht, bei dem die Rolle beim Abspielen wie gewohnte Musiknotation zu lesen ist.

4.) In der Menüleiste am oberen Rand findet sich ein Infoknopf, welcher ein Fenster mit Informationen zu Stück und Komponisten öffnet, welche aus den Metadaten und Wikipedia hervorgeht. Ein Tippen auf den Klangknopf lässt das Klangeinstellungs-Fenster mit den drei zu spezifizierenden Drehreglern herausfahren, welche den Benutzer die Klangfarbe verändern lassen, während die Musik weiterläuft (bspw. Höhe, Harmonie, Hall und Echo, oder Weichheit und Härte des Tons).

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

MIDIOLA Interviewergebnisse

MIDIOLA Nutzerbefragung

Während unser Interesse an den Notenrollen schon seit Beginn des Kurses feststand, kam im Brainstorming jedoch die grundsätzliche Frage auf, ob wir uns dem Bestand mit einer Hardware- oder einer Softwarepräsentation nähern sollten. Diese Entscheidung sollte uns das Interview erleichtern. Unsere Fragen waren dabei eher frei und offen formuliert.

Welche Erwartungen hast du an eine Präsentation der Notenrollen? Welcher Aspekt wäre dir bei der Präsentation am Wichtigsten? Wie siehst du dich mit einer spielerischen Anwendung interagieren?

Interviewpartner waren Leute aus unserem Umfeld, in unserem Alter und mit ähnlichen Interessen wie wir, die zum Teil schon vom Notenrollen-Projekt wussten, unsere Überlegungen zu Hard- und Software jedoch noch nicht kannten.

Treffen2

Aus den teilweise längeren Antworten arbeiteten wir bei einem abendlichen Treffen in der Sophienstraße Stichworte heraus, die das Gesagte schlank zusammenfassten, bspw. „Niedrigschwellig, ohne Vorwissen“ oder „Schnelles Verstehen, nicht zu komplex“. Aus den Stichworten entwickelten wir die sechs Interessenskategorien: Historischer Kontext/Dokumentation, Schwerpunkt Audio, Starke visuelle Komponente, Erreichbarkeit, Interaktivität/Nutzereinbindung und Materieller Aspekt/Hardware

Die einzelnen Interviewpartner konnten wir somit in ein Raster einordnen, das ihre Interessen wiedergab. Dabei gab es keine Abstufung – eine Nennung von bspw. „Verständliche Aufarbeitung der Technik“ war ein Ausschlag auf der Achse „Hist. Kontext/Dokumentation“.

In der Überlagerung der Interessensraster stellten wir fest, dass der materielle Aspekt einer Präsentation als keinesfalls so wichtig empfunden wurde wie eine umfassende Dokumentation oder die Niedrigschwelligkeit und Erreichbarkeit der Präsentation. MIDIOLA Nutzerbefragung 2

Dies erleichterte uns die endgültige Entscheidung für eine mobile Softwareanwendung, zumal diese im Gegensatz zu einer Hardwareinstallation auch bessere Möglichkeiten für eine historische Unterfütterung des Materials durch Querverweise bietet. Durch ihre besondere Verfügbarkeit bringt eine App weiterhin auch eine bessere Erreichbarkeit und Nutzereinbindung mit sich.

MIDIOLA

Die Notenrollen des Deutschen Museums München sind ein wichtiges Zeugnis historischer Musikkultur. Weil selbstspielende Klaviere nicht länger auf öffentliches Interesse stößen und durch moderne Musiktechnik ersetzt wurden, sind die Pianola-Notenrollen ein hinfälliges Artefakt, das nur noch als Museumsstück auf Interesse stößt.

25-4-  Wikimedia 2

Mit unserem Projekt MIDIOLA, wollen wir den Notenrollen zu einer neuen Aktualität verhelfen. Ziel ist es, nicht nur dem wissenschaftlichen Personal des Museums Zugang zu den Rollen zu verschaffen, sondern die Technik der Notenrollen für die breite Öffentlichkeit zugänglich zu machen. Hierbei sollen die Notenrollen in einer physischen Installation präsentiert und als audiovisuelles Ereignis interaktiv erfahrbar gemacht werden.

25-4-  Wikimedia

Die Musik auf den Rollen soll in unserer Installation hörbar und sehbar gemacht werden. Dem Benutzer stehen hierbei haptische Bedienelemente zur Verfügung, die ihn den Klang unseres MIDIOLA formen lassen und ihn somit die Stücke auf den Notenrollen neu interpretieren lassen.