musikproduktion in augmented reality diplomarbeit von ...cg/diplomarbeiten/da_danielhienert.pdf ·...

Musikproduktion in Augmented Reality

Diplomarbeit

von

Daniel Hienert

Matrikelnummer: 119920019

Institut für Computervisualistik

Arbeitsgruppe Computergrafik

Betreuer und Prüfer: Prof. Dr. Stefan Müller

August 2005

I

Eidesstattliche Erklärung

Hiermit erkläre ich an Eides statt, dass die vorliegende Arbeit selbstständig ver-

fasst wurde und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet

wurden. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prü-

fungsbehörde vorgelegt und auch nicht veröffentlicht.

Koblenz, den 10. August 2005 Unterschrift

Inhaltsverzeichnis

Abbildungsverzeichnis VII

Tabellenverzeichnis IX

Vorwort 1

1 Einleitung 3

1.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Problemabgrenzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Ziel der Arbeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Stand der Wissenschaft bzw. der Technik 7

2.1 Augmented Reality. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Überblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 3D-Interaktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Freiheitsgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 Affordances und Constraints. . . . . . . . . . . . . . . . . . . 10

2.2.3 Interaktionsmetaphern. . . . . . . . . . . . . . . . . . . . . . 10

2.2.4 Menü-Interaktion. . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Grundlagen/Ausgangsbasis 13

3.1 Historie von berührungslosen Musikinstrumenten. . . . . . . . . . . . 13

III

IV INHALTSVERZEICHNIS

3.2 Musiktheoretische Grundlagen. . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 Der Ton. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.2 Der Akkord. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.3 Rhythmus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 MIDI - Musical Instrument Digital Interface. . . . . . . . . . . . . . . 20

3.3.1 Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2 Funktionsweise. . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.3 GENERAL-MIDI . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Lösungskonzeption 29

4.1 Kurzbeschreibung der Applikationen. . . . . . . . . . . . . . . . . . . 29

4.2 Schnittstellen-Beschreibung. . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Funktionsweise der Applikationen. . . . . . . . . . . . . . . . . . . . 33

4.3.1 ARTDrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.2 ARMusic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Praktische Ergebnisse/ Evaluierung 43

5.1 Testvorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2 Testablauf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Nachbefragung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.4 Auswertung der Ergebnisse. . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.1 Eingabe von Musik im Raum. . . . . . . . . . . . . . . . . . 45

5.4.2 Instrumentenauswahl. . . . . . . . . . . . . . . . . . . . . . . 45

5.4.3 Arrangieren und Mixen. . . . . . . . . . . . . . . . . . . . . . 45

5.4.4 ARTDrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4.5 Benutzerfeedback durch Visualisierung. . . . . . . . . . . . . 46

5.4.6 Affordances und Constraints. . . . . . . . . . . . . . . . . . . 46

5.4.7 Augmented Reality. . . . . . . . . . . . . . . . . . . . . . . . 47

5.4.8 Environment Performance. . . . . . . . . . . . . . . . . . . . 47

5.4.9 Benutzerfreundlichkeit. . . . . . . . . . . . . . . . . . . . . . 47

5.4.10 Nützlichkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

INHALTSVERZEICHNIS V

5.5 Allgemeines Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6 Technische Realisierung 51

6.1 ARTTracker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 Verwendete APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.1 ARToolKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.2 MIDIShare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2.3 Player-Library . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3 Implementierte Anwendungen. . . . . . . . . . . . . . . . . . . . . . 67

6.3.1 Gemeinsame MIDI-Funktionalität. . . . . . . . . . . . . . . . 67

6.3.2 ARTDrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.3.3 ARMusic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7 Ausblick/Schlussfolgerungen 81

7.1 Kurze Zusammenfassung der erzielten Ergebnisse. . . . . . . . . . . . 81

7.2 Offene Probleme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.3 Anregungen für weiterführende Arbeiten. . . . . . . . . . . . . . . . . 83

A Programmdokumentation I

Literaturverzeichnis V

VI INHALTSVERZEICHNIS

Abbildungsverzeichnis

4.1 Grundlegendes Konzept. . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Konzept ARTDrums . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Screenshot Eingabestil Atmospheric. . . . . . . . . . . . . . . . . . . 35

4.4 Konzept Eingabestil Atmospheric. . . . . . . . . . . . . . . . . . . . 36

4.5 Konzept Eingabestil Violinbogen. . . . . . . . . . . . . . . . . . . . . 37

4.6 Konzept Eingabestil Matrix-Loop-Player. . . . . . . . . . . . . . . . . 38

6.1 Verwendete APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2 ARTDrums mit Congavisualisierung. . . . . . . . . . . . . . . . . . . 68

6.3 ARTDrums mit Schlagzeugvisualisierung. . . . . . . . . . . . . . . . 69

6.4 ARMusic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.5 Das Schlagzeug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.6 Die Hammondorgel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.7 Das Keyboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.8 Die Instrumentenauswahl. . . . . . . . . . . . . . . . . . . . . . . . . 77

6.9 Erstes Konzept einer Instrumentenauswahl. . . . . . . . . . . . . . . . 78

6.10 Der Mixer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.11 Der Arranger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

VII

VIII ABBILDUNGSVERZEICHNIS

Tabellenverzeichnis

3.1 Abstand in Halbtönen und Name des entsprechenden Intervalls. . . . . 16

3.2 MIDI-Controller Ein- und Ausschalter. . . . . . . . . . . . . . . . . . 23

3.3 Kontinuierliche MIDI-Controller. . . . . . . . . . . . . . . . . . . . . 24

3.4 MIDI-Controller Kanalbetriebsart. . . . . . . . . . . . . . . . . . . . 24

3.5 Paarweise MIDI-Controller. . . . . . . . . . . . . . . . . . . . . . . . 25

3.6 Belegung der Programmplätze nach dem GENERAL-MIDI-Standard. 26

3.7 Belegung der Perkussioninstrumente nach dem GENERAL-MIDI-Standard27

6.1 MidiShare-Typen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

IX

X TABELLENVERZEICHNIS

Vorwort

Im Jahre 1919 erfand Jean Theremin ein Instrument, das er berührungslos mit seinen

Händen spielen konnte. Ein Holzkasten mit zwei Metallantennen registrierte den Ab-

stand seiner Hände zu den Antennen und formte daraus einen Ton. Schon damals waren

die Menschen fasziniert von diesem Instrument. Eine so einfache Beeinflussung von

Tönen war bis dahin nicht möglich gewesen. Musik war bis dahin immer nur Menschen

vorbehalten, die ein Instrument spielen konnten. Die Idee, Musik einfach mit den Hän-

den zu beeinflussen, ohne eine Tastatur, ein Griffbrett oder Ventile zu benutzen, erfuhr

aber leider keine Weiterentwicklung. Später wurden neue berührunglose Instrumente

entwickelt, die von Jean Michel Jarre und anderen hauptsächlich als Show-Instrumente

eingesetzt wurden. Heutzutage stehen uns mit Augmented Reality (AR) und dem MIDI-

Protokoll Techniken zur Verfügung, die es uns erlauben, diese Idee wieder aufzugreifen

und weiterzuentwicklen. Die Einfachheit der Beeinflussung von Klang mit den Händen

soll erhalten bleiben, die Möglichkeiten Klang zu beeinflussen sollen erweitert werden.

Augmented Reality gibt uns die Möglichkeit die Position von beliebigen Objekten zu

erkennen und in Musik umzuwandeln. MIDI macht es uns möglich viele Parameter der

Musik in Echtzeit zu beeinflussen und über 128 verschiedene Instrumente zu benutzen.

Die Kombination dieser beiden Techniken soll zur Entwicklung eines Systems dienen,

das eine intuitive Erzeugung von Musik erlaubt.

1

2 TABELLENVERZEICHNIS

Kapitel 1

Einleitung

1.1 Motivation

Diese Diplomarbeit beschäftigt sich mit der Verbindung von Augmented Reality-Technik

mit der Produktion von Musik. MIDI, ein Protokoll für die Übermittlung, Aufzeichnung

und Wiedergabe von musikalischen Steuerinformationen und das ARToolKit, eine Aug-

mented Reality-API1 bilden die Grundlage der Applikation. Gibt es bisher nur wenige

kommerzielle Anwendungen für Augmented Reality, versucht diese Arbeit einen neu-

en Themenbereich für die AR-Technik zu finden. Produktion von Musik ist bisher nur

denjenigen vorbehalten, die ein Instrument spielen können. Die Anwendung versucht

nun die Möglichkeiten der Augmented Reality-Technik zu nutzen, um Benutzern ohne

musikalische Vorbildung, das Erzeugen von Musik zu ermöglichen.

1.2 Problemabgrenzung

Bei der Entwicklung eines Augmented Reality-Systems für die Produktion von Mu-

sik sind viele Probleme zu lösen. Wie kann man die verschiedenen Bereiche von Mu-

sikproduktion, wie das Eingeben von Musik, das Manipulieren, das Aufzeichnen und

Mischen auf verschiedenen Spuren zufriedenstellend lösen? Welche Metaphern kann

man für die verschiedenen Bereiche benutzen, welche stehen zur Verfügung ? Welche

1Application Programming Interface - Schnittstelle zur Anwendungsprogrammierung

3

4 KAPITEL 1. EINLEITUNG

Musikparameter kann und soll der Benutzer beeinflussen und wie kann der Benutzer

mithilfe von geeigneten „Affordances und Constraints“2 unterstützt werden. Ist es mög-

lich die große Anzahl von Funktionen, zum Beispiel beim Mischen von unterschied-

lichen Spuren, übersichtlich und effizient darzustellen und zu kontrollieren? Stellt die

3-Dimensionalität eine Erleichterung oder eine Erschwernis für den Benutzer dar? Un-

terstützt die Visualisierung den Benutzer bei der Eingabe von Musik?

Diese und viele weitere Fragen stellen sich im Kontext dieser Arbeit. Aufgrund

von fehlenden Referenzsystemen im Bereich der Produktion von Musik in Augmented

Reality-Umgebungen und dem niedrigen Forschungstand im Bereich der Interaktion in

drei Dimensionen müssen die unterschiedlichsten offenen Bereiche bearbeitet werden.

1.3 Ziel der Arbeit

Die Vorteile der Augmented Reality-Technik sollen die Produktion von Musik in Aug-

mented Reality unterstützen. Dabei müssen die Vorteile von AR exakt ausgearbeitet

werden und in Vorteile für die Musikproduktion umgewandelt werden.

Beschränkt sich die Navigation in klassischen Benutzeroberflächen auf eine zwei-

dimensionale Ebene, kann man im dreidimensionalen Raum mit drei Raumkoordinaten

und drei Drehungen um die Achsen arbeiten. Es stehen also sechs Freiheitsgrade gleich-

zeitig zur Verfügung, mit denen man die Parameter der Musik beeinflussen kann. Damit

stehen nicht nur traditionelle, sondern auch innovative Eingabemethoden zur Verfügung.

Tangible User Interfaces3 ist das Konzept für die Manpulation der Instrumente. Die

3D-Modelle sollen mithilfe der drei Raumachsen intuitiv beeinflussbar sein. Dadurch

erhöht sich die Einfachheit beim Spielen und der Auswahl der Instrumente. Im Idealfall

steht ein komplettes Orchester zur Verfügung, welches von dem Benutzer multimodal4

erlebt werden kann. Das Ohr hört die Musik, das Auge sieht die entsprechenden 3D-

2„Affordances“: durch die Benutzerschnittstelle werden dem Anwender nur bestimmte Interaktions-

möglichkeiten angeboten, „Constraints“: Einschränkung der Interaktionsmöglichkeiten für ein Objekt,

z.B. geometrisch oder strukturell3berührbare Benutzerschnittstellen4mit mehreren Sinnen

1.3. ZIEL DER ARBEIT 5

Grafiken und Animationen und die Hände als natürliches Interaktionsmedium werden

mit in die Applikation integriert.

Der Benutzer erhält eine Rückkopplung durch die Visualisierungen auf den ver-

schiedenen Instrumenten. Diese können einerseits didaktisch, andererseits zur Rück-

kopplung während der Eingabe von Musik benutzt werden.

Der Benutzer wird mithilfe geeigneter „Affordances und Constraints“ unterstützt. So

kann er beliebige Raumdaten eingeben, die das System sinnvoll in eine Tonart überleitet,

so dass die Musik immer in Harmonie bleibt. Die Geschwindigkeit der verschiedenen

Spuren kann mit dem Schlagzeug kontrolliert werden und ist für die verschiedenen Spu-

ren immer gleich. Der Takt setzt immer zum richtigen Zeitpunkt ein. Rhythmen können

von einem Objekt auf verschiedene andere Objekte und damit auf andere Musikinstru-

mente übertragen werden.

Die Applikationen sollen intuitiv und einfach sein und trotzdem die Kontrolle von

vielen verschiedenen Parametern der Musik erlauben. Die Benutzerschnittstelle soll

mehrere Sinne des Menschen ansprechen, die Welt möglichst realistisch abbilden und

dadurch einen einfachen Zugang zu den dahinterliegenden Möglichkeiten bieten. Mög-

lichkeiten, wie die Auswahl von 128 verschiedenen Instrumenten, die das GENERAL-

MIDI-Protokoll bietet, oder die Beeinflussung vieler Klangparameter zu einem Zeit-

punkt, sollen intuitiv, ohne Einarbeitung, beeinflusst werden können. Die Transparenz

der Benutzerschnittstelle soll dem Benutzer die Möglichkeit bieten, sich auf die Aufga-

ben der Musikerzeugung zu konzentrieren.

Komplexe Interaktionsmöglichkeiten sind bisher in Augmented Reality-Systemen

kaum realisiert. Bei komplexen Anwendungen, wie dem Mischen oder dem Arrangieren

von Musik soll eine Interaktionsmöglichkeit gefunden werden, die es dem Benutzer

erlaubt viele Funktionen auf kleiner Fläche zu kontrollieren, ohne dabei auf weitere

Hardware zurückzugreifen. Dies soll mithilfe von natürlichen Gesten realisiert werden.

6 KAPITEL 1. EINLEITUNG

1.4 Zusammenfassung

In Kapitel 1 erfolgt ein Überblick zur Motivation, Problemabgrenzung und zum Ziel der

Arbeit. Kapitel 2 erläutert den Stand der Wissenschaft und Technik in den Bereichen

Augmented Reality und 3D-Interaktion. Kapitel 3 gibt einen Überblick über die Grund-

lagen und die Ausgangsbasis. Es erläutert die Geschichte von alternativen, ohne Berüh-

rung gespielten Instrumenten, gibt einen wichtigen musiktheoretischen Überblick, der

zum Verständnis dieser Arbeit nötig ist und führt in das MIDI- und das GENERAL-

MIDI-Protokoll ein. Kapitel 4 erläutert die Lösungskonzeption in den verschiedenen

Bereichen. Kapitel 5 präsentiert die Auswertung der Evaluierung und die praktischen

Ergebnisse. Kapitel 6 gibt einen Überblick über die verwendeten Werkzeuge zur Ent-

wicklung und über die verschiedenen Implementierungen.

Kapitel 2

Stand der Wissenschaft bzw. der

Technik

Dieses Kapitel gibt einen Überblick über die verwendete Technik Augmented Reali-

ty. Im zweiten Teil des Kapitels werden die grundsätzlichen Eigenschaften von 3D-

Interaktion behandelt.

2.1 Augmented Reality

2.1.1 Definition

Augmented Reality (AR) ist eine Technologie, die ein reales Bild mit virtuellen Ob-

jekten erweitern kann. Die Geometrie von Videobildern, welche von Webcams, Fern-

sehkameras und Kameras auf Datenbrillen geliefert werden, können mit computergene-

rierten 3D-Grafiken in Deckung gebracht werden, so dass der Benutzer den Eindruck

von einer „Erweiterten Realität“ hat. Der Benutzer in Augmented Reality-Umgebungen

interagiert mit realen oder virtuellen Objekten. Durch die dynamische Erweiterung mit

virtuellen Objekten kann der Benutzer mit visuellen Informationen unterstützt werden.

7

8 KAPITEL 2. STAND DER WISSENSCHAFT BZW. DER TECHNIK

2.1.2 Überblick

Nach Milgram und Kishino (10) ist Augmented Reality ein Teil der „Mixed Reality“

und eine Symbiose von virtueller Realität und realer Umgebung. Die virtuelle Reali-

tät und die reale Umgebung sind miteinander kombiniert und teilweise überlagert. Die

Interaktivität findet in Echtzeit statt. Virtuelle 3D-Objekte sind so in den 3D-Raum ein-

gefügt, dass sie geometrisch korrekt erscheinen.

Ein Augmented Reality-System besteht aus einer Kamera, Trackinggeräten1 ver-

schiedenster Art und Software, um die realen Bilder mit den virtuellen Objekten geo-

metrisch korrekt zu überlagern.

Ein Beispiel für die Anwendung von Augmented Reality ist das Einblenden von

Abstandsgrafiken in Sportübertragungen. Verschiedene Entfernungen bei Fußballüber-

tragungen, beim Skispringen oder beim Weitwurf werden mit einfachen Grafiken auf

dem Fernsehbild in Echtzeit visualisiert. Weitere Beispiele sind das Unterstützen des

Benutzers mit visuellen Informationen auf realen Bildern bei der Wartung, Instandhal-

tung und Reparatur von Autos oder Flugzeugen. Hier können Informationen und Ar-

beitsanweisungen für das zu montierende Teil den Benutzer unterstützen. Beim Militär,

dem Katastrophenmanagement, sowie der Ökologie können Karten mit dynamischen

Elementen erweitert werden. In der Medizin können nicht sichtbare Elemente für den

Arzt und den Patienten visualisiert werden. Mehrbenutzerkonferenzen können mit rea-

len und virtuellen Teilnehmern abgehalten werden. Aktuelle Entwicklungen finden sich

im Spielesektor. Auf der „Play-Station 2“ der Firma Sony werden einfache Augmented

Reality-Spiele angeboten. Der Benutzer sieht sich selbst im Videobild und muss je nach

Spiel mit den Grafiken interagieren.

Die Probleme der Augmented Reality-Technik sind vielfältig. Augmented Reality

stellt hohe Anforderungen an alle technischen und nichttechnischen Komponenten. Das

System muss 30 Bilder pro Sekunde aufnehmen, mit geeigneten Bildverfahren bearbei-

ten und mit den visuellen Erweiterungen, die bedarfsgerecht berechnet werden müssen,

wieder ausgegeben werden. Die eingehenden Daten haben eine hohe Komplexität. Nicht

1Geräte zur Positionsbestimmung

2.2. 3D-INTERAKTION 9

nur die Videobilder, sondern auch Trackerinformation müssen verarbeitet werden. Diese

aktualisieren sich bei manchen Systemen bis zu 60 Mal pro Sekunde. Das Tracking ist

eine empfindliche Komponente. Je nach Art des Tracking, optisch, elektromagnetisch,

per GPS usw. treten verschiedene Probleme auf. Bei markerbasierten Trackingverfah-

ren ist das Verdecken von Markern2 ein großes Problem. Die meisten Trackingsysteme

haben eine zu geringe Abtastrate um Bewegungen genau genug abzutasten. Die Folge

ist die nicht geometrisch korrekte Überlagerung der Realität. Das Tracking mit GPS ist

sehr ungenau und selbst bei der Kopplung mehrerer Satelliten auf nur wenige Meter

genau. Das macht es schwer mobile Systeme für Augmented Reality zu entwickeln.

Die Visualisierungen der virtuellen Szene in der realen Umgebung benötigt Daten,

die die Umgebung auch in ihrer Geometrie beschreiben. Daraufhin kann man die Ver-

deckung von virtuellen durch reelle oder umgekehrt berechnen. Diese Daten sind aber

meist nicht verfügbar und nur selten in heutigen Augmented Reality-Systemen zu fin-

den.

Die Benutzerschnittstelle bei Augmented Reality-Systemen steht noch in einem sehr

frühen Entwicklungsstadium. Einfache Funktionen werden meist mit dreidimensiona-

len Maus-Systemen gesteuert, komplexe Funktionssteuerungen sind kaum möglich. Da-

durch ist die komplexe Interaktion in solchen Systemen meist sehr beschränkt.

2.2 3D-Interaktion

2.2.1 Freiheitsgrade

Im zweidimensionalen Raum gibt es zwei Achsen, die x- und die y-Achse. Im dreidi-

mensionalen Raum dagegen gibt es eine Achse mehr, die z-Achse, die in die Tiefe des

Raums zeigt. Ein 3D-Raum besteht damit aus 6 Freiheitsgraden (Degrees of Freedom),

den drei Translationen und den drei Rotationen um die Achsen.

Die Besonderheit bei der Interaktion in drei Dimensionen ist die Entfernung zu ei-

nem Objekt. Bleibt in zwei Dimensionen der Mauszeiger immer auf einer Ebene und

2Muster, anhand derer der Tracker die 3D-Position feststellen kann


kann leicht das passende Objekt aussuchen, besteht in drei Dimensionen das Problem,

wie das entfernte Objekte angewählt werden kann.

2.2.2 Affordances und Constraints

Drei Dimensionen bieten viele Möglichkeiten der Interaktion. Auf Seiten des Benutzers

ist die Interaktion auf die menschlichen Kommunikationswege beschränkt. Auf Seiten

des Computers beschränkt sich die Kommunikation auf die Ein- und Ausgabegeräte.

Um den Benutzer bei der Interaktion mit Computern zu unterstüzen, wurden Interak-

tionsverfahren eingeführt, die den Benutzer „leiten“. „Affordances und Constraints“

kann dem Interaktionsverfahren zu Hilfe kommen. Je nach der Anzahl der Möglich-

keiten, die ein Interaktionsverfahren bietet, können „Affordances und Constraints“ die

Anzahl der möglichen Interaktionen einschränken. „Constraints“ helfen dem Benutzer

zum Beispiel bei der Positionierung von Objekten in einer virtuellen Umgebung. Durch

die Möglichkeiten der Positionierung in drei Dimension ist die exakte Positionierung

oft sehr schwierig und zeitaufwendig. „Constraints“ können Benutzer nun dadurch un-

terstützen, dass sie auch die ungefähre Positionierung durch den Benutzer akzeptieren

und das Objekt auf einem Raster anordnen. „Affordances“ kommen zum Einsatz, wenn

Objekte mit Eigenschaften ausgestattet werden. Dabei können bestimmte Objekte mit-

einander interagieren, andere wiederum nicht. Ein Beispiel wäre die erlaubte Interaktion

von virtueller „Schere“ mit virtuellem „Blatt Papier“, aber das Verbot von Interaktion

des Objektes „Schere“ mit einem virtuellem „Stein“. Der Einsatz von „Affordances

und Constraints“ sind unbeschränkt. Regeln für die Interaktion des Benutzers mit den

verschiedenen Objekten können aufgestellt werden und so den Benutzer führen und

unterstützen. Sie vereinfachen die Interaktion mit dem Computer.

2.2.3 Interaktionsmetaphern

Metapher kommt aus dem Griechischen und bedeutet „Übertragung“. Als sprachliches

Ausdrucksmittel wird das eigentliche Wort durch ein anderes ersetzt, welches eine sach-

liche oder gedankliche Ähnlichkeit hat. Metaphern werden benutzt um komplexe Sach-

2.2. 3D-INTERAKTION 11

verhalte auf einfach verständliche Bilder zu übertragen, so dass der Rezipient diese ein-

facher verstehen kann. Eine Interaktionsmetapher wird benutzt um komplexe Interaktio-

nen zwischen Computer und Mensch einfacher zu gestalten. Dreidimensionale, virtuelle

Objekte und bereits aus der Realität bekannte Interaktionsverfahren werden benutzt um

dem Benutzer eine einfache Interaktion im virtuellen Raum zu ermöglichen. Es wird

unterschieden zwischen exozentrischen und egozentrischen Metaphern. Hat der Benut-

zer die gesamte virtuelle Welt im Blickfeld und kann sie von mehreren Seiten betrach-

ten, befindet er sich außerhalb dieser Welt und es kommen exozentrische Metaphern

zum Einsatz. Befindet sich der Benutzer innerhalb der Welt, wird von egozentrischen

Metaphern gesprochen. Augmented Reality strebt die Immersion3 des Benutzers in die

virtuelle Welt an, folglich kommen hier egozentrische Metaphern zum Einsatz. „World-

in-Miniature“ (WIM) ist eine verkleinerte Darstellung der virtuellen Welt. Die Objek-

te dieser Welt sind leicher manipulierbar als größere Objekte. Diese Objekte können

in sechs Freiheitsgraden beeinflusst werden und so komplexe Funktionen auf einfache

Manipulation des Objekts übertragen werden. Statt mit einer virtuellen Hand können in

Augmented Reality-Umgebungen diese Objekte mit der getrackten echten Hand mani-

puliert werden. Virtuelle Objekte können mit der echten Hand selektiert und manipuliert

werden. Das aktuelle Objekte kann sehr einfach durch die Entfernung der echten Hand

zu dem virtuellen Objekt ausgewählt werden. Die explizite Selektion und Deselektion

bedarf einer virtuellen Taste oder einer Greifgeste.

2.2.4 Menü-Interaktion

Auch wenn Interaktionsmetaphern viele Möglichkeiten der Interaktion bieten, können

viele Änderungen im System oder von Objekten nur sinnvoll mithilfe von Menüs aus-

geführt werden. Das gilt vor allem für die Steuerung für eine große Anzahl von Funk-

tionen. Die bekanntesten Interaktionsmetaphern in zweidimensionalen Applikationen

sind Drop-Down-Menüs, Toolbars und Sliders. Zusätzlich kommen Kontextmenüs zum

Einsatz, die Funktionen zum jeweiligen Objekt dynamisch anbieten. Diese Metaphern

3das Eintauchen


können leicht in drei Dimensionen übertragen werden und nutzen das Vorwissen des

Benutzers. Die Ausführung der Menüs kann auch drei Dimensionen annehmen, womit

aber nicht unbedingt ein Mehrwert an Funktionalität und Qualität der Interaktion ver-

bunden ist. Nicht immer ist die Erweiterung auf drei Dimensionen intuitiv und kann die

Navigation erheblich erschweren. Der Zugewinn an grafischen Effekten kann also durch

fehlenden Bedienkomfort stark verringert werden. Eindimensionale Menüs, wie Slider

bieten sich für die Auswahl von einem Eintrag oder die Rotation eines Objektes um ei-

ne Achse an. Bei einem zweidimensionalen Menü, wie dem Pull-Down-Menü wird dem

Benutzer eine weitere Auswahlebene zur Verfügung gestellt. Eine Erweiterung des ein-

dimensionalen Sliders auf drei Dimensionen ist das Ring-Menü. Es besteht aus einem

Ring, auf dem die einzelnen Menüpunkte als 3D-Objekte angeordnet sind. Das vorder-

ste Objekt ist das ausgewählte. Alle anderen Menüpunkte können aber immer durch den

Benutzer überblickt werden. Der Benutzer muss sich nur zwischen zwei Richtungen der

Rotation entscheiden und kann so das gewünschte Objekt auswählen.

Kapitel 3

Grundlagen/Ausgangsbasis

Das Kapitel Grundlagen und Ausgangsbasis gibt zuerst einen kurzen Überblick über

die Geschichte von berührungslosen Instrumenten. Der zweite Teil gibt einen Überblick

über wichtige musiktheoretische Grundlagen. Im dritten Teil wird das MIDI- und das

GENERAL-MIDI-Protokoll vorgestellt.

3.1 Historie von berührungslosen Musikinstrumenten

Neben den klassischen Musikinstrumenten, wie Klavier, Geige oder Gitarre gab es

schon zu Anfang des letzten Jahrhunderts alternative Entwicklungen. Der Ton wurde

im Gegensatz zu den klassischen Instrumenten nicht durch das Schwingen von Saiten,

sondern elektronisch erzeugt.

Das Theremin ist das erste berührungslose Musikinstrument und wurde 1919 vom

dem russischen Physikprofessor Leon Theremin erfunden. Es besteht aus einem Holz-

kasten mit zwei Antennen. Die Antennen umgibt ein leichtes elektronisches Feld. Das

Theremin wird berührungslos durch den Abstand der beiden Hände zu den Antennen

gespielt. Die eine Hand kontrolliert die Tonhöhe, die andere Hand die Lautstärke des

Tons. Bewegt man die eine Hand in Richtung der Antenne wird der Klang stufenlos

höher. Bewegt man die andere Hand in Richtung der Antenne wird der Klang leiser.

Besonders gut geeignet ist das Theremin für Kompositionen, die für Geige oder Flöte

13

14 KAPITEL 3. GRUNDLAGEN/AUSGANGSBASIS

geschrieben wurden, da das Instrument als Melodieinstrument ausgelegt ist. Der Klang

der Instruments ist eine Mischung aus Geige und elektronischer Ausdrucksform.

Das Theremin wurde 1945 im Hitchcock-Thriller „Spellbound“ eingesetzt. Ende

1968 wurde der Thereminklang mit dem Popsong der Beach Boys „Good Vibrations“

berühmt, allerdings wurde es von einem mit einer Tastatur versehenen Modell gespielt.

Oft wurde das Theremin für Filmmusik verwendet, zum Beispiel auch in „Psycho“ von

Alfred Hitchcock. Besonders bekannt ist die Eröffnungsmelodie der alten Star Trek-

Serie “Raumschiff Enterprise“ aus den 60er Jahren. Ebenfalls verwendete Christopher

Franke ein Theremin für die Musik zum „Babylon 5“-TV-Film „Das Tor zur 3. Dimensi-

on“. Der französische Musiker Jean Michel Jarre setzte das Theremin bei einigen seiner

Stücke ein. Auch in der modernen Rockmusik fand das Theremin Anwendung. So be-

nutzte Jimmy Page von Led Zeppelin das Instrument bei „The Song Remains The Same“

und „Whole Lotta Love“. Eine bekannte Virtuosin auf dem Theremin war Clara Rock-

more (1911-1998). In der Gegenwart tritt Lydia Kavina, die Großnichte Theremins, die

bei ihm das Thereminspiel gelernt hatte, als Virtuosin auf dem Theremin auf.

Heutzutage wird das Theremin als Ethervox MIDI-Theremin angeboten. Das Instru-

ment besitzt eine MIDI-In- und eine MIDI-Out-Schnittstelle, mit der sich die Klänge

aufnehmen und abspielen lassen.

Es gab in der Geschichte, maßgeblich nach der Erfindung von MIDI 1983, weitere

berührungslose MIDI-Controller. Optisch kann man mit Bildverarbeitung, Laser, Infra-

rot oder Lichtvorhang arbeiten. Akustisch kann Ultraschall eingesetzt werden. Ihnen

allen gemeinsam ist das Abtasten von Hand oder Körper, die Umwandlung in Töne

oder Musik, per MIDI oder mit Samples1. Viele Instrumente verarbeiten die Gesten

auch grafisch und zeigen sie auf einer Leinwand. Besonders spektakulär ist die „Laser

Harp“, die speziell für den Musiker Jean Michel Jarre hergestellt wurde. Das Instrument

erschien 1981 und ist mit 10 Laserstrahlen ausgestattet, die in die Höhe gehen. Durch

die Stärke des Lasers ist die Bedienung nur mit Asbesthandschuhen und Schutzbrille

möglich. Ein Windows-PC misst die Unterbrechung des Laserstrahls mit den Händen

und formt einen entsprechenden Ton.

1kurze Musikaufnahmen

3.2. MUSIKTHEORETISCHE GRUNDLAGEN 15

Der einzige berührungslose MIDI-Controller der heutzutage kommerziell eingesetzt

wird, ist der „D-Beam-Controller“ von Roland. Die Position der Hand wird dabei mit-

hilfe eines Infrarot-Strahls gemessen. Das System unterstützt drei Raumachsen, ist aber

räumlich stark eingegrenzt. Er wird in vielen Roland-Instrumenten zur zusätzlichen Pa-

rameterkontrolle eingesetzt.

3.2 Musiktheoretische Grundlagen

3.2.1 Der Ton

Der elementare Baustein der Musik ist der Ton. Ein Ton ist ein Einzelton, den man von

den Begriffen Klang und Geräusch abzugrenzen muss. Ein Klang besteht aus mehre-

ren Tönen, ein Geräusch ist eine Klangfläche. Der Ton besteht aus den Komponenten

Tonhöhe, Tonlänge, Tonlautstärke und der Klangfarbe.

Die Tonhöhe wird bestimmt durch die Grundfrequenz, dem Sinuston. Diese Fre-

quenz wird in Hertz gemessen, die die Schwingungen in Sekunden ausdrückt. Ande-

rerseits wird die Tonhöhe auch mit der Tonbezeichnung der Klaviatur mit ihrer Oktave

betitelt. Die Tonlautstärke wird physikalisch als die Schwingungsweite, der Amplitude,

bezeichnet. Die Klangfarbe wird durch die verschiedenen Obertöne, den sogenannten

„Flageoletts“ bestimmt. Ein Instrumentalton, zum Beispiel von einer Geige, ist damit

eine Mischung aus einem Grundton und vielen Obertönen, die für die charakteristische

Klangfarbe des Instruments verantwortlich ist.

Das Intervall

Zwei Töne erklingen gleichzeitig in einem bestimmten Intervall, mehrere gleichzeitig

erklingende Töne werden als Akkord bezeichnet. Tabelle3.1 zeigt die Abstände der

Halbtöne und den Namen des entsprechenden Intervalls.


Abstand in Halbtönen Name des Intervalls in einer diatonischen Tonleiter

0 Prime

1 kleine Sekunde

2 große Sekunde

3 kleine Terz

4 große Terz

5 Quarte

6 Tritonus

7 Quinte

8 kleine Sexte

9 große Sexte

10 kleine Septime

11 große Septime

12 Oktave

13 Non

14 Dezim

Tabelle 3.1: Abstand in Halbtönen und Name des entsprechenden Intervalls


Tonleitern

Die sieben Stammtöne verwenden die ersten sieben Buchstaben des lateinischen Alpha-

bets: a, b, c, d, e, f, g. Verwendet man a als Grundton ergibt sich die a-Moll Tonleiter,

mit c als Grundton ergibt sich die Tonart C-Dur. Da C-Dur die üblichste Tonleiter ist,

verwendet man im Deutschen die Stammtöne in der Reihenfolge c, d, e, f, g, a, h. Im

Englischen wird die Note h als b bezeichnet, während die Note b als „b flat“ bezeichnet

wird. Man kann Töne um Halbtöne erhöhen oder erniedrigen.

Eine Tonleiter ist eine Folge von Tönen, die in einem musikalischen Zusammenhang

stehen. Eine Tonleiter hat den Umfang von einer Oktave, das heißt sie bewegt sich vom

Grundton, bis zu 12 Halbtöne höher und wiederholt sich dann wieder. In der abendlän-

dischen Musiktheorie wird zwischen verschiedenen diatonischen Tonleitern unterschie-

den. Diatonische Tonleitern dürfen nur aus den Intervallen große und kleine Sekund

bestehen. Beispiele dafür sind Dur- und Molltonleitern. Die Dur-Tonleiter besteht aus

Tönen im folgenden Abstand:

Ganzton - Ganzton - Halbton - Ganzton - Ganzton - Ganzton - Halbton

Moll-Tonleitern haben den folgenden Abstand von Tönen:

Ganzton - Halbton - Ganzton - Ganzton - Halbton - Ganzton - Ganzton

Man kann eine Tonleiter auf jedem beliebigen Ton beginnen. Ordnet man die Töne

aufbauend auf einen Grundton nach dem obigen Muster an, hat man eine Tonart be-

stimmt. Nimmt man den Ton c als Grundton und baut die Tonleiter nach den obigen

Mustern darauf auf, hat man die Tonart C-Dur oder c-Moll bestimmt.

Die Tonart C-Dur enthält alle Stammtöne: c - d - e f - g - a - h c. Zwischen den Ganz-

tonschritten liegen die Halbtonschritte, die hier durch die Bindstriche gekennzeichnet

sind. Die Stammtöne haben auf der Klaviatur die weißen Tasten, Halbtöne die schwar-

zen. Im Deutschen werden sie erhöht, indem man ein „is“ an den Stammton hängt.

Daraus ergeben sich folgende Halbtöne: cis, dis, fis, gis und ais. Erniedrigt man einen

Stammton wird meist ein „es“ anghängt: des, es, ges, as und b.

Mit verschiedenen Grundtönen und dem Aufbau der Tonleiter nach dem Dur- oder

Mollprinzip ergeben sich verschiedene Tonarten. Diese Tonarten werden auch durch die

Anzahl ihrer Halbtöne beschrieben.


3.2.2 Der Akkord

Ein Akkord ist das gleichzeitige Erklingen von mehreren, unterschiedlichen Tönen die

dabei einen harmonischen Klang ergeben. Der gebräuchlichste Akkord in der europäisch-

amerikanischen Musiklehre ist ein Dreiklang. Er besteht aus aufeinandergestapelten Tö-

nen im Terzabstand. Wie Tabelle3.1 zeigt, besteht eine kleine Terz aus drei Halbton-

schritten, eine große aus vier. Zwei übereinander liegende Terzen ergeben einen Akkord.

Ist die untere Terz groß und die obere klein, ergibt sich ein Dur-Akkord, umgekehrt er-

gibt sich ein Moll-Akkord. Zum Beispiel besteht ein C-Dur-Akkord aus den Tönen c, e

und g. Zwischen den Tönen c und e ergibt sich eine große Terz, zwischen e und g eine

kleine. Ist der Akkord aus zwei großen oder zwei kleinen Terzen aufgebaut, ergibt sich

ein übermäßiger oder ein verminderter Akkord. Stapelt man drei überliegenden Terzen,

ergibt sich ein Septakkord. Vier Terzen ergeben ein Septnonakkord. Beim Septakkord

wird also zum Grunddreiklang die tonleitereigene Septime gesetzt, die je nach Position

groß oder klein sein kann. Vier Terzen ergeben einen Septnonakkord, bei dem zu dem

Septakkord noch die neunte Stufe der Tonleiter hinzugefügt wird.

Jazzakkorde bestehen nicht aus einfachen Dreiklängen, sondern aus Septakkorden

mit Erweiterungen. Meistens werden Vier- oder Fünfklänge gespielt. Die Septime kann

dabei eine große oder kleine sein. Ist sie klein, handelt es sich um einen Dominant-Sept-

Akkord, ist sie groß, um einen Major-Sept-Akkord. Die Sept-Akkorde können nun mit

Akkord-Erweiterungen, sogenannten Optionen, versorgt werden. Als Optionen stehen

der 9., der 11. oder der 13. Ton der eigenen Tonleiter zur Verfügung.

„Spread Voicing“ sind vierstimmige Akkorde mit dem Grundton, der Terz, der Quin-

te und der Septime. Jedoch treten die Töne nicht in einer bestimmten Reihenfolge auf,

sondern sind, wie der Name schon sagt, über die Klaviatur verstreut. Es gibt verschie-

dene „Spread Voicings“. Ihr Name wird durch die Reihenfolge ihrer Töne bestimmt.

„1735“-Voicings sind die gebräuchlichsten, wobei „1“ den Grundton, „7“ die Septime,

„3“ die Terz und „5“ die Quinte angibt. Außerdem gibt es noch „1379“- und „1573“-

Voicings. Die „9“ bezeichnet dabei die „Non“.

Das diatonische Stufensystem in Dur oder Moll stellt Jazz-Akkorde zur Verfügung.

Dabei nimmt man die diatonische Dur- oder Molltonleiter und schichtet auf jeden Ton-


leiterton drei diatonische Terzen. Eine diatonische Terz bezeichnet hierbei eine Terz

nach den Regeln der Tonleiter, also immer den übernächsten Ton in der jeweiligen Ton-

leiter. Daraus ergeben sich sieben Akkorde, die harmonisch zueinander sind und diato-

nische Stufenakkorde genannt werden.

3.2.3 Rhythmus

Die zeitliche Anordnung von Tönen oder Akkorden nennt man Rhythmus. Das Me-

trum bezeichnet in der Musik das gleichmäßige Schlagen im Takt ohne Betonung. Die

Taktart bezeichnet die Einteilung des Metrums in betonte und unbetonte Zählzeiten. Bei

einem 4/4-Takt schlägt das Metrum vier Mal pro Takt. Der Rhythmus bezeichnet nun

die Folge unterschiedlicher Tondauern und der Akzentmuster, die auf den Grundtakt

gelegt werden. Der Rhythmus ist damit ein komplexer Zusammenhang zwischen Ton-

dauer und Betonung im Beziehung zu einer bestimmten Taktart. Durch die regelmäßige

Wiederkehr behält der Rhythmus den Bezug zum Takt.

Musikstücke werden in Abschnitte gleicher Zeitdauer unterteilt. Die Taktart wird

durch einen Bruch angegeben. Der Nenner definiert, wie lang die Hauptwerte eines

Stückes dauern. Hauptwerte können Viertel-, Achtel-, 16tel- oder 32stel-Noten sein.

Der Zähler gibt Auskunft, wie viele Viertel, Achtel usw. auf einen Takt kommen. Jede

Taktart bekommt durch die Lage von Betonungsakzenten einen typischen Charakter. So

werden bei einem 4/4-Takt die Zählzeit 1 stark und die Zählzeit 3 leicht betont. Bei

einem 6/8 Takt wird die Zählzeit 1 stark und die Zählzeit 4 schwach betont.

Rhythmen bestehen meist aus zwei Takten. Es gibt die verschiedensten Rhythmen

für alle möglichen Musikstile. Beispiele sind Jazz-, Funk-, Soul- und Rockrhythmen.


3.3 MIDI - Musical Instrument Digital Interface

2

3.3.1 Definition

MIDI ist ein Datenübertragungs-Protokoll für die Übermittlung, Aufzeichnung und Wie-

dergabe von musikalischen Steuerinformationen zwischen digitalen Instrumenten oder

einem PC.

Das MIDI-Protokoll wird von vielen Soundkarten in modernen Rechnern unter-

stützt. Das Protokoll wurde zu Beginn der 80er Jahre maßgeblich von Sequential Cir-

cuits und Roland entwickelt und erstmals 1983 auf der Namm-Show in Anaheim, USA,

vorgestellt. Überwacht wird der Standard von der IMA (International MIDI Associati-

on).

Für die Entwicklung von elektronischer Musik war MIDI von zentraler Bedeutung.

Waren vorher die Kommunikation zwischen Musikinstrumenten nur über herstellerspe-

zifische Schnittstellen ansteuerbar, gab MIDI nun einen Standard vor, der es erlaubt alle

MIDI-fähigen Instrumente miteinander zu verbinden.

3.3.2 Funktionsweise

Das MIDI-Protokoll überträgt keine Klänge in Wellenformen, sondern Steuerungsbe-

fehle, mit denen man elektronische Musikinstrumente, wie Keyboards, Synthesizer3 und

Sampler4 ansteuern kann. Auch der Synthesizer-Chip auf Soundkarten kann angesteuert

werden. Dazu werden die elementaren Tonparameter als Steuerungsbefehle versendet.

Beispiele sind: „NoteOn“, zum Einschalten der Note, „NoteOff“, zum Ausschalten der

Note, „KeyVelocity“, die Anschlagstärke und die Tonhöhe. Diese Befehle werden dann

von einem Klangerzeuger in Klänge umgesetzt. Auch kann man diese Steuerungsbe-

2Digitale Schnittstelle für Musikinstrumente3elektronisch gesteuertes Gerät zur Synthese von Schwingungen4elektronisches Musikinstrument, das kurze Musikaufnahmen wiedergeben kann

3.3. MIDI - MUSICAL INSTRUMENT DIGITAL INTERFACE 21

fehle empfangen und aufzeichnen, wenn man auf einem MIDI-fähigem Instrument, wie

zum Beispiel auf einem Keyboard, spielt.

Die einzelnen Noten in den verschiedenen Oktavierungen werden von 0 bis 127

durchnummeriert. Das heißt die tiefste Note hat die Nummer 0 und entspricht einem c,

cis entspricht der 1 und d einer 2 und so weiter. Die Nummer 12 ist ein c eine Oktave

höher, die Nummer 24 ein c zwei Oktaven höher. Möchte man nun ein mittleres c ab-

spielen, erzeugt man ein MIDI-Event mit „NoteOn()“ und übergibt die Notennummer

60 und die Laustärke als Parameter.

MIDI stellt neben diesen elementaren weitere spezielle Befehle zur Verfügung, mit

denen man zum Beispiel zwischen verschiedenen Klängen umschalten, oder diese Klän-

ge beeinflussen kann. Systemexklusive Meldungen stellen eine weitere Kategorie von

MIDI-Befehlen dar. Sie werden kurz „SysEx“-Befehle genannt. Mit ihnen kann man

Backups von Speicherinhalten eines Gerätes machen oder neue Betriebsysteme laden.

Ursprünglich wurde das MIDI-Protokoll für die gegenseitige Ansteuerung von di-

gitalen Musikinstrumenten wie zum Beispiel Synthesizern, Samplern, Drumcomputern,

Effektgeräten (Hall, Echo, Equalizer usw.), Masterkeyboards, Drum-Pads oder Fader-

Boxen entwickelt. Mithilfe von Hardware-Sequenzern und Computern mit Software-

Sequenzern können MIDI-Daten aufgezeichnet, abgespielt, bearbeitet und ausgegeben

werden.

Erzeugt man MIDI-Signale mit einem MIDI-fähigem Instrument, wie zum Beispiel

einem Keyboard und nimmt diese Signale auf, kann man MIDI-Dateien erzeugen, die

sehr klein sind. Im Gegensatz zu normalen Speicherung von Musik, bei der Schallwel-

len abgetastet werden und diese Informationen in Dateien gespeichert werden, werden

bei MIDI-Dateien nur die Steuerungsbefehle gespeichert. Diese Art der Speicherung

ermöglicht keine originalgetreue Wiedergabe, da der Klang durch das Klangmodul be-

stimmt wird. So kann man derselben MIDI-Spur unterschiedliche Klänge zuweisen.

Der erste Computer, der zur MIDI-Bearbeitung eingesetzt wurde, war der Atari ST.

Er war standardmäßig mit einer MIDI-Schnittstelle ausgerüstet.

Sequenzer-Programme zeichnen MIDI-Daten auf, spielen sie ab und können MIDI-

Daten manipulierten. Bekannte Sequenzer-Programme sind Cubase von der Firma Stein-


berg und Logic von Apple. Diese Programme haben mittlerweile nicht nur MIDI-Funk-

tionalität, sondern bilden komplette Studioumgebungen in einer Software ab.

MIDI-Geräte besitzten drei Anschlüsse: „MIDI-In“, „MIDI-Out“ und „MIDI-Thru“.

„MIDI-In“ wird zum Empfang, „MIDI-Out“ zum Versenden von MIDI-Daten verwen-

det. „MIDI-Thru“ sendet die auf „MIDI-In“ empfangenen Signale an weitere MIDI-

Instrumente weiter. MIDI-Kabel sind als fünfpolige DIN-Stecker realisiert. Möchte man

ein Ziel-Instrument mit einem Quell-Instrument steuern, verbindet man den „MIDI-

Out“ des Quell-Instruments mit dem „MIDI-In“ des Ziel-Instruments. Weitere Instru-

mente kann man steuern, indem man sie mit dem „MIDI-Thru“ des Ziel-Instrumentes

verbindet.

MIDI wird über eine serielle Schnittstelle übertragen. Die Geschwindigkeit beträgt

dabei 31250 Bits pro Sekunde. Jeder MIDI-Befehl enthält eine Befehlskennung, Be-

fehlsdaten, sowie eine Kanalnummer. Mit MIDI lassen sich 16 Kanäle ansteuern.

Heutzutage werden die meisten MIDI-Geräte nicht mehr über DIN-Stecker, son-

dern über neue Schnittstellen, wie USB oder Firewire angeschlossen. Mithilfe von Trei-

bern wird der MIDI-Software eine normale MIDI-Verbindung vorgetäuscht. Diese neu-

en Schnittstellen bieten eine viel schnellere Verbindung und befinden sich mittlerweile

an jedem Computer. Daraus ergeben sich Vorteile: Es können mehrere virtuelle MIDI-

Verbingungen realisiert werden, mit denen die Beschränkung auf 16 MIDI-Kanäle um-

gangen wird. Die Übertragung von „SysEx“-Meldungen werden mit USB oder Firewire

auf Echtzeit reduziert.

MIDI wird über kurze Bytefolgen ausgetauscht. Ein Byte besteht aus zwei Hexa-

dezimalziffern. Ein Statusbyte enthält einen Befehl im MIDI-Datenstrom. Auf ein Sta-

tusbyte folgt eine passende Anzahl von Datenbytes. Um Statusbytes von Datenbytes

zu unterscheiden, wird das erste Bit bei Statusbytes gesetzt, bei Datenbytes dagegen

nicht. Die zweite Hexadezimalziffer bei Statusbytes enthält den MIDI-Kanal, für den

der Befehl vorgesehen ist.

Für den Einsatz von MIDI ist der Aufbau von MIDI-Nachrichten eher uninteres-

sant. Große Bedeutung haben jedoch die Midi-Controller, mit denen man in Echtzeit

Klangparameter beeinflussen kann. Die Befehle bekommen die Controller-Nummer und


den Controller-Wert übergeben. Dabei wird unterschieden zwischen „not continuous“,

„continuous“, „channel mode“ und „controller pair“ Control-Change-Befehlen. „not

continuous“-Controller können nur die Werte „an“ oder „aus“ annehmen. „continuous“-

Controller nehmen Werte zwischen 0 und 127 an. „channel mode“-Controller sind für

die Kanalbetriebsart verantwortlich und „controller pair“-Controller können bis zu 16384

Werte annehmen. Der eine Controller übernimmt dabei die 128er Schritte (höherwerti-

ges Byte), der andere die Einer-Schritte dazwischen (niederwertiges Byte). Die Tabellen

3.2, 3.3, 3.4und3.5zeigen die wichtigsten MIDI-Controller im Überblick.

not continuous/ Ein/Aus-Schalter Controller-Nummer

sustain pedal Dämpfungs-Pedal 64

portamento on/off Portamento an/aus 65

sostenuto Sostenuto-Pedal 66

soft pedal Soft-Pedal 67

hold 2 2. Halte-Pedal 69

Tabelle 3.2: MIDI-Controller Ein- und Ausschalter

3.3.3 GENERAL-MIDI

GENERAL-MIDI wurde 1991 von der MIDI Manufacturers Association (MMA) und

dem Japan MIDI Standards Committee (JMSC) als Erweiterung des MIDI-Standards

festgelegt. Die Musikinstrumentenhersteller Roland und Yamaha haben auch die her-

stellerspezifischen Standards GS und XG festgelegt. 1999 wurde GENERAL-MIDI zu

GENERAL-MIDI 2 erweitert.

GENERAL-MIDI erweitert MIDI um Inhalte. Legt MIDI Hardware- und Protokoll-

spezifikation fest, werden in GENERAL-MIDI die Belegung der 128 Programmplätze

mit Instrumenten festgeschrieben. Ein GENERAL-MIDI-Instrument muss 24 Stimmen

gleichzeitig wiedergeben können (24-stimmige Polyphony). Dabei müssen 16 Melodie-

stimmen und 8 Perkussionstimmen zur Verfügung stehen. Die Polyphonie muss auf al-

len 16 MIDI-Kanälen zur Verfügung stehen. MIDI-Daten können auf 16 MIDI-Kanälen


continuous/ kontinuierliche Controller-Nummer

modulation wheel Modulations-Rad 1

breath cont. Blasdruck-Wandler 2

foot cont. Fußpedal 4

portamento time Portamento 5

data entry Dateneingabe 6

main volume Gesamtlautstärke 7

balance Balance 8

pan Panorama 10

expression cont. Ausdrucks-Pedal 11

external effects depth Stärke des Hall-Effektes 91

chorus depth Stärke des Chorus-Effektes 93

data increment Wert-Erhöhung 96

data decrement Wert-Erniedrigung 97

Tabelle 3.3: Kontinuierliche MIDI-Controller

channel mode/ Kanalbetriebsart Controller-Nummer

reset all controllers alle Controller zurücksetzen 121

local control off/on Local an/aus 122

all notes off alle Noten aus 123

omni mode off Kanaltrennung ein 124

omni mode on Kanaltrennung aus 125

mono mode on and poly mode off Polyphonie aus 126

mono mode on and poly mode on Polyphonie ein 127

Tabelle 3.4: MIDI-Controller Kanalbetriebsart


controller pair/ paarweise Controller-Nummer

bank select Klangspeicherbank-Wahl 0 und 32

non-registered parameter

herstellerspezifische Parameterauswahl,

die mit data increment und

data decrement verändert werden können 98 und 99

registered parameter (festgelegte Parameter):

1. pitch bend sensitivity Pitch-Bend Sensitivität100=0 und 101=0

2. fine tuning Feinstimmung 100=1 und 101=0

3. coarse tuning Grobstimmung 100=2 und 101=0

Tabelle 3.5: Paarweise MIDI-Controller

empfangen werden, wobei die Perkussioninstrumente auf Kanal 10 liegen. Das Instru-

ment muss die Anschlagdynamik unterstützen, das heißt die Festigkeit des Anschlags

wird in die Tonlautstärke umgewandelt. Weiterhin werden weitere Steuerungsparame-

ter, beispielsweise zur Effektsteuerung festgelegt. Die Tabelle3.6 zeigt die Belegung

der Programmplätze nach dem GENERAL-MIDI-Standard. Die Tabelle3.7 zeigt die

Belegung der Perkussion- und Schlagzeugklänge auf dem MIDI-Kanal 10.


Piano: Bass: Reed: Synth Effects:

1 Acoustic Piano 33 Acoustic Bass 65 Soprano Sax 97 FX 1 (rain)

2 Bright Acoustic Piano 34 Electric Bass (finger) 66 Alto Sax 98 FX 2 (soundtrack)

3 Electric Grand Piano 35 Electric Bass (pick) 67 Tenor Sax 99 FX 3 (crystal)

4 Honky-tonk Piano 36 Fretless Bass 68 Baritone Sax 100 FX 4 (atmosphere)

5 Electric Piano 37 Slap Bass 69 Oboe 101 FX 5 (brightness)

6 Electric Piano 38 Slap Bass 70 English Horn 102 FX 6 (goblins)

7 Harpsichord 39 Synth Bass 71 Bassoon 103 FX 7 (echoes)

8 Clavi 40 Synth Bass 2 72 Clarinet 104 FX 8 (sci-fi)

Chromatic Percussion: Strings: Pipe: Ethnic:

9 Celesta 41 Violin 73 Piccolo 105 Sitar

10 Glockenspiel 42 Viola 74 Flute 106 Banjo

11 Music Box 43 Cello 75 Recorder 107 Shamisen

12 Vibraphone 44 Contrabass 76 Pan Flute 108 Koto

13 Marimba 45 Tremolo Strings 77 Blown Bottle 109 Kalimba

14 Xylophone 46 Pizzicato Strings 78 Shakuhachi 110 Bagpipe

15 Tubular Bells 47 Orchestral Harp 79 Whistle 111 Fiddle

16 Dulcimer 48 Timpani 80 Ocarina 112 Shanai

Organ: Ensemble: Synth Lead: Percussive:

17 Organ 49 String Ensemble 1 81 Lead 1 (square) 113 Tinkle Bell

18 Percussive Organ 50 String Ensemble 2 82 Lead 2 (sawtooth) 114 Agogo Bells

19 Rock Organ 51 Synth Strings 1 83 Lead 3 (calliope) 115 Steel Drums

20 Church Organ 52 Synth Strings 2 84 Lead 4 (chiff 116 Woodblock

21 Reed Organ 53 Voice Aahs 85 Lead 5 (charang) 117 Taiko Drum

22 Accordion 54 Voice Oohs 86 Lead 6 (voice) 118 Melodic Tom

23 Harmonica 55 Synth Voice 87 Lead 7 (fifths) 119 Synth Drum

24 Tango Accordion 56 Orchestra Hit 88 Lead 8 (bass + lead) 120 Reverse Cymbal

Guitar: Brass: Synth Pad: Sound effects:

25 Acoustic Guitar (nylon) 57 Trumpet 89 Pad 1 (new age) 121 Guitar Fret Noise

26 Acoustic Guitar (steel) 58 Trombone 90 Pad 2 (warm) 122 Breath Noise

27 Electric Guitar (jazz) 59 Tuba 91 Pad 3 (polysynth) 123 Seashore

28 Electric Guitar (clean) 60 Muted Trumpet 92 Pad 4 (choir) 124 Bird Tweet

29 Electric Guitar (muted) 61 French horn 93 Pad 5 (bowed) 125 Telephone Ring

30 Overdriven Guitar 62 Brass Section 94 Pad 6 (metallic) 126 Helicopter

31 Distortion Guitar 63 Synth Brass 1 95 Pad 7 (halo) 127 Applause

32 Guitar harmonics 64 Synth Brass 2 96 Pad 8 (sweep) 128 Gunshot

Tabelle 3.6: Belegung der Programmplätze nach dem GENERAL-MIDI-Standard


35. Acoustic Bass Drum 51. Ride Cymbal 1 67. High Agogo

36. Bass Drum 1 52. Chinese Cymbal 68. Low Agogo

37. Side Stick 53. Ride Bell 69. Cabasa

38. Acoustic Snare 54. Tambourine 70. Maracas

39. Hand Clap 55. Splash Cymbal 71. Short Whistle

40. Electric Snare 56. Cowbell 72. Long Whistle

41. Low Floor Tom 57. Crash Cymbal 2 73. Short Guiro

42. Closed Hi Hat 58. Vibraslap 74. Long Guiro

43. High Floor Tom 59. Ride Cymbal 2 75. Claves

44. Pedal Hi-Hat 60. Hi Bongo 76. Hi Wood Block

45. Low Tom 61. Low Bongo 77. Low Wood Block

46. Open Hi-Hat 62. Mute Hi Conga 78. Mute Cuica

47. Low-Mid Tom 63. Open Hi Conga 79. Open Cuica

48. Hi Mid Tom 64. Low Conga 80. Mute Triangle

49. Crash Cymbal 1 65. High Timbale 81. Open Triangle

50. High Tom 66. Low Timbale

Tabelle 3.7: Belegung der Perkussioninstrumente nach dem GENERAL-MIDI-Standard

Kapitel 4

Lösungskonzeption

Dieses Kapitel gibt einen Überblick über die Lösungskonzeption. Erst wird eine Kurz-

beschreibung der Applikationen gegeben. Daraufhin folgt eine Funktionsübersicht, eine

Schnittstellenbeschreibung und die Funktionsweise der Anwendungen.

4.1 Kurzbeschreibung der Applikationen

ARTDrumsbietet eine realistische Simulation von Schlagzeug- und Percussioninstru-

menten. Der Benutzer steht vor einer Stereoleinwand und kann mit Schlagzeugstöcken

oder den Händen Schlagzeug oder beliebige Perkussioninstrumente spielen. Für die

Schlagzeugvisualisierung steht außerdem eine Fußmaschine zur Verfügung. Die An-

wendung berücksichtigt dabei die Anschlagsstärke. Die Instrumente werden auf der

Leinwand abgebildet und animiert, sobald ein Treffer ausgelöst wurde. Eine Webcam

nimmt den Benutzer auf, so dass er sich selbst und seine Hände im Hintergrund se-

hen kann. Der Schlagzeugsound verändert sich je nach der Position des Treffers in der

Tonhöhe und in der Panoramaeinstellung. Außerdem können Schlagzeugrhythmen aus

MIDI-Dateien geladen und auf der Leinwand angezeigt werden, so dass der Benutzer

die Rhythmen nachspielen kann.

Mit der ARMusic-Applikation soll Musik intuitiv und einfach ohne Vorwissen, nur

mithilfe der drei Raumachsen eingegeben werden können. Auf verschiedenen ARTool-

Kit-Markern werden verschiedene Instrumente für den Schlagzeugrhythmus, die Ak-

29

30 KAPITEL 4. LÖSUNGSKONZEPTION

korde und die Melodien abgebildet. Diese können mit einem Zeigepattern beeinflusst

und so Musik kreiert werden. Man wählt ein Instrument aus, indem man mit dem Zei-

gepattern auf den entsprechenden Marker tippt. Visualisiert wird das nächste Instrument

zum Zeigepattern mit einem grünen Rahmen über dem entsprechenden Marker. Ist ein

Instrument ausgewählt wird ein roter Rahmen über dem Marker gezeichnet. Außerdem

stehen eine Instrumentenauswahl, ein Mixer und ein Arrangierboard zur Verfügung.

ARTDrumsbietet:

• mit Schlagzeugstöcken oder den Händen Schlagzeug oder beliebige Perkussion-

instrumente spielen

• für die Schlagzeugvisualisierung steht eine Fußmaschine zur Verfügung

• anschlagdynamische Instrumente

• die Instrumente werden auf der Leinwand abgebildet und animiert, sobald ein

Treffer ausgelöst wurde

• es steht eine Schlagzeug- und eine Congavisualisierung zur Verfügung

• eine Webcam nimmt den Benutzer auf, so dass er sich selbst und seine Hände im

Hintergrund sehen kann

• der Schlagzeugsound verändert sich je nach Trefferort in der Tonhöhe und in der

Panoramaeinstellung

• Schlagzeugrhythmen können aus MIDI-Dateien geladen und auf der Leinwand

angezeigt werden, so dass der Benutzer die Rhythmen nachspielen kann

• die geladenen Rhythmen können in der Geschwindigkeit verändert werden, so

dass man die Rhythmen leichter erlernen kann

ARMusicbietet:

• Schlagzeugrhythmen werden auf dem virtuellen Schlagzeug abgebildet, die Ge-

schwindigkeit und der Rhythmus können durch Verschieben beeinflusst werden

4.2. SCHNITTSTELLEN-BESCHREIBUNG 31

• der Rhythmus und die Geschwindigkeit gelten auch für das Keyboard und die

Hammondorgel

• Akkorde können auf dem virtuellen Keyboard eingegeben werden und in Tonhö-

he, Tondauer und Tonlautstärke verändert werden

• Melodien können auf der virtuellen Hammondorgel eingegeben werden und in

Tonhöhe, Tondauer und Tonlautstärke verändert werden

• mit der Instrumentenauswahl können für das Keyboard und die Hammondorgel

verschiedene Klänge gewählt werden

• mit dem Mixer können 16 MIDI-Kanäle in Laustärke, Panorama, Chorus- und

Hall-Effekt und Mute beeinflusst werden

• mit dem Arrangierboard können Musiksequenzen aufgenommen und arrangiert

werden

4.2 Schnittstellen-Beschreibung

ARTDrumsbenutzt den ARTTracker (siehe6.1) zum Erfassen der Raumposition von

Schlagzeugstöcken oder Händen. Dieser optische Tracker bietet eine hohe Updatera-

te der Raumpositionen von 60 Hertz. Damit ist es möglich, auch schnelle Bewegun-

gen, wie sie bei dem Spielen mit Schlagzeugstöcken auftreten, genau zu erfassen. Zwei

Drumsticks und eine Schlagzeugfußmaschine wurden mit ARTTracker-Bodies ausge-

stattet. Damit ist es möglich, die exakte Postion der Drumsticks und des Schlägels der

Fußmaschine im Raum zu erfassen. Das Videobild des Benutzers wird mithilfe des AR-

Toolkits (siehe6.2.1) erfasst. Ausgegeben werden Visualisierungen von Instrumenten

und Animationen und das Videobild des Benutzers auf einer Stereoleinwand mithil-

fe des ARToolKits. Die erzeugten MIDI-Events werden an den Synthesizer-Chip der

Soundkarte oder an ein angeschlossenes Keyboard gesendet, welche die Steuerinforma-

tionen in Klänge umwandeln und über die Boxen ausgeben.


Bei derARMusic-Applikation werden die Positionsdaten durch das ARToolKit ge-

liefert. Bei diesem markerbasierten Tracking liefern ausgedruckte Muster Raumposi-

tion und Orientierung. Eine Videokamera liefert das Videobild, indem die Muster er-

kannt werden. Der Benutzer kann die Muster verschieben und damit die gelieferten

3D-Koordinaten manipulieren. Ausgegeben wird das Videobild mit den 3D-Grafiken

der Instrumente und den Animationen auf dem Monitor. Die erzeugten MIDI-Events

werden wieder an die angeschlossenen MIDI-Geräte geliefert, die den Klang produzie-

ren.

Abbildung 4.1: Grundlegendes Konzept

Figur 4.1 zeigt die grundlegende Funktionsweise. Das ARToolKit oder der ART-

Tracker liefern 3D-Positions- und Orientierungsdaten. Diese werden auf für MIDI ver-

wertbare Eingabewerte von 0 bis 127 skaliert und je nach Funktion, dem entsprechenden

MIDI-Befehl übergeben. Dieser wird dann an die angeschlossenen MIDI-Instrumente

übermittelt, welche die entsprechenden Klänge erzeugen. MIDI-Befehle werden mithil-

fe der Programmbibliothek MIDIShare (siehe6.2.2) verarbeitet. Die Programmbiblio-

theken OpenGL und GLUT visualisieren die MIDI-Events und geben entsprechende

Grafiken und Animationen aus.

4.3. FUNKTIONSWEISE DER APPLIKATIONEN 33

4.3 Funktionsweise der Applikationen

4.3.1 ARTDrums

Bei der Schlagzeugvisualisierug ist der Raum von links nach rechts in vier räumliche

Zonen unterteilt, die auf die einzelnen Teile des Schlagzeugs HiHat, Snare, Ride- und

Crash-Becken aufgeteilt sind. Anhand der x-Postion der Drumsticks im Raum sind sie

eindeutig einem bestimmten Teil des Schlagzeugs zugeordnet. Visualisiert wird dies

durch einen grünen Rahmen für den rechten und einem blauen Rahmen für den linken

Drumstick über dem entsprechenden Schlagzeugteil der 3D-Modelle. Bei einer zwei-

ten Visualierung werden zwei Congas dargestellt. Hier wird der Raum in zwei Teile

unterteilt.

Befindet sich ein Drumstick unter einer festgelegten Höhe, wird die Anschlagd-

dynamik berechnet und ein MIDI-Event mit dem entsprechenden Klang erzeugt und

gesendet. Visualisiert wird dies durch die Änderung der Rahmenfarbe in rot und gelb

und durch das Austauschen der 3D-Grafiken. Das HiHat und die Becken werden leicht

versetzt gezeichnet um eine Bewegung zu simulieren. Die Snare- und Bassdrum-3D-

Modelle werden ausgetauscht, um eine Bewegung des Fells zu simulieren. Hat der

Schlägel der Fußmaschine einen Winkel über 0 Grad in der Vertikalen, wird die An-

schlagstärke berechnet, ein entsprechender MIDI-Event gesendet und die 3D-Grafik

animiert. Für das Spielen von Trommelwirbeln oder exakter Rhythmen werden Drum-

pads eingesetzt, die auf Ständern in der Anschlagshöhe montiert werden. Diese Gum-

mimatten haben beim Anschlag mit den Drumsticks eine geringe Eigenlautstärke und

imitieren das Rebound-Verhalten1 eines echten Schlagzeugfelles.

Um die mit MIDI-Dateien geladenen Schlagzeugrhythmen zu animieren, wird je

nach Schlagzeugteil, entweder ein virtueller Drumstick oder eine rote durchsichtige

Kugel auf dem entsprechenden Schlagzeugteil gezeichnet, sobald ein entsprechender

„NoteOn“-Event im Rhythmus auftritt. So wird dem Benutzer der Rhythmus auf den

verschiedenen Teilen des Schlagzeugs visualisiert. Außerdem kann der Benutzer seine

1Rückprall-Effekt


eigenen Rhythmen aufzeichnen und wieder abspielen. Die Geschwindigkeit der gelade-

nen Rhythmen kann verändert werden, um sie leichter nachspielen zu können.

Abbildung 4.2: Konzept ARTDrums

4.3.2 ARMusic

Eingabe von Musik im Raum

Durch die drei Raumkoordinaten der x-,y- und z-Achse ergeben sich neue Möglichkei-

ten für die Eingabe von Musik. Jeder der drei Achsen kann frei mit allen möglichen

MIDI-Parametern belegt werden. Neben der Nachbildung von klassischen Anschlags-

formen wie dem Anstrich der Geige oder dem Anschlag auf dem Klavier können auch

neue Formen des Anschlags realisiert werden.

Geliefert werden die Raumkoordinaten zum Steuern der Instrumente und zum Navi-

gieren auf dem Mixer und dem Arrangierboard, von einem auf den Zeigefinger aufsteck-

baren ARToolKit-Marker. Dieses Zeigepattern hat eine Seitenlänge von 20 Millimeter

und liefert damit sehr einfach die Raumkoordinaten des Zeigefingers. Ein zweiter Mar-

ker wird für die Selektion und Deselektion von einzelnen Parametern beim Mixer oder

bei dem Arrangierboard benutzt.


Die Möglichkeit, Musik mithilfe von Raumkoordinaten einzugeben, bedarf eines

Konzepts, bei dem festgelegt wird, wann oder wo die Note oder der Akkord ausge-

löst und wann diese wieder beendet werden. Bildet man klassische Anschlagsformen,

wie die des Klaviers oder der Geige nach, wird die Note beim Drücken der Taste oder

mit dem Anstrich der Saiten begonnen und mit dem Loslassen oder dem Abheben des

Bogens beendet. Für die Eingabe im Raum muss nun auch eine Möglichkeit des Be-

ginnens oder Beendens der Note gefunden werden. Das Auslösen kann durch eine be-

stimmte Raumposition oder zeitlich erfolgen. Die einfachste Form ist die Umsetzung

von klassischen Anschlagsformen, wie sie mit dem Geigenanschlag prototypisch um-

gesetzt wurde. Im Folgenden werden einige Eingabemethoden vorgestellt, welche auch

in einer ersten Version implementiert wurden.

Abbildung 4.3: Screenshot Eingabestil Atmospheric

Eingabestil Atmospheric Hält man das Zeigepattern bei diesem Eingabestil in einen

markierten Bereich der rechten Hälfte des Videobilds, wird die Note angeschlagen. Die

y-Position des Zeigepatterns bestimmt dabei die Notenhöhe. In einem markierten Be-

reich der linken Hälfte des Videobildes kann man die Note wieder ausklingen lassen.


Mithilfe der z-Achse kann die Note moduliert werden. Bewegt man das Zeigepattern in

den Raum hinein, wird die Note stufenlos erhöht, bewegt man den Zeigepattern hinaus,

wird die Note stufenlos erniedrigt. Damit lassen sich einfache Vibratoeffekte2 erzeu-

gen. Dieser Eingabestil ist gut für atmosphärische Klangflächen geeignet, da diese gut

moduliert werden können und monophon ansprechend klingen.

Abbildung 4.4: Konzept Eingabestil Atmospheric

Eingabestil Violinbogen Bei diesem Eingabestil wird der Anschlag eines Violinbo-

gens nachempfunden. Begonnen wird in der rechten Videobildhälfte. Bewegt sich das

Zeigepattern nun in eine Richtung wird eine NoteOn-Message an den Klangerzeuger

geschickt. Macht der Marker nun einen Richtungswechsel, wird die alte Note ausge-

schaltet und die neue Note angeschaltet. Die y-Position des Markers gibt dabei die No-

tenhöhe vor.

Eingabestil Matrix-Loop-Player Der Eingabestil Matrix-Loop-Player bildet einen

16-Step-Loop-Player in 3D nach. In gewissen Zeitabständen wird die aktuelle 3D-Position

des Markers in einen Noten-Event umgewandelt. Dabei wird die y-Position des Zeige-

patterns als Notenhöhe, die x-Position als Notenlänge und die z-Position als Notenlaut-

2Schwankungen der Tonhöhe


Abbildung 4.5: Konzept Eingabestil Violinbogen

stärke interpretiert. Es werden 16 Noten aufgenommen und im Kreis (geloopt) wieder

abgespielt. Ist das Zeigepattern nicht sichtbar werden die aufgenommenen Noten immer

wieder im Kreis abgespielt. Ist das Zeigepattern sichtbar werden neue Noten aufgenom-

men und abgespielt. Dieses Konzept stellte sich am praktikabelsten für die Eingabe von

Musik bei geringer Updaterate der Kamerabilder heraus. Da die meisten Webcams, bei

einer Auflösung von 640x480 Pixeln nur 15 Bilder pro Sekunde liefern, werden die

Bewegungen der Hand nicht in Echtzeit erfasst. Dies kann problematisch bei Einga-

bestilen werden, die eine Bewegung erfassen. Aufgrund der niedrigen Framerate der

Kamera, werden tonauslösende Bewegungen verzögert erkannt und damit der Ton ver-

spätet gesendet. Dies wäre zum Beispiel beim Eingabestil Violinbogen der Fall. Beim

Eingabestil Matrix-Loop-Player dagegen ist die Verzögerung der Bewegung durch die

niedrige Framerate nicht so wichtig. Die Raumdaten werden immer zu einem exakten

Zeitpunkt in Musikparameter umgerechnet. Dabei ist es weitgehend unwichtig ob eine

veraltete Raumposition oder eine aktuelle zur Verfügung steht. Der wichtigste Punkt ist,

das der Klang zu einem definitiven Zeitpunkt gesendet wird.

Eingabestil Akkord Dieser Eingabestil entspricht dem des Matrix-Loop-Player, nur

werden anstatt einzelnen Noten, Akkorde abgespielt. Der abzuspielende Akkord ergibt


Abbildung 4.6: Konzept Eingabestil Matrix-Loop-Player

sich aus der y-Position des Zeigepatterns, die Akkordlänge aus der x-Position und die

Lautstärke aus der z-Position. Es werden 8 diatonische Stufenakkorde, je nach Syste-

meinstellung in verschiedenen Tonarten abgespielt. Der Grundton des Akkordes ergibt

sich aus der y-Position. Aus diesem Grundton wird dann ein diatonischer Stufenakkord

(siehe3.2.2) gebildet und abgespielt. Dadurch ergibt sich ein harmonisches Klangbild.

Instrumentenauswahl

Die Instrumentenauswahl stellt hohe Anforderungen an die Menüart. Das GENERAL-

MIDI-Protokoll stellt 128 verschiedene Instrumente zur Verfügung. Diese sind in Kate-

gorien wie Tasten-, Streich-, Bläser- oder elektronische Instrumente unterteilt. Das erste

Konzept sah eine zweistufige Auswahl der Instrumente vor. Im ersten Selektionsschritt

wählt man die Kategorie aus, im zweiten das passende Instrumente. Diese Konzept hat

den Vorteil einer übersichtlichen und auch schnellen Auswahl des entsprechenden In-

struments. Die Vorauswahl ist schnell kategorisiert, im zweiten Selektionsschritt muss

nur noch zwischen acht verschiedenen Instrumenten ausgewählt werden. Man hat also

trotz der großen Anzahl, schnell und übersichtlich das passende Instrument ausgewählt.

Dem gegenüber steht die Schwierigkeit der Interaktion in drei Dimensionen. Insbeson-


dere bei der Interaktion in Augmented Reality-Umgebungen mit den eigenen Händen

stellte sich die Zweistufigkeit des Systems als besonders fehleranfällig heraus. Reduzier-

ten sich in späteren Konzepten der Selektionsprozess auf eine Geste, muss hier zuerst

die Kategorie ausgewählt und selektiert werden. Danach folgt die Auswahl des Instru-

ments und dessen explezite Selektion. Es müssen also ingesamt vier Interaktionen durch

den Benutzer vollzogen werden. Damit vervierfacht sich nicht nur der Zeitaufwand, son-

dern auch die Fehleranzahl der einzelnen Selektionsprozesse. Insgesamt stellte sich das

Konzept als ungeeignet heraus.

In einem zweiten Konzept wurde der Selektionsprozess auf eine Geste reduziert. An-

gelehnt an das Konzept des Eingabestils „Atmospheric“ (siehe4.3.2) wurde die rechte

Seite des Videobildes als Erhöhung und die linke Seite als Erniedrigung des aktuellen

Instrumentes gewertet. Der mittlere Teil des Videobildes ist neutral. In der linken oberen

Ecke wird das aktuelle Instrument als Text angezeigt. Der Benutzer positioniert das Zei-

gepattern nun mit seiner in Hand in den entsprechenden Teil des Videobildes und kann

damit einfach und schnell das aktuelle Instrument auswählen. Bleibt das Zeigepattern

länger im Plus- oder Minus-Bereich der Videobildes wird die Zeitspanne zwischen dem

Instrumentwechsel erniedrigt. Analog zur Verweildauer des Zeigepattern im jeweiligen

Bereich erfolgt der Instrumentenwechsel also schneller oder langsamer. So kann schnell

zu entfernten Instrumenten navigiert oder im nahen Bereich bewusst ausgewählt wer-

den. Eine explizite Selektion des Instrumentes, wie im vorherigen Konzept entfällt. Die

Fehleranzahl ist stark reduziert und kann schnell korrigiert werden.

Dieser Selektionsprozess wurde nun noch mit dem Konzept des Ringmenüs (siehe

2.2.4) erweitert. Hierbei werden die 128 GENERAL-MIDI-Instrumente auf einem vir-

tuellen Fließband angeordnet, das sich in der Endlichkeit des Raums verliert. Sichtbar

sind also nur die vordersten neun Instrumente. Das vorderste ist das aktuelle und ausge-

wählte Instrument. Die 3D-Modelle repräsentieren die GENERAL-MIDI-Instrumente,

so das eine Auswahl allein durch die grafischen Repräsentation gewährleistet ist. Be-

findet sich der Marker im rechten Teil des Videobildes wird das aktuelle Instrument

um eins erhöht, im linken Teil um eins erniedrigt. Der mittlere Teil des Videobilds ist

wieder neutral. Visualisiert wird die Auswahl nun mit dem Ringmenü. Es gibt insge-


samt neun Positionen auf dem Fließband. Wird das Instrument mit dem Zeigepattern

um eins erhöht, werden die Instrumente im Uhrzeigersinn um eine Position nach rechts

verschoben. Befindet sich das Zeigepattern im linken Teil des Videobildes werden die

Instrumente um eine Position nach links verschoben. Somit ist der Selektionsprozess

sehr einfach und intuitiv und wird grafisch durch die Repräsentation und durch das Vor-

rücken der verschiedenen Instrumente visualisiert.

Mischen von Soundsequenzen

Beim Mischen von Soundsequenzen muss eine hohe Anzahl von Funktionen auf gerin-

gen Raum zur Verfügung stehen. 16 verschiedene MIDI-Kanäle haben jeweils Regler

für den Hall- und Choruseffekt, die Balance, den Muteschalter und die Lautstärke. Da-

mit ergeben sich für die 16 Kanäle 80 Parameter, die auf geringem Raum zu kontrol-

lieren sind. Natürlich wäre auch die Sichtbarkeit und Kontrolle von nur einem Kanal

möglich. Damit wäre viel Platz vorhanden, um die nur fünf Parameter zu kontrollieren.

Dem gegenüber steht aber die Übersicht und das Verhältnis der verschiedenen Laut-

stärken zueinander. Grade die Übersicht der Stellung der einzelnen Lautstärkerregler

zueinander gibt ein Bild über die Mischung im finalen Mix. Auch die Dezentralisierung

und das Verlegen der Lautstärkerregler zu den Instrumenten hin war ein angedachtes

Konzept. Es wurde aber aus denselben Gründen verworfen. Die Wahl der passenden

Metapher ist hier äußerst schwierig. Letztlich bleibt bei einer so großen Anzahl von

Parametern nur die eins zu eins Übersetzung aus der Realität übrig.

Der Mixer wurde, wie in der Realität in 16 MIDI-Kanäle unterteilt. Für jeden Kanal

stehen die Parameter Hall- und Choruseffekt, Balance, Mute und die Lautstärke zur

Verfügung. Die ersten drei Parameter sind als Drehregler ausgeführt. Dies hat der Vorteil

von extrem wenig Platzbedarf. Für das Stummschalten des Kanals wurde ein Mute-

Schalter implementiert, die Lautstärke ist als Fader3 ausgeführt. Damit ist eine sehr

exakte und übersichtliche Kontrolle der Lautstärke möglich. Außerdem gibt es noch

einen Masterregler für die Kontrolle der Gesamtlautstärke.

3Schieberegler


Die Navigation zur Auswahl eines Parameters wird durch die x- und y-Achse ge-

währleistet. Mit dem Verschieben des Zeigepatterns in x-Richtung wechselt man den

Kanal, mit dem Verschieben in y-Richtung wechselt man die verschiedenen Paramter

des Kanals. Die Navigation auf dem Mixer wird mit verschiedenen Rahmnen visuali-

siert. Ein grüner Rahmen gibt den aktuellen Kanal an. Ein roter Rahmen markiert den

aktuellen Parameter. Hat man einen Parameter ausgewählt, selektiert man diesen, indem

man den Daumen mit dem aufgestecktem zweiten Zeigepattern zum Zeigefinger führt.

Visualisiert wird die erfolgreiche Selektion mit einem gelben Rahmen. Zur Deselektion

wiederholt man diesen Vorgang. Dies soll die Art einer Greifgeste abstrahieren. Damit

ist ein geringer Lernaufwand und eine hohe Akzeptanz verbunden.

Weitere Konzepte zur Selektion mussten aufgrund der geringen Updaterate der Raum-

koordinaten durch das ARToolKit verworfen werden. Werden die x- und die y-Achse

zur Navigation verwendet, steht die z-Achse zur Selektion zur Verfügung. Ein Tippen

auf den jeweiligen Parameter kann als Selektion gewertet werden. Durch die geringe

Updaterate der Raumkoordinaten fehlt aber die nötige Präzision zur Auswertung die-

ser Geste. Außerdem ist bei der hohen Anzahl der Parameter auf geringem Raum ein

schnelles Verschieben auf den nächsten Paramter beim Tippen mit dem Zeigefinger vor-

programmiert. Damit war dieses Konzept sehr fehleranfällig.

Arrangieren von Soundsequenzen

Auch hier wurde das klassische Konzept zum Arrangieren von Soundsequenzen von

2D-Sequenzern übernommen. Die 16 MIDI-Spuren werden auf einer Oberfläche un-

tereinandergelegt. Werden MIDI-Daten auf einer Spur aufgenommen, erscheint je nach

Dauer der aufgenommenen Daten, ein Balken, der die Daten repräsentiert. Diese Bal-

ken haben verschiedene Farben für die verschiedenen Kanäle. Auf einem Kanal können

verschiedene Sequenzen nacheinander aufgenommen werden.

Navigiert wird wieder mit dem Zeigepattern in x- und y-Richtung. Ein grüner Rah-

men bezeichnet das aktuelle Segment. Selektiert wird dieses Segment wieder mit dem

zweiten Zeigepattern und der Selektionsgeste. Ist ein Segment selektiert ist es mit einem

roten Rahmen visualisiert. Nun kann das Segment an eine andere Position verschoben


oder kopiert werden. Ein roter Cursor gibt den Ort an, an den das Segment kopiert wer-

den kann. Navigieren kann man diesen Cursor wieder mit dem Verschieben des Zeige-

patterns in x- und y-Richtung. Eine zweite Selektionsgeste kopiert oder fügt das ausge-

wählte Segment an die aktuelle Position ein. So kann man ein Segment auf verschiedene

Positionen auf derselben oder anderen Spuren verschieben und so ein Arrangement er-

stellen. Motive können kopiert und aneinandergereiht werden, Segmente kann man auf

verschiedene Spuren kopieren und ihnen damit neue Instrumente zuweisen.

Kapitel 5

Praktische Ergebnisse/ Evaluierung

Um Sicherzustellen, dass die Applikation die vorgebenen Ziele in den verschiedenen

Kategorien erreicht hat, wurden Benutzertest durchgeführt.

5.1 Testvorbereitung

Zuerst wurden Vortests nach einer Vorschulung durchgeführt um Sicherzustellen, dass

die Probanden die minimalen Vorraussetzungen zum Verständnis und zur Benutzung

der Anwendungen verstanden haben. Die Vortests belegen, ob der Einführungstext alle

erforderlichen Komponenten zum elementaren Verständnis und zur Benutzung bereit-

stellt. Der Einführungstext stellt sicher, dass alle Probanden die gleichen Vorausset-

zungen zum Benutzen der Anwendung haben. Der Text gibt eine Einführung in die

verschiedenen zu untersuchenden Bereiche. Der erste Teil gibt einen Überblick über

die verschiedenen Instrumente und wie man sie beeinflussen kann. Weitere Teile geben

einen kurzen Überblick über das Selektieren des aktuellen Instruments, die Instrumen-

tenauswahl und das Selektieren bei Arranger und Mixer.

5.2 Testablauf

Es wurden freie Tests durchgeführt, das heißt die Probanden sollten nur mit dem Wis-

sen des Einführungstextes die Applikation benutzen. Weitere Hilfen während dem Test

43

44 KAPITEL 5. PRAKTISCHE ERGEBNISSE/ EVALUIERUNG

waren nicht erlaubt. Die Tests wurden mit 5 Probanden durchgeführt, alle Personen hat-

ten grundlegende Computerkenntnisse und waren keine Profis im Umgang mit Compu-

tern. Zu jedem Testgebiet mussten die Probanden Aufgaben durchführen. Zuerst wurde

ein Grundtest zum Thema „Eingabe von Musik im Raum“ durchgeführt. Die Benutzer

sollten Töne, Akkorde und Rhythmen mit den verschiedenen Instrumenten eingeben

und beeinflussen. Die Hauptfrage diese Testblocks war, ob Musik intuitiv und einfach

mit der Belegung der drei Raumachsen mit elementaren Musikparametern, eingegeben

werden kann. Der Erweiterungstest überprüfte die Instrumentenauswahl. Es sollten den

verschiedenen Instrumenten verschiedene Klänge zugewiesen werden. Die Zusatzauf-

gabe widmete sich dem Arrangieren und Mixen. Hier stellte sich vor allem die Frage

von Interaktion in drei Dimensionen mit komplexen Funktionen und der Funktionalität

der integrierten Selektionsgeste. Ein Spezialtest wurde mit derARTDrums-Applikation

durchgeführt. Hier waren die Fragestellungen verteilt auf die visuelle Rückkopplung

und die didaktische Komponente der Visualisierung von abspielbaren Schlagzeugrhyth-

men. Ein zweiter Grundtest wurde nach drei Tagen durchgeführt um herauszufinden, ob

den Probanden die abstrakte Funktionsweise im Kurzzeitgedächnis erhalten blieb.

5.3 Nachbefragung

Bei der Nachbefragung wurden zu jedem Testblock Fragen gestellt, die mit dem Schul-

notensystem und teilweise mit Text beantwortet wurden. Es gab Fragekomplexe zu

den Testblocks „Eingabe von Musik im Raum“, „Instrumentenauswahl“, „Arrangieren

und Mixen“ undARTDrums. Weiterhin gab es Zusatzfragen zu den Themenkomplexen

„Benutzerfeedback durch Visualisierung“, „Affordances und Constraints“, „Augmented

Reality“, „Environment Performance“, „Benutzerfreundlichkeit“ und „Nützlichkeit“.

5.4. AUSWERTUNG DER ERGEBNISSE 45

5.4 Auswertung der Ergebnisse

5.4.1 Eingabe von Musik im Raum

Die Eingabe von Musik im Raum, mit der Belegung von elementaren Musikparametern

auf den drei verschiedenen Raumachsen, wurde sehr gut angenommen. Die Benutzer

empfanden die Eingabe als sehr intuitiv und konnten sich keine andere Belegung der

Raumachsen vorstellen.

5.4.2 Instrumentenauswahl

Die Darstellung der Instrumentenauswahl auf dem Marker war zu klein skaliert. Da-

durch konnten die einzelnen Instrumente kaum erkannt und unterschieden werden. Ei-

ne größere Skalierung der Instrumentenauswahl würde das Problem schnell lösen. Die

Menüart an sich wurde als intuitiv und unterstützend für den Selektionsprozess emp-

funden. Den Zusammenhang zwischen dem Instrumentenname als 2D-Text in der lin-

ken oberen Bildschirmhälfte und dem 3D-Modell auf dem virtuellen Ringmenü zu er-

kennen, fiel den Probanden schwer. Hier wäre ein 3D-Text direkt über der 3D-Grafik

wünschenswert. Die Beschränkung auf wenige 3D-Modelle, statt der Repräsentation

der 128 GENERAL-MIDI-Instrumente hat den Selektionsprozess eher eingeschränkt,

als unterstützt.

5.4.3 Arrangieren und Mixen

Die Gestenerkennung für das Selektieren und Deselektieren, wurde sehr schnell an-

genommen und umgesetzt. Probleme kamen durch das Springen zum nächsten Regler

bei geringen Bewegungen der Hand auf. Da bei dem Mixer sehr viele Parameter ma-

nipuliert werden können, standen für jeden Drehregler nur wenige reale Millimeter im

Bewegungsspielraum der Hand zur Verfügung. Abhilfe kann durch die Auswahl auf nur

wenige manipulierbare Drehregler, oder auf nur einen oder mehrere Kanalzüge geschaf-

fen werden. Außerdem würde eine maßstabsgerechte Visualisierung des Mixers Abhilfe

schaffen. Dies würde aber die Benutzung einer Datenbrille, anstatt einer Webcam und


eines Monitors vorraussetzen. Vorschläge zur alternativen Visualisierung mit dem Ver-

zicht auf Drehregler und dem Einsetzen nur von Schiebereglern wurden gemacht. Die

Schieberegler wurden generell besser angenommen. Dies wurde durch die größere Ska-

lierung und die damit bessere Sichtbarkeit der Laustärkerveränderung erklärt. Auch war

der Bereich für Handbewegungen zum Beeinflussen der Schieberegler viel größer.

5.4.4 ARTDrums

Die Visualisierung des rechten Drumsticks mit einem blauen Rahmen und des linken mit

einem grünen Rahmen für das aktuell ausgewählte Schlagzeugteil und den Farbwechsel

von Grün nach Rot und von Blau nach Gelb wurde teilweise als unübersichtlich bewer-

tet. Die leichten Tonhöhen- und Panoramaveränderungen abhängig von der Raumpo-

sition wurden als sehr unterstützend für das Spielen des Instruments empfunden. Die

Visualisierung der von außen geladenen Schlagzeugrhythmen mit der Möglichkeit der

Tempoänderung wurden als sehr praktisch bewertet. Die Möglichkeit die Geschwindig-

keit der geladenen Rhythmen zu ändern wurde als unterstützend für den Lernprozess

empfunden.

5.4.5 Benutzerfeedback durch Visualisierung

Die Benutzer empfanden die Visualisierungen als sehr unterstützend. Durch die zu klei-

ne Skalierung der Instrumente wurde die Visualisierung der Töne und Akkorde aber oft

übersehen. Den meisten Benutzern erschien diese Visualisierung noch zu komplex. Die

Visualisierung der Schlagzeugrhythmen empfanden die Benutzer als sehr überzeugend

und vorteilhaft für das Erlernen von Rhythmen.

5.4.6 Affordances und Constraints

„Affordances und Constraints“ waren eine große Hilfe für den Benutzer. Die Benutzer

empfanden es als sehr praktisch, dass alle Instrumente die gleiche Geschwindigkeit hat-

ten und durch das Schlagzeug beeinflusst werden konnten. Die Auswahl des Rhythmus

mit dem Schlagzeug empfanden die Benutzer im Gegensatz zur Geschwindigkeitswahl

5.4. AUSWERTUNG DER ERGEBNISSE 47

als zu abgebrochen, da bei einem Wechsel der Rhythmus kurz aussetzt und dann wieder

von vorne beginnt. Das Einsetzen des Taktes war manchmal verwirrend, da der Benut-

zer eine zeitlang ohne audiophiles Feedback war. Die Übertragung des Rhythmus auf

den Step-Sequenzer für Melodien wurde gut angenommen.

5.4.7 Augmented Reality

Die elementaren Fragen in diesem Bereich waren: Ist Augmented Reality geeignet für

die Eingabe von Musik im Raum und bringt Augmented Reality Vorteile für die Eingabe

und Manipulation von Musik. Die Benutzer empfanden die Eingabe von Musik in Aug-

mented Reality als sehr sinnvoll und intuitiv. Die Probanden bestätigten einen schnellen

Zugriff zu den elementaren Musikparametern und deren komplexen Verbindungen. Pro-

bleme traten immer wieder durch technische Limitierungen, wie dem Verdeckung von

Markern und der Änderung der Lichtverhältnisse auf.

5.4.8 Environment Performance

Die Kontrolle der Musikparameter über die drei Raumachsen und das Melodieinstru-

ment waren für die meisten Benutzer die effizientesten Komponenten des Systems. Die

Laustärkesteuerung wurde als sehr effektiv empfunden. Es kam immer wieder zu Pro-

blemen bei der Auswahl der einzelnen Instrumente, wenn die Marker durch eine Hand

oder das Zeigepattern verdeckt wurden. Für manche Benutzer war die Anzahl der Gra-

fiken und Animationen unübersichtlich.

5.4.9 Benutzerfreundlichkeit

Die Benutzerfreundlichkeit wurde allgemein als intuitiv und einfach beurteilt. Proble-

me traten bei der Auswahl der Instrumente auf. Sie waren insgesamt zu klein skaliert.

Auch ohne Vorschulung wären die meisten Benutzer nach einer bestimmten Zeit mit

der Steuerung zurechtgekommen. Die Benutzer empfanden, dass mehrere ihrer Sinne

angesprochen wurden, einige bemerkten jedoch eine Überbeanspruchung der visuellen

Komponente.


5.4.10 Nützlichkeit

Das System wurde als transparent bewertet. Oft wurde der Benutzer durch technische

Probleme abgelenkt. Augmented Reality wurde als nützlich für die Visualisierung und

die Eingabe von Musik bezeichnet. Die Möglichkeiten von Augmented Reality zur Vi-

sualisierung der Töne, Akkorde und Schlagzeugrhythmen wurde als sehr sinnvoll er-

achtet. Die Benutzer empfanden die Anwendung auf die natürlichen Fähigkeiten des

Menschen abgestimmt. Der Zugang zu den technischen Möglichkeiten wurde als ein-

fach beschrieben. Die meisten Benutzer empfanden, dass ihnen komplexe Interaktions-

möglichkeiten geboten wurden.

5.5 Allgemeines Fazit

Die aufgetretenen Probleme lassen sich in zwei Kategorien einteilen. Eine Kategorie

wird bestimmt durch die technischen Limitierungen der Augmented Reality-Technik,

die andere Kategorie besteht aus leichter lösbaren Problemen.

Die größeren Probleme wurden durch die Technik bestimmt. Die Marker sind all-

gemein sehr empfindlich gegen veränderten Lichteinfall und direktes Sonnenlicht. Da-

durch wurden Marker immer wieder nicht erkannt, was zu einer Unterbrechung der

Musik führte. Dies wurde als sehr störend eingestuft.

Das größte Problem aber bestand in der Auswahl des aktuellen Instruments. Die Ap-

plikation folgt der Regel, dass wenn der Zeigemarker im Bild sichtbar ist, die Position

der Instrumente „eingefroren“ werden. Das heißt sie werden auf ihrer aktuellen Position

angezeigt, auch wenn der jeweilige Marker verdeckt ist. So kann man das Zeigepattern

für die Steuerung der Instrumente benutzen und diese sind trotzdem sichtbar. Ist das

Zeigepattern für die Kamera aber kurz nicht sichtbar, werden die Instrumente, durch

die Verdeckung des Zeigepatterns und der Hand über den Markern, nicht mehr ange-

zeigt. Solche Ausfälle der Sichtbarkeit von Markern treten immer wieder durch leichte

Veränderungen der Lichtverhältnisse auf.

Ein weiteres großes Problem bestand im Aktionsbereich des Benutzers. Durch die

Größe des Zeigepatterns ist die Entfernung der Kamera zur Plattform eingeschränkt. Die

5.5. ALLGEMEINES FAZIT 49

Kamera kann das Zeigepattern nur auf eine Entfernung von ungefähr 70 cm erkennen.

Dadurch konnte nur auf einem geringen Aktionsradius mit den Instrumenten interagiert

werden. Abhilfe könnte hier durch die Benutzung einer Datenbrille geschaffen werden.

Einfach zu lösende Probleme sind die größere Skalierung von Instrumenten und

der Instrumentenauswahl. Alle 128 GENERAL-MIDI-Instrumente für die Instrumen-

tenauswahl konnten aus Zeitmangel nicht modelliert werden. Dadurch wurde der Se-

lektionsprozess eher eingeschränkt. Hier könnte mit der Visualisierung aller 128 Instru-

mente der Auswahlprozess stark unterstützt werden. Der Wechsel des Rhythmus beim

Schlagzeug wurde als zu „abgebrochen“ empfunden. Hier wäre ein gleitender, gemisch-

ter Übergang von einem zum anderen Rhythmus wünschenswert.

Kapitel 6

Technische Realisierung

Diese Kapitel gibt einen Überblick über die technische Realisierung der beiden Appli-

kationen. Eine kurze Beschreibung des ARTTrackers erläutert die Funktionsweise. Es

folgt die Beschreibung der Funktionsweise der verwendeten APIs, als Basis der Ap-

plikation. Danach folgt getrennt nach den ApplikationenARTDrumsundARMusic, die

Programmstruktur im Überblick, Methoden im Detail und die Beschreibung der Reali-

sierung von Instrumentenauswahl, Mixer und Arrangierboard.

6.1 ARTTracker

Der ARTTracker ist ein optisches Trackingsystem der Firma A.R.T. GmbH. Das System

besteht aus zwei Infrarot-Kameras und der Software DTrack. Die beiden Kameras wer-

den über einen PC synchronisiert, die Software DTrack liefert die Positionsdaten über

das Netzwerk an vorgegebene Rechner, wo sie mithilfe von einfachen Headerdateien,

die in das eigene Projekt inkludiert werden, empfangen werden können. Die beiden

ARTTracker-Kameras senden Infrarotstrahlen aus, die von den sogennanten „Bodies“

reflektiert werden. Diese „Bodies“ bestehen aus einer Anordnung von vier Kugeln mit

einem Durchmesser von 10 Millimeter auf einem Leichtmetallkreuz. Die Kugeln sind

mit einer reflektierenden Folie überzogen, die die Infrarotstrahlen stark reflektieren.

Diese Reflektionen werden von den Kameras aufgenommen. Anhand der Anordnung

der Kugeln kann damit die Position der „Bodies“ im Raum errechnet werden.

51

52 KAPITEL 6. TECHNISCHE REALISIERUNG

6.2 Verwendete APIs

Abbildung 6.1: Verwendete APIs

6.2.1 ARToolKit

Überblick

ARToolkit (6) ist eine in C entwickelte Software-Bibliothek, die eine einfache Entwick-

lung von Augmented Reality-Applikation erlaubt. Sie steht für verschiedene Betriebssy-

steme, wie Windows, Linux, SGI, MacOs und Matlab zur Verfügung. Die Software wird

unter der GPL-Lizenz vertrieben und steht für wissenschaftliche Zwecke mit den kom-

pletten Quellcodes im Internet zur Verfügung. Es werden alle grundlegenden Funktio-

nen zur Verfügung gestellt um eine markerbasierte Augmented Reality-Applikation zu

entwickeln. Ausgegeben werden können die errechneten Bilder, außer auf dem Monitor

auch auf Optical- oder auch auf Video-See-Through Head Mounted Displays (HMDs).

Mit den mitgelieferten Kalibrierungs-Tools kann verschiedene Hardware an das System

angepasst werden. So kann der Entwickler eigene Webcams, Head Mounted Displays

und eigene Markermuster in das System integrieren. ARToolkit benutzt Bildverarbei-

6.2. VERWENDETE APIS 53

tungstechnologie, um die Position der echten Kamera in Position und Orientierung, ab-

hängig von Karten mit Mustern, zu bestimmen. Relativ zu diesen Karten können dann

computergenerierte Objekte gesetzt werden.

Funktionsweise des ARToolKits

Alle Arbeitsschritte werden im ARToolKit in einer Hauptschleife abgearbeitet. Zu-

erst wird das nächste verfügbare Videobild der Videokamera eingelesen. Mithilfe eines

Schwellwertes wird dieses Bild binarisiert, das heißt in ein Schwarz-Weißbild umge-

wandelt. Mithilfe von Bildverarbeitungs-Algorithmen wird das Bild nach Rechtecken

durchsucht und diese in einer Liste abgelegt. Bei den meisten dieser Rechtecke han-

delt es sich nicht um den gewünschten Marker, sondern um andere Gegenstände im

Bild, wie Schatten oder Teile der Hand. Nun wird jedes Rechteck mit den vortrainierten

Mustern verglichen. Findet der Algorithmus eine Übereinstimmung, hat er einen Mar-

ker gefunden. Werden mehrere Übereinstimmungen gefunden, entscheidet der Grad der

Ähnlichkeit. Für jedes dieser Rechtecke wird nun die Translation und die Rotation ab-

hängig zum Kamerakoordinatensystem bestimmt und in einer 3x4 Matrix gespeichert.

Diese Matrix wird dann dazu benutzt die virtuelle Kamera zu positionieren. Mithilfe

der OpenGL-Bibliothek wird die virtuelle Kamera positioniert und die 3D-Objekte ge-

zeichnet.

Die Applikation unterteilt sich in sechs grundlegende Schritte:

1. Initialisierung der Applikation

2. „Grabben“ eines Videobildes

3. Finden der Marker im Videobild

4. Berechnen der Kamera-Transformation

5. Zeichnen der virtuellen Objekte

6. Schließen der Videoroutine


Initialisiert wird die Applikation mit der Funktion „init()“. Diese öffnet die Video-

routine und liest die verschiedenen Applikations-Parameter ein. Diese werden aus Da-

teien ausgelesen. Eine enthält Informationen über die zu suchenden Muster, eine weitere

Informationen über die Verzerrung der benutzten Webcam. Die Auflösung der Webcam

wird durch einen Initialisierungsdialog an die Applikation übergeben.

Die Schritte zwei bis fünf werden nun in einer Schleife bis zum Beenden des Pro-

gramm wiederholt. „arVideoGetImage()“ liefert das aktuelle Videobild der Kamera und

mit „argDrawMode2D()“ wird in den Zeichenmodus für das Videobild umgeschaltet.

Mit der Funktion „argDispImage()“ wird das aktuelle Videobild angezeigt. „arDetect-

Marker()“ findet nun die Rechtecke in diesem Bild und vergleicht sie mit den vortrai-

nierten Markern. Bei einem erfolgreichen Vergleich wird die Transformation und Ro-

tation zum Kamerakoordinatensystem mit „arGetTransMat()“ berechnet und in einer

3x4 Matrix gespeichert. Nun wird mit „argDrawMode3D()“ in den OpenGL 3D-Modus

umgeschaltet und mit der „draw()“-Funktion die 3D-Modelle gezeichnet.

Die „Cleanup()“-Methode schließt beim Beenden die Videoroutine und beendet die

Applikation.

ARToolKit Typ-Definitionen

Die beiden wichtigsten Typendefinitionen im ARToolKit verwalten die Marker- und

Objekt-Informationen. Der Typ „ARMarkerInfo“ speichert die aktuellen Werte für einen

im Bild gefundenen Marker. „cf“ gibt den Ähnlichkeitswert an, die Marker-ID wird

durch „id“ definiert. „pos[2]“ gibt den Mittelpunkt des Markers an, „line[4][3]“ enthält

die vier Außenlinien und „vertex[4][2]“ enthält die vier Eckpunkte des Markers.

t ypede f s t r u c t {

i n t area ;

i n t id ;

i n t dir ;

double cf ;

double pos [ 2 ] ;

double line [ 4 ] [ 3 ] ;


double vertex [ 4 ] [ 2 ] ;

} ARMarkerInfo ;

Listing 6.1: Typ-Definition ARMarkerInfo aus dem ARToolKit

„ObjectDataT“ ist die Struktur für die Verwaltung von 3D-Objekten. Sie enthält

für jedes definierte Objekt die aktuelle Transformationsmatrix, die korrespondierende

Marker-ID, sowie einen Boolean-Wert, der besagt, ob der Marker im Videobild sichtbar

ist.

t ypede f s t r u c t {

i n t id ;

double marker_width ;

double trans [ 4 ] [ 2 ] ;

bool visible ;

} ObjectDataT ;

Listing 6.2: Typ-Definition ObjectDataT aus dem ARToolKit

VRML-Unterstützung

Das ARToolKit unterstützt das Laden und Darstellen von VRML-Objekten auf den Mar-

kern. VRML ist ein Format, das mithilfe von Grundprimitiven, Transformation, Rotati-

on, Skalierung und Szenegraphen, 3D-Objekte in ASCII-Dateien beschreibt. In der Da-

tei „vrmldata“ werden die Anzahl der zu erkennenden Marker und die Verweise zu den

Vrml-Informationsdateien festgelegt. Außerdem enthalten Sie den Verweis zur Marker-

datei, die Größe des Markers und einen „Offset“ zum Mittelpunkt.

Die Vrml-Informationsdateien enthalten die Angabe über die zu verwendende VRML-

Datei, sowie Informationen über eine zu benutzende Translation, Rotation und Skalie-

rung. Zudem werden Beleuchtungswerte für jedes einzelne 3D-Modell festgelegt.

Anzahl der zu registrierenden Muster

2


pattern 1

VRML Wrl/ 3D−Modell_1 . dat Vrml −Informationsdatei

Data / Pattern1 . patt dem Modell zugeordneter Marker

50 .0 Kantenlänge des Markers in mm

0 .0 0 .0 Offset zum Mittelpunkt

pattern 2

VRML Wrl/ 3D−Modell_2 . dat

Data / pattern2 . patt

50 .0

0 .0 0 .0

Listing 6.3: Marker-Informationsdatei

Wrl / model . wrl Angabe über die zu verwendende VRML −Datei

0 .0 0 .0 0 .0 Translation − x , y , z vom Mittelpunkt des Markers

90 .0 1 .0 0 .0 0 .0 Rotation Winkel + Achse , hier 90

Grad um die X −Achse drehen

2 .5 2 .5 2 .5 Skalierung x , y , z

LIGHT DIR gerichtete Lichtquelle

0 .5 Ambient

1 .0 Intensität

1 .0 1 .0 1 .0 RGB

0 .0 0 .0 1 .0 Richtung

Listing 6.4: Vrml-Informationsdatei

6.2.2 MIDIShare

Funktionen

MIDIShare (4) ist eine Echtzeit-Bibliothek für die Entwicklung von MIDI-Applikationen

vom Grame Computer Music Research Lab aus Lyon/ Frankreich. Sie stellt dem Ent-

wickler Funktionen auf hohem Abstraktionsniveau zur Verfügung. MIDIShare wird


seit 1989 entwickelt und stellt damit eine ausgereifte Bibliothek zur Verfügung. Die

Software wird unter der GNU-Lizenz vertrieben und läuft unter Linux-, MacOS- und

Windows-Betriebssystemen. Sie steht für verschiedene Programmierumgebungen, wie

C, C++, Common Lisp, Pascal und Java zur Verfügung. Aufbauend auf die MIDIShare-

Bibliothek gibt es zwei weitere Bibliotheken. Eine für die Darstellung von Musiknoten

und eine für die Entwicklung von Mehrspursequenzern.

MIDIShare bietet folgende Funktionen:

• zeitlich geordnete, abstrakte MIDI-Events, die jeweils mit einem Millisekunden-

Zeitstempel versehen sind

• einem „event and task scheduler“, der MIDI-Events zu ihrem fälligen Zeitpunkt

an den „communication manager“ liefert

• der „communication manager“ liefert die Musik-Events zur Client-Applikation, je

nachdem wie die Verbindungen gesetzt wurden; diese können durch den Benutzer

dynamisch gesetzt werden

• Aufgaben können für die Zukunft auf die Millisekunde geplant und durch MIDI-

Share in Echtzeit auf Interrupt-Level aufgerufen werden.

• von außen kommende MIDI-Events oder globale Kontextänderungen (ein neuer

Client startet eine Session, Modifikationen von Verbindungen zwischen Applika-

tionen...) können in Echtzeit mit benutzerdefinierten Echtzeitalarmen behandelt

werden

Konzeptueller Aufbau

Die MIDIShare-Bibliothek basiert auf einem Client-/ Server-Modell und besteht kon-

zeptuell aus sechs Komponenten: einem „event memory manager“, einem „time mana-

ger“ und dem „synchronizer“, einem „task manager“, einem „communication manager“,

einem „event und task scheduler“ und den MIDI-Treibern.

Der „event and task scheduler“ kümmert sich um das Zurverfügungstellen von MIDI-

Events und geplanten Aufgaben zum geplanten Zeitpunkt. Er erlaubt es, MIDI-Events


und Aufgaben in der Zukunft automatisch aufrufen zu lassen. Die Möglichkeit zur Pla-

nung von Funktionsaufrufen und zum Senden von MIDI-Events ist sehr nützlich in

Echtzeitapplikationen, in denen mehrere Aufgaben parallel mit einem präzisem „Ti-

ming“ aufgerufen werden müssen.

Der „time manager“ und „synchronizer“ verwaltet die aktuelle Zeit des Systems. Er

bietet eine Auflösung von einer Millisekunde.

Der „communication manager“ leitet Musik-Events vom „event and task scheduler“

und anderen Eingabe-Treibern zur Client-Applikation und zu den Ausgabetreibern, je

nachdem, wie die Verbindungen vom Benutzer festgelegt wurden.

Der „task manager“ ruft die Funktionen auf, die vom „Event und Task Scheduler“

geliefert werden.

Der „event memory manager“ ist ein dynamischer Speicher-Manager, der speziell

auf die Bedürfnisse von Echtzeit-Operationen auf Interrupt-Basis ausgerichtet ist. Er

bietet Applikationen einen effizienten Weg für das Verwalten, Kopieren und Löschen

von MIDI-Events.

Die MIDI-Treiber verwalten die MIDI-Kommunikation zwischen den 256 MIDI-

Ports.

MIDIShare-Events

MIDI-Kommunikation mit der MIDIShare-Bibliothek basiert auf MIDI-Events auf ho-

hem Abstraktionsniveau. Diese Events können schneller und einfacher verarbeitet wer-

den, als MIDI-Pakete die auf niedrigerem Abstraktionsniveau benutzt werden. So müs-

sen große „System-Exklusive-Meldungen“ nie in mehrere Pakete aufgeteilt werden,

sondern können als ein MIDI-Event, wie jedes andere versendet, empfangen und be-

handelt werden. MIDI-Events sind nicht auf MIDI-Nachrichten beschränkt, sondern

können auch alle MIDI-Datei-Events verarbeiten. Alle MIDIShare-Events haben einen

Zeitstempel, einen MIDI-Kanal und das Ausgabegerät, welches durch die Portnummer

definiert ist. MIDI-Events können von Client-Applikationen empfangen und gesendet

werden. Client-Applikationen benötigen einen Eingangs- und eine Ausgangsport, um

mit allen anderen MIDI-Geräten zu kommunizieren.


Tabelle6.1 listet die verschiedenen Typen auf die ein MIDI-Event annehmen kann.

Die Tabelle enthält alle MIDI-Messages (siehe Tabellen3.2, 3.3, 3.4 und 3.5), sowie

spezifische MIDIShare-Messages, wie zum Beispiel der Typ „typeNote“. Dieser kor-

respondiert zu einer MIDI-Note, mit ihrer Tonhöhe, Tonlänge und Tonlaustärke. Ein

neues MIDI-Event kann mit der MIDIShare-Funktion MIDINewEv() erzeugt werden,

der der gewünschte Typ übergeben wird. Weitere Typen sind typeKeyOn“ und „type-

KeyOff“, die exakt den Spezifikationen des MIDI-Protokolls entsprechen und die Ton-

höhe und Tonlautstärke übergeben bekommen. Ein weiterer wichtiger MIDI-Event ist

vom Typ „typeCrtlChange“, der eine aus Tabellen3.2, 3.3, 3.4 und 3.5 gelieferten

Control-Change-Wert übergeben bekommt und diesen dann ausführt. Damit sind zum

Beispiel einfache Panorama- oder Effektstärkewechsel möglich. Mit dem Typ „typePro-

gChange“ kann einfach zwischen den Klängen auf verschiedenen Kanälen umgeschaltet

werden. Übergeben wird ein Wert aus der Tabelle3.6 oder3.7. Mit dem Typ „type-

PitchWheel“ werden fließende Tonhöhenänderungen realisiert. Der Typ bekommt als

Übergabeparameter ein höherwertiges und ein niederwertiges Byte mit dem Umfang

von 0-127 übergeben. Damit lassen sich bis zu 16384 Abstufungen in der Tonhöhen-

änderung vollziehen (siehe3.3.2). Um ein MIDI-Event wieder freizugeben wird die

Funktion „MIDIFreeEv()“ benutzt.

Datenstruktur eines MIDIShare-Events

Ein MIDIShare-Event ist eine Datenstruktur, die als Listenelement realisiert wurde.

Dessen Komponenten können mit den „SetField()“ und „GetField()“-Methoden mani-

puliert werden. Ein MIDI-Event enthält folgende Komponenten:

• dasLink-Feld enthält den Verweis auf das nächste MIDI-Event

• dasDate-Feldenthält den Zeitstempel des MIDI-Events in Millisekunden

• dasrefNum-Feld enthält die Referenznummer

• dasevTypeenthält die Art des Events

• dasPort-Event gibt den MIDI-Port an


Name Kode Kommentar

typeNote 0 pitch, velocity and duration (16bit)

typeKeyOn 1 pitch and velocity

typeKeyOff 2 pitch and velocity

typeKeyPress 3 pitch and after touch pressure

typeCtrlChange 4 control and value

typeProgChange 5 program change

typeChanPress 6 channel after touch pressure

typePitchWheel 7 Lsb and Msb

typeSongPos 8 Lsb and Msb

typeSongSel 9 song selection

typeClock 10

typeStart 11

typeContinue 12

typeStop 13

typeTune 14

typeActiveSens 15

typeReset 16

typeSysEx 17 data1..dataN

typeStream 18 byte1..byteN

typePrivate 19..127 arg1, arg2, arg3, arg4

typeProcess 128 arg1, arg2, arg3, arg4

typeDProcess 129 arg1, arg2, arg3, arg4

typeQFrame 130 msg type (0..7) and value

TypeCtrl14b 131

TypeNonRegParam 132

TypeRegParam 133

TypeSeqNum extended types from MIDIFile 1.0 134

TypeText 135

TypeCopyright 136

TypeSeqName 137

TypeInstrName 138

TypeLyric 139

TypeMarker 140

TypeCuePoint 141

TypeChanPrefix 142

TypeEndTrack 143

TypeTempo 144

TypeSMPTEOffset 145

TypeTimeSign 146

TypeKeySign 147

TypeSpecific 148

TypeReserved 149..254

Tabelle 6.1: MidiShare-Typen


• dasChan-Feldenthält den MIDI-Kanal

MIDIShare-Funktionen

Öffnen und Schließen einer MIDIShare-Session Zuerst wird überprüft, ob MIDIS-

hare im Speicher installiert ist. MIDIShare wird mithilfe einer dll- und einer Header-

Datei in das eigene Projekt inkludiert. Die Verbindungen zu den MIDI-Out-Treibern

werden mithilfe einer externen Treiber-Applikation realisiert. Dort werden die 256 MIDI-

Share-Ports mit den Geräten, wie zum Beispiel dem MIDI-Synthesizer, der Soundkarte

oder dem externen Keyboard verbunden. Mit der Funktion „MIDIOpen()“ wird nun

eine neue MIDIShare-Session initialisiert. Es wird Speicher für diese Applikation re-

serviert und eine eigene Referenznummer zurückgegeben, mit der man die spezifische

Applikation ansprechen kann. Diese Referenznummer wird auch der „MIDIClose()“-

Funktion übergeben, die die Applikation wieder schließt. Es können bis zu 63 simultane

MIDIShare-Applikationen geöffnet werden.

Kommunikation und Verbindungen Damit eine Applikation empfangen und sen-

den kann, muss sie erst mit anderen Ziel- und Quell-Applikationen verbunden werden.

MIDIShare-Applikationen können frei miteinander verbunden werden. Jede Applika-

tion kann als Quell- und auch als Ziel-Applikation verwendet werden. MIDI-Events

werden dabei in Echtzeit zwischen den Applikationen ausgetauscht. Dieser Mecha-

nismus erlaubt eine sehr transparente Verbindung zwischen normalerweise unabhän-

gigen Applikationen. MIDI-Hardware-Ein- und Ausgänge werden durch eine Pseudo-

Applikation mit dem Namen „MIDIShare“ und der Referenznummer 0 verwaltet. Um

eine Applikation mit der „Außenwelt“ kommunizieren zu lassen, müssen diese zuerst

mit der „MIDIShare“-Applikation verbunden werden. Die „MIDIConnect()“-Funktion

erlaubt das Ein- und Ausschalten von Verbindungen zwischen Applikationen. Dabei

werden nur die Referenznummern und eine 1 für das Setzen oder eine 0 für das Tren-

nen einer Verbindung übergeben. Es gibt keine Beschränkungen für Verbindungen zwi-

schen einzelnen MIDIShare-Applikationen. So kann eine MIDIShare-Applikation auch

mit sich selbst verbunden werden.


Senden und Empfangen Sobald eine MIDIShare-Applikation verbunden ist, kann

sie MIDI-Events empfangen und senden. Jede Applikation hat einen Empfangspuffer,

in den die MIDIShare-Applikation eine Kopie des empfangenen MIDI-Events legt. Die-

se können von anderen MIDIShare-Applikationen oder von „außen“, zum Beispiel von

einem Keyboard stammen. Die MIDIShare-Funktion „MIDICountEvs()“ liefert die An-

zahl der im Empfangspuffer liegenden MIDI-Events. Mit der Funktion „MIDIGetEv()“

können diese MIDI-Events dann aus dem Puffer abgeholt werden. Für die zu empfan-

genden MIDI-Events können Filter mit den Methoden „MIDISetFilter()“ und „MIDI-

GetFilter()“ gesetzt werden. Mit dem ersten Öffnen der MIDIShare-Applikation wird

der MIDI-Timer gestartet. Der Timer hat eine Genauigkeit von einer Millisekunde und

versieht jedes empfangene und gesendete MIDI-Event mit einem Zeitstempel. Mit der

Funktion „MIDIGetTime()“ kann jederzeit die genaue Zeit abgefragt werden. MIDI-

Events können mit drei verschiedenen Funktionen versendet werden. „MIDISendIm()“

sendet das übergebene MIDI-Event sofort, „MIDISend()“ und „MIDISendAt()“ erlau-

ben das zeitversetzte Senden von MIDI-Events.

MIDIShare-Sequenzen MIDIShare bietet elementare Funktionalität für das Verwal-

ten von Sequenzen an. Dabei werden MIDI-Events in zeitlich geordneten Listen ver-

waltet. Die „MIDINewSeq()“-Funktion erstellt eine neue MIDI-Sequenz, die „MIDI-

AddSeq()“-Funktion fügt ein MIDI-Event dieser Sequenz hinzu, wobei die zeitliche

Reihenfolge erhalten bleibt. Mit „MIDIApplySeq()“ kann man alle „MIDI-Events einer

Sequenz einzeln einer Funktion übergeben. Die „MIDIClearSeq()“-Funktion wiederum

löscht die Sequenz und gibt den Speicher frei.

Event and Task Scheduler Der MIDIShare-„Event und Task Scheduler“ ist auf das

Konzept von Alarmen aufgebaut. Ein Alarm ist eine Funktion, dessen Adresse zu MI-

DIShare durch die entsprechende Applikation gesendet wird. MIDIShare ruft dann die-

se Funktion in Echtzeit auf. Jede Applikation kann zwei Kategorien von Alarmen er-

zeugen. Die erste „MIDISetApplAlarm()“-Funktion warnt die Applikation vor globa-

len Änderungen in MIDIShare. Die zweite „MIDISetRcvAlarm()“-Funktion informiert


über neu eingetroffene MIDI-Events im Empfangspuffer. Diese Alarme werden immer

auf Interrupt-Basis ausgeführt und haben Zugang zu allen MIDIShare-Funktionen, au-

ßer „MIDIOpen()“ und „MIDIClose()“. Sobald der „Receive-Alarm“ gesetzt wird, kann

die Applikation ihre eigenen Echtzeitaufgaben organisieren, indem es seinen eigenen

Empfangspuffer benutzt. Im Gegensatz zu traditionellen MIDI-Events, können priva-

te Events dazu benutzt werden, um von einer Applikation an sich selbst geschickt zu

werden. Diese werden dazu benutzt, um eine Applikation daran zu „erinnern“, eine

Aufgabe zu einem präzisen Zeitpunkt auszuführen. Wenn dieser Zeitpunkt gekommen

ist, schiebt MIDIShare den privaten Event in den Empfangspuffer der Applikation, wo

es von dieser, wie ein normaler MIDI-Event aufgenommen und verarbeitet wird. Ein

weiterer Mechanismus ist in MIDIShare für die von Aufgaben integriert. Zeitversetzte

Funktionsaufrufe können mit den Funktionen „MIDITask()“ oder „MIDIDTask“ geplant

werden. An diese Funktionen werden Aufrufargumente und die Adresse der Funktion

übergeben. MIDIShare legt nun ein spezielles MIDI-Event vom Typ „typeProcess“ oder

„typeDProcess“ an, das zum geplanten Zeitpunkt ausgeführt wird. Dabei wird die Ap-

plikationsumgebung gespeichert und die Funktion ausgeführt. Diese geplanten Funk-

tionen werden aber nicht sofort ausgeführt, sondern in einer Liste der auszuführenden

Aufgaben für die jeweilige Applikation gespeichert. Die „MIDICountDTasks“-Funktion

liefert die Anzahl der anstehenden Aufgaben für die jeweilige Applikation. Die nächste

anstehende Aufgabe wird dann mithilfe der „MIDIExec1DTask“-Funktion ausgeführt.

Da diese „MIDI-Tasks“ auf Interrupt-Basis ausgeführt werden, muss das Betriebssy-

stem nicht benutzt werden. Unter bestimmten Umständen ist das Löschen von bereits

geplanten, aber noch nicht ausgeführten Aufgaben nötig. Mit der Funktion „MIDIFor-

getTask()“ können diese gelöscht werden. Auch mit „MIDIDTask()“ geplante Aufga-

benlisten können mit „MIDIFlushDTasks“ gelöscht werden.


6.2.3 Player-Library

Überblick

Die Player-Bibliothek (3) erlaubt die Entwicklung eines kompletten Mehrspur-MIDI-

Share-Sequenzers. Jede „Player“-Instanz ist eine MIDIShare-Applikation mit 256 Spu-

ren, vier verschiedenen Synchronisationsmodi, Event-Verfolgung und „Loop“-Markern.

Eine Player-Instanz benutzt intern MIDIShare-Sequenzen. Es stehen Funktionen zum

Lesen und Schreiben von MIDI-Dateien und zum Umwandeln in MIDIShare-Sequenzen

zur Verfügung. Die Bibliothek steht für das Macintosh- und das Windows-Betriebssystem

zur Verfügung.

Überblick über die Bibliotheksfunktionen

Öffenen und Schließen eines PlayersEin neuer „Player“ wird mithilfe der „Open-

Player()“-Funktion geöffnet. Zurückgegeben wird eine einzigartige Referenznummer,

die die MIDIShare-Applikation identifiert. Diese Referenznummer wird an alle „Player“-

Funktionen übergeben. Ein leerer „Player“ benutzt ein Standardtempo von 120 Schlä-

gen pro Minute, einen 4/4-Takt und einen Zeitwert von 500 „Ticks“ pro Viertelnote.

Ein „Tick“ ist die interne Zeiteinheit und korrespondiert exaxt zu einer Millisekun-

de. MIDIShare-Sequenzen werden in den „Player“ mithilfe der „SetAllTrackPlayer()“-

Funktion geladen. Ein MIDIShare-Player benutzt eine „Tempo-Map“-Spur, die anstatt

des Standard-Tempos und dem Standard-Takt benutzt werden kann. Nach dem Öff-

nen des „Players“ wird dieser mit dem MIDI-Ein- und Ausgängen verbunden. Da ein

„Player“-Objekt wie eine MIDIShare-Applikation behandelt wird, kann es genauso mit

weiteren „Playern“ oder anderen MIDIShare-Applikationen mithife der „MIDIConnect()“-

Funktion verbunden werden. Geschlossen wird der „Player“ mithilfe der „ClosePlayer()“-

Funktion. Diese gibt die internen Sequenzen frei und schließt die MIDIShare-Applikation.

Transportkontrolle Der „Player“ kann mit „StartPlayer()“ gestartet und mit „Pause-

Player()“ in den Pause-Modus gesetzt werden. Dabei werden die ausstehenden MIDI-

“Events“, wie fehlende „KeyOffs“ und „SustainOffs“ nicht gesendet. Mit „ContPlayer“


startet der „Player“ von der derzeitigen Position, mit „StopPlayer()“ wird der „Player“

gestoppt und die fehlenden MIDI-Events gesendet. Mit „ForwardStepPlayer()“ und „Back-

wardStepPlayer()“ spielt der „Player“ den vorhergehenden oder folgenden Akkord un-

ter Berücksichtungen von stummen oder auf „solo“ gestellten Spuren. Den aktuellen

„Player“-Status kann man mit der Funktion „GetStatePlayer()“ jederzeit abfragen. Der

Status kann entweder auf „kIdle“ für „Beschäftigt“, „kPause“ für den Pause-Modus,

„kRecording“ für den Aufnahme-Modus, „kPlaying“ für den Abspiel-Modus oder „kWai-

ting“, wenn der „Player“ auf Synchronisation von außen wartet, gesetzt werden.

Um eine neue Spur aufzunehmen, muss man mithilfe der „RecordPlayer“-Funktion

eine Spur auswählen und dann den „Player“ vom Anfang oder der aktuellen Position

starten. Während der Aufnahme werden die empfangenen MIDI-Events in der gewähl-

ten Spur gespeichert. Eine Aufnahme kann in zwei Modi erfolgen. Der „kMixMode“-

Modus mixt die empfangenen MIDI-Events mit den bereits auf Spur gespeicherten, der

„kEraseMode“-Modus löscht zuvor alle auf der Spur befindlichen MIDI-Events. Diese

Modi werden mit der „SetRecordModePlayer()“-Funktion gesetzt. Filter können mit der

„SetRecordFilterPlayer“ gesetzt werden.

Verwaltung der Spuren Jeder Player enthält ein internes Arrangement, in dem alle

Spuren gemischt sind. Ein Player hat 256 Spuren, auf die einzelnen zugegriffen, ma-

nipuliert und aufgenommen werden kann. Spuren werden intern durch ihre Referenz-

nummer der MIDI-Events auf ihnen unterschieden. Das heißt, das alle MIDI-Events auf

der Spur 0 eine Referenznummer von 0 haben, alle MIDI-Events auf der Spur 1 eine

Referenznummer von 1. Lädt man eine Mehrspur-MIDI-Datei, werden die verschiede-

nen Spuren automatisch auf einzelne MIDIShare-Sequenzen verteilt. Möchte man ei-

ne neue Mehrspur-Sequenz in einen „Player“ laden, müssen die verschiedenen Spuren

verschiedene Referenznummern haben. MIDIShare-Sequenzen werden mit den Funk-

tionen „SetAllTrackPlayer()“ für alle Spuren oder „SetTrackPlayer()“ für eine einzelne

Spur in einen Player geladen. Zum Extrahieren von Sequenzen aus „Playern“ werden

die Funktionen „GetAllTrackPlayer()“ oder „GetTrackPlayer()“ analog benutzt. Mit der


Funktion „SetParamTrackPlayer()“ kann eine einzelne Spur stumm geschaltet werden

oder als einzig abzuspielende ausgewählt werden.

Verwalten der internen Position Die Position im Arrangement wird intern mit ei-

ner „Tick“-Einheit verwaltet. Manipulieren kann man diese entweder über die musi-

kalischen Einheiten Takt, Schlag und Einheit oder in Echtzeit. Mit der Funktion „Set-

PosMsPlayer()“ kann die aktuelle Position in Echtzeit verändert werden, „SetPosBBU-

Player()“ verändert die Position mit musikalischen Einheiten.

Zustandkontrolle Das Verfolgen von MIDI-Events sichert, dass der Player, egal von

wo er gestartet wurde, immer den richtigen Klang abspielt. Der Player verwaltet intern

Programm-, Lautstärke-, Panorama- und andere MIDI-Controller-Wechsel, die in der

jeweiligen Spur vorkommen. Dies gilt für beide Abspielrichtungen, vorwärts und rück-

wärts. So wird unabhängig von der Startposition des Players immer der richtige Klang

mit den richtigen Parametern abgespielt.

Das Verwalten von „Loops“ 1

„Loop“-Marken, können mithilfe von „SetLoopStartMsPlayer()“ und “SetLoopEndMs-

Player()“ in Echtzeit oder mit „SetLoopStartBBUPlayer()“ und „SetLoopEndBBUPlayer()“

in musikalischen Einheiten gesetzt werden. Mit „SetLoopPlayer()“ werden „Loops“ ein-

und ausgeschaltet.

Verwalten des aktuellen Status Für die Anzeige liefert „GetStatePlayer()“ die aktu-

elle Position entweder in Echtzeit oder in musikalischen Einheiten. Diese Funktion kann

in regelmäßigen Zeitabständen aufgerufen werden, um die aktuelle Position anzuzeigen.

Mit „GetEndScore()“ kann die letzte Position im Player abgefragt werden.

1„Loops“ sind Musiksequenzen, die im Kreis abgespielt werden. Kommt man zum Ende der Sequenz,

wird am Anfang der Sequenz wieder begonnen.

6.3. IMPLEMENTIERTE ANWENDUNGEN 67

Verwalten von MIDI-Dateien Die zwei Funktionen „MIDIFileLoad()“ und „MIDI-

FileSave()“ erlauben das Lesen und Schreiben von MIDI-Dateien und das Konvertieren

in MIDIShare-Sequenzen.

6.3 Implementierte Anwendungen

6.3.1 Gemeinsame MIDI-Funktionalität

Für beide ApplikationenARTDrumsund ARMusicwurde eine gemeinsame Basisbi-

bliothek von MIDI-Funktionen implementiert. Diese haben gegenüber den MIDIShare-

Funktionen den Vorteil einer weiteren Abstrahierung. MIDI-Events können anhand der

Eingabe-Parameter einer Methode direkt erzeugt, manipuliert und gesendet werden.

Außerdem wird intern immer die richtige MIDIShare-Applikations-Referenznummer

übergeben. So entfällt das Aufrufen einzelner MIDIShare-Methoden für immer wieder

benötigte Aufgaben.

Mit „initMIDI()“ und „initPlayer()“ werden Methoden zum Erzeugen von MIDI-

Share-Applikationen zur Verfügung gestellt. „closePlayer()“ und „closeMIDI()“ schlie-

ßen diese Applikationen wieder.

Es werden auch Methoden zum Erzeugen, zum Senden und zum Manipulieren von

MIDI-Events zur Verfügung gestellt. Mit „playNote()“, „sendKeyOn()“ und „sendKey-

Off()“ können MIDI-Noten mit einer bestimmten Tonhöhe, einer Tonlautstärke und ei-

ner Notenlänge erzeugt und auf einem bestimmten Kanal direkt gesendet werden. Mit

„sendBankSelect()“ und „sendProgramChange()“ wird eine Bank ausgewählt und ein

neues Instrument auf einem bestimmten Kanal eingestellt. Mit „sendControlChange()“

können alle möglichen MIDI-Events, wie zum Beispiel die Steuerung der Effekte oder

der Panoramaeinstellung manipuliert werden. „sendPitchWheel()“ erlaubt die stufenlo-

se Erhöhung und Erniedrigung von Noten.

Außerdem werden Methoden zum Laden und Speichern von MIDI-Dateien mit

„loadMIDIFile()“ und „saveMIDIFile()“ zur Verfügung gestellt. Methoden zum Starten,

Stoppen, Pausieren und Aufnehmen von Playern stellen die Methoden „startPlayer()“,


„stopPlayer()“, „pausePlayer()“ und „record()“ zur Verfügung. Mit „getTempo()“ und

„setTempo()“ kann die Geschwindigkeit der einzelnen Player verändert werden. „getT-

racksNumber()“ liefert die Anzahl von Tracks in einer bestimmten Player-Applikation.

6.3.2 ARTDrums

Abbildung 6.2: ARTDrums mit Congavisualisierung

Programmstruktur im Überblick

Die ARTDrums-Applikation wird in der „init()“-Methode initialisiert, der folgende Pa-

ragraph gibt einen Überblick. Die Anwendung ist als Multithreading-Applikation im-

plementiert. Dies wurde durch die Einbindung des ART-Trackers nötig. Verarbeitet die

Hauptschleife die Videobilder und wird dadurch höchstens dreißig mal pro Sekunde

aufgerufen, muss die Methode, welche die Trackerpositionen behandelt sechzig Mal pro

Sekunde aufgerufen werden. Eine Verarbeitung der Trackerdaten in der Hauptschleife

würde damit die Anzahl der Positionsdaten auf dreißig beschränken und damit die La-


Abbildung 6.3: ARTDrums mit Schlagzeugvisualisierung

tenz2 enorm erhöhen. Dadurch ist es nötig, dass die Hauptschleife und die Methode zur

Verarbeitung der Positionsdaten parallel ablaufen. Hier wird im übernächsten Paragraph

ein Überblick gegeben.

Initialisierung In der „init()“-Methode werden alle Komponenten, die zum Betrieb

der Applikation benötigt werden aufgerufen. Die „initARTServer()“-Methode setzt einen

neuen ART-Server auf, der die Body-Raumpositionen und Winkel über das Netzwerk an

einem bestimmten Windows-Socket empfängt und an die Methode „handleART()“ wei-

terleitet. Diese Methode ist als „Callback“-Methode ausgelegt, so dass bei jedem Ein-

treffen von neuen Positionsdaten die Methode aufgerufen wird. „initMultithreading()“

setzt eine neue Multithreading-Umgebung auf. Ihr wird die Methode „handleART()“

übergeben. Damit wird diese Methode in einem seperaten Thread behandelt und kann

bis zu sechzig Mal pro Sekunde aufgerufen werden. „initMIDI()“, „initPlayer()“ und

„initRecordPlayer()“ initialisieren drei neue MIDIShare-Applikationen. Die erste ver-

waltet die zu erstellenden MIDI-Events beim Spielen des Schlagezeugs oder der Percus-

2Verzögerungszeit


sioninstrumente. Die zweite lädt vorgefertigte Rhythmen, die sich bei Bedarf abspielen

lassen. Die dritte verwaltet die aufzunehmenden MIDI-Events. „initARToolkit()“ ruft

nun elementare Methoden zum Laden der 3D-Grafiken, der Kamera-Paramter und der

Marker-Dateien auf (siehe6.2.1). „startVideoCapture()“ startet nun das Einlesen der

Bilder. „startMainLoop()“ ruft die Hauptschleife auf, die nun für jedes Videobild ein-

mal durchlaufen wird.

Die Methode „KeyEvent“ verwaltet Tastatureingaben durch den Benutzer. Wird von

Benutzer die „Escape“-Taste gedrückt schließt eine „cleanup()“-Methode alle initiali-

sierten Komponenten. Mit „r“ werden alle aktuellen MIDI-Events aufgezeichnet. Mit

„p“ können diese abgespielt werden. Mit „d“ werden durch mehrmaliges Drücken ver-

schiedene Rhythmen abgespielt. Mit „0“ und „9“ wird zwischen der „Schlagzeug“- und

der „Conga“-Visualierung umgeschaltet. Mit „s“ können die aufgenommen Sequenzen

abgespeichert werden.

Hauptschleifen Während der Programmausführung wird nun parallel die Hauptschlei-

fe und die Methode zur Verarbeitung der Positionsdaten „handleART()“ behandelt.

Die Hauptschleife wird mit jedem eintreffenden neuen Videobild durchlaufen. „dra-

wVideoFrame()“ zeichnet das von der Kamera aufgenommene Videobild. Danach wird

mit „changeTo3D()“ in den 3D-Modus umgeschaltet, damit die 3D-Grafiken gezeichnet

werden können. „drawDrums()“ oder „drawCongas()“ zeichnen nun je nach Benutzer-

auswahl die Schlagzeug- oder die Congagrafiken auf die Leinwand. Über das aktuell

ausgewählte Schlagzeugteil zeichnet diese Methode für den rechten Drumstick einen

grünen und für den linken einen blauen Rahmen. Wird ein Treffer ausgelöst, wechseln

diese Rahmen ihre Farbe zu rot und gelb und die Vrml-Grafiken werden ausgewech-

selt, um den Treffer zu visualisieren. „playDrumTrack()“ spielt gegebenenfalls einen

vom Benutzer ausgewählten Rhythmus ab. Mit „changeTo2D()“ wird wieder in den

2D-Zeichnen-Modus umgeschaltet und die Schleife beginnt von vorne.

Parallel wird nun die „handleART()“-Methode ausgeführt, die bei jeder Positions-

aktualisierung aufgerufen wird. Da die „Bodies“ (siehe6.1) in der Mitte der Drumsticks

montiert sind, aber die Position der Köpfe benötigt wird, werden die Positionsdaten


zuerst umgerechnet. Danach wird je nach Position der einzelnen Drumsticks der ent-

sprechende Schlagzeugteil in einer Variablen gespeichert, so dass die Grafikmethoden

den entsprechenden farbigen Rahmen setzten können. Ist die Position unter einer be-

stimmten Höhe und ein Treffer wird ausgelösst, werden Variablen gesetzt, so dass die

Vrml-Grafiken entsprechend ausgetauscht werden können. Hat der Drumstick die höch-

ste Position erreicht, wird die Position und die aktuelle Zeit gespeichert, damit später die

Beschleunigung und damit die Anschlagdynamik errechnet werden kann. Die Berech-

nung der Anschlagdynamik ist nötig, damit die Töne nicht immer gleich laut, sondern

abhängig vom Anschlag leise oder lauter abgespielt werden können.

Befindet sich ein Drumstick nun unter einer bestimmten Höhe wird ein Programm-

fragment (sieheA.1) durchlaufen, dass für alle Kombinationen von Drumstick und

Schlagzeugteilen implementiert ist. Zuerst wird die Anschlagstärke berechnet, je nach

Teil des Schlagzeugs, noch verschiedene Laustärken für gleichzeitg abzuspielende Klän-

ge. Abhängig von der x-Position wird die Panoramaeinstellung und die Tonhöhe ver-

ändert. Daraufhin werden ein oder mehrere MIDI-Events mit der entsprechenden An-

schlagsstärke an die Klangerzeuger geschickt.

Weitere Features

Aufnahme Der Benutzer kann seine Schlagzeug-Rhythmen aufnehmen. Zu Beginn

wird intern eine neue MIDIShare-Applikationen für die Aufnahme initialisiert und mit

der MIDIShare-Applikation zum Abspielen der vom Benuzter gespielten MIDI-Events

verbunden. Durch den Aufruf der „record()“-Methode werden Kopien der MIDI-Events

an die Record-Applikation geliefert, die sie mit einem Zeitstempel versehen speichert.

Bei Bedarf wird die Sequenz als MIDI-Datei im Programmverzeichnis gespeichert.

Abspielen von Rhythmen aus MIDI-Dateien und deren Visualisierung Die zu Be-

ginn initialisierte MIDIShare-Applikation zum Abspielen von MIDI-Dateien wird in-

tern mit sich selbst verbunden. Das heißt MIDI-Events, die diese MIDIShare-Applikation

ausgibt, bekommt sie auch wieder als Kopie geliefert. Mit der Funktion „MIDISetRcv-

Alarm()“ wird eine Funktion „checkForDrumEvents“ aufgerufen, wenn neue MIDI-


Events an die MIDIShare-Applikation geliefert werden. Diese Funktion überprüft die

MIDI-Daten auf „NoteOn“-Events von Hihat, Snare, Bassdrum und Beckensounds.

Findet die Methode einen solchen MIDI-Event, veranlasst sie die Visualisierung mit

den Methoden „showBassdrumHit()“, „showSnareHit()“, „showHihatHit()“ und „show-

CymbalHit()“ auf den entsprechenden 3D-Grafiken.

6.3.3 ARMusic

Abbildung 6.4: ARMusic

Programmstruktur im Überblick

Initialisierung Die „init()“-Methode dient zur Initialisierung. „initMIDI()“, „initMI-

DI2()“, „initPlayer()“ und „initRecordPlayer()“ initialisieren vier MIDIShare-Applika-

tionen. Die ersten beiden verwalten die zu erstellenden MIDI-Events für die imple-

mentierten Instrumente „Keyboard“ und „Hammondorgel“. Die dritte lädt vorgefertig-

te Rhythmen über MIDI-Dateien in die neu erstellte MIDIShare-Applikation, die sich

bei Bedarf abspielen lassen. Die vierte Applikation dient zur Aufnahme von MIDI-

Sequenzen. „initARToolkit()“ ruft nun elementare Methoden zum Laden der 3D-Grafiken,


der Kamera-Parameter und der Marker-Dateien auf (siehe6.2.1). „startVideoCapture()“

startet nun die das Einlesen der Bilder. „startMainLoop()“ ruft die Hauptschleife auf,

die nun für jedes Videobild einmal durchlaufen wird. Wird vom Benutzer die „Escape“-

Taste gedrückt, schließt eine „cleanup()“-Methode alle initialisierten Komponenten.

Hauptschleifen Die Hauptschleife wird auch hier wieder mit jedem eintreffenden

neuen Videobild durchlaufen. „drawVideoFrame()“ zeichnet das aktuelle Videobild.

„detectMarkers()“ sucht in diesem Bild nach den eingelesenen Markern. Mit „change-

To3D()“ wird in den 3D-Zeichnen-Modus umgeschaltet. „drawVrml()“ zeichnet auf den

gefundenen Markern die entsprechenden 3D-Grafiken. „chooseNextPattern()“ sucht den

nächsten Marker zum Zeigepattern und ruft die entsprechende Methode auf, falls dieser

Marker selektiert wurde. Falls der Marker für das Schlagzeug, die Instrumentenaus-

wahl, der Mixer oder das Arrangierboard sichtbar ist, wird die entsprechende Methode

aufgerufen. Die „drawGraphics()“-Methode zeichnet alle erforderlichen 3D-Grafiken

in das Bild. „planNextMethodCall()“ plant den nächsten zeitlichen Aufruf der Eingabe-

methoden. „showOnScreenMessages()“ gibt 2D-Informationen, wie der aktuelle Instru-

mentenname und die Kanalnummer auf dem Bildschirm aus. Mit „changeTo2D()“ wird

wieder in den 2D-Zeichnen-Modus umgeschaltet.

Visualisierungmethoden „drawGraphics()“ ruft alle Methoden zum Zeichnen der Gra-

fiken auf. „drawFrameOverChoosenPattern()“ zeichnet einen grünen Rahmen über dem

nächsten Marker relativ zum Zeigepattern. Wird ein Marker mit dem Zeigepattern aus-

gewählt, wird ein roter Rahmen gezeichnet. „showChordOnTheKeyboard()“ zeichnet

die entsprechenden Tasten auf dem Keyboard passend zum Akkord grün. „showSingle-

NotesOnTheHammond()“ zeichnet äquivalent die Tasten auf der Hammondorgel für die

aktuelle Note grün.

Das Schlagzeug

Ist der Schlagzeugmarker im Videobild sichtbar, wird die „DrumButton()“-Methode

aufgerufen. Die y-Koordinate wird auf einen Wert von null bis sechs umgewandelt und


damit wird der entsprechende Rhythmus ausgewählt. Die Rhythmen werden in eine

MIDIShare-Player-Applikation geladen. Abhängig von der x-Koordinate wird das Tem-

po des Players gesetzt. Der geladene Rhythmus bestimmt die Anzahl der Durchläufe des

Stepsequenzers der Hammondorgel. Je nach Rhythmus durchläuft der Stepsequenzer

16 oder 32 Schritte bis er wieder von vorne beginnt. Der Rhythmus bestimmt auch die

Länge der einzelnen Noten und ob sie gespielt oder nicht gespielt werden. Die Auswahl

dieser Parameter ergibt zusammen den Rhythmus für die Hammondorgel.

Abbildung 6.5: Das Schlagzeug

Auswahl des aktuellen Instruments

Mit der Methode „chooseNextPattern()“ wird das nächste Pattern relativ zum Marker

gesucht, bei Berühren ausgewählt und die entsprechende Eingabemethode aufgerufen.

Die Hammondorgel

Mit der Auswahl der Hammondorgel wird die Methode „InputStyleMatrix()“ aufgeru-

fen. Hier werden anhand der 3D-Position des Zeigepatterns MIDI-Events erzeugt und

ausgegeben.A.2 zeigt den Beispielcode. Die Methode inkrementiert, je nach Rhythmus


eine Variable. Die x-, y-, und die z-Position werden in Werte für Tonhöhe, Tonlaut-

stärke und Tondauer umgewandelt. Die Werte müssen zwischen 0 und 127 liegen und

werden in einem Array gespeichert. Je nach dem durch das Schlagzeug ausgewählten

Rhythmus, wird nun die Notenlänge und ob die Note gespielt wird aus dem entsprechen-

den Rhythmus-Array ausgelesen. Wird die Mischung aus zwei MIDI-Sounds gespielt,

wird die Lautstärke für den ersten und den zweiten Sound berechnet. Mit der Methode

„isInC“ wird berechnet, ob die Note in C-Dur ist. Die Methode benutzt den Umstand,

dass alle Noten von 0 bis 127 durchnummeriert sind. Zieht man von dem Notewert, so

oft 12 Halbtöne ab, solange der Notenwert über null liegt, kommt man in einen Bereich

der Notenwerte von null bis elf. Mit einer entsprechenden „switch-case“-Anweisung er-

hält man nun den Notennamen. Ist die Note in C-Dur wird sie abgespielt, wenn nicht,

wird der Notenwert einfach um eins erhöht. Die entsprechenden Notenwerte werden mit

ihrer Lautstärke auf dem passenden Kanal ausgegeben und auf dem Instrument visuali-

siert.

Abbildung 6.6: Die Hammondorgel


Das Keyboard

Die Methode „InputStyleMatrixChord()“ ist das Äuquivalent der Methode „InputStyle-

Matrix()“ für Akkorde und wird mit dem Selektieren des Keyboardmarkers aufgerufen.

Die x-, y-, und die z-Position werden wieder in Werte für die Akkordhöhe, die Ak-

kordlautstärke und die Akkorddauer umgewandelt und in einem Array gespeichert. Die

Werte für die Akkordhöhe werden auf den Wertebereich von eins bis acht umgewan-

delt. Dieser Wert wird an die „sendChordOn“-Methode übergeben, die diesen in den

entsprechenden diatonischen Stufenakkord (siehe3.2.2) umwandelt. Diese Methode er-

stellt den Akkord und spielt ihn ab. Der Akkordname wird auf dem Bildschirm angezeigt

und auf dem Instrument animiert.

Abbildung 6.7: Das Keyboard

Die Instrumentenauswahl

Die Methode „InstrumentChooser()“ wird aufgerufen, sobald der entsprechende Marker

im Videobild sichtbar ist. Befindet sich das Zeigepattern im rechten Teil des Videobildes

wird das aktuelle Instrument um eins erhöht, im linken Teil um eins erniedrigt. Der mitt-

lere Teil des Videobilds ist neutral. Visualisiert wird die Auswahl der Instrumente mit


einem dreidimensionalem Fließband. Die Instrumente rotieren dabei im Uhrzeigersinn

auf insgesamt neun Positionen. Wird das aktuelle Instrument mit dem Zeigepattern um

eins erhöht, werden die Instrumente um eine Position nach rechts verschoben. Das ent-

sprechende MIDI-Event zum Instrumentwechsel wird gesendet. Umgekehrt werden die

Instrumente um eins nacht links verschoben, wenn das Zeigepattern im linken Teil des

Videobilds ist. Die Frequenz der Erhöhung oder Erniedrigung des aktuellen Instruments

wird erhöht je länger sich das Zeigepattern in einem Teil des Videobildes befindet. So

soll eine schnelle Navigation durch die 128 Instrumente gewährleistet werden. Idealer-

weise sollten die 3D-Grafiken die 128 verschiedenen Instrumente abbilden, es konnten

aus Zeitgründen aber nur sieben verschiedene Instrumente modelliert werden, die sich

im Kreis drehen.

Es wurde auch eine frühe Version der Instrumentenauswahl implementiert. Bei die-

ser Version wird das Instrument zweistufig ausgewählt. Im ersten Selektionsschritt wählt

man eine der 16 Kategorien, wie Tasten-, Streich- oder Blasinstrumente. In einem zwei-

ten Schritt wählt man explizit eines der 8 Instrumente aus. Diese Konzept sollte den Vor-

teil einer übersichtlichen und schnellen Auswahl der Instrumente realisieren. Abbildung

6.9zeigt die implementierte Instrumentenauswahl. Navigiert wurde über das Verschie-

ben des Markers in x- und y-Richtung. Die aktuelle Auswahl wurde durch einen weißen

Rahmen visualisiert. Durch Bewegen des Markers in z-Richtung über eine festgelegte

Distanz wurde die Auswahl selektiert und die Rahmenfarbe geändert. Durch Bewegen

gegen die z-Richtung wurde wieder deselektiert.

Der Mixer

Die Methode „MixerNavigation()“ wird durch die Sichtbarkeit des entsprechenden Mar-

kers im Videobild aufgerufen. Vertikal sind die 16 MIDI-Kanäle und ein Master-Kanal

angeordnet. Horizontal stehen für jeden Kanal die drei Drehregler Hall-, Choruseffekt

und Panorama, ein Muteschalter und die Lautstärke zur Verfügung. Mit dem Masterka-

nal kann die Gesamtlautstärke eingestellt werden. Die aktuellen Koordinaten des Zei-

gepatterns werden auf die einzelnen Drehregler und Lautstärkefader gemapped und ein

grüner Rahmen darüber gezeichnet. Wird mit dem zweiten Zeigepattern die Selektions-


Abbildung 6.8: Die Instrumentenauswahl

geste durch den Benutzer ausgeführt, ist das aktuelle Item selektiert, ein roter Rahmen

wird gezeichnet. Durch Bewegen des Zeigepatterns nach oben oder unten kann man

nun den jeweiligen Wert ändern. Der entsprechende MIDI-Befehl wird erzeugt und auf

dem entsprechenden Kanal gesendet. Die Grafik wird aktualisiert. Bei den Drehreglern

wird die weiße Markierung neu gesetzt, bei den Mute-Schalten wird ein rotes Quadrat

gezeichnet. Die Lautstärkefader werden in der Position verschoben.

Das Arrangierboard

Auch hier wird mit der Sichtbarkeit des Markers die entsprechende Methode „VirtualAr-

ranger()“ aufgerufen. Die 16 MIDI-Kanäle werden als einzelne Spuren auf einem Board

visualisiert. Die einzelnen Spuren haben zur Unterscheidung verschiedene Farben. Neue

Segmente auf der gleichen Spur werden als abgetrennte Balken gezeichnet. Intern wer-

den die Spuren als verschiedene Spuren der MIDIShare-Record-Applikation behandelt.

Für die Visualisierung werden die Start- und Stoppzeiten der einzelnen Segmente ge-

speichert. Die Länge der einzelnen Segmente ergibt sich damit aus der Differenz dieser

beiden. Die Navigation wird durch die Position des Zeigepatterns bestimmt. Die aktu-

elle Position wird auf das entsprechende Segment gemapped. Mit dem zweiten Zeige-


Abbildung 6.9: Erstes Konzept einer Instrumentenauswahl

pattern kann das aktuelle Segment selektiert und deselektiert werden. Damit kann man

das Segment auf eine andere Position oder auf eine andere Spur verschieben und damit

auch ein neues Instrument zuweisen. Wird ein Segment verschoben, muss die entspre-

chende Spur aus der MIDIShare-Applikation extrahiert und die MIDI-Daten mit dem

entsprechenden Zeiten herausgefiltert werden. Diese werden in einer Hilfssequenz zwi-

schengespeichert und an der richtigen Stelle der neuen Spur eingefügt.


Abbildung 6.10: Der Mixer

Abbildung 6.11: Der Arranger

Kapitel 7

Ausblick/Schlussfolgerungen

7.1 Kurze Zusammenfassung der erzielten Ergebnisse

Das Produzieren von Musik, auch ohne Instrumentenkenntnisse zu ermöglichen, war

eines der Ziele dieser Arbeit. Nun kann man mit derARMusic-Applikation nur mit den

Händen elementare Musikparameter beeinflussen und durch den Zusammenhang von

Ton, Akkord, Rhythmus und Melodie komplexe Arrangements produzieren. Mithilfe

der Instrumentenauswahl steht ein einfaches Hilfsmittel für die Auswahl der vielen ver-

schiedenen Instrumente zur Verfügung. Das Menü zeigt, dass mit Visualisierungen auch

eine große Anzahl von Menüpunkten sehr übersichtlich und intuitiv präsentiert wer-

den kann. Augmented Reality bietet die Möglichkeit ein einfaches „User-Interface“ zu

entwickeln, in dem der Benutzer nicht indirekt mit der Maus, sondern direkt die Ob-

jekte mit seinen Händen beeinflussen kann. Mit der Realisierung des Mixers und dem

Arrangierboard wurde gezeigt, dass auch eine komplexe Funktionssteuerung in einer

AR-Umgebung realisiert werden kann. Die Gestenerkennung für das Selektieren ein-

zelner Parameter wurde erstaunlich schnell angenommen und umgesetzt. Hier scheint

ein hohes Potential für die Interaktion in drei Dimensionen zu liegen.

DieARTDrums-Anwendung eröffnet dem Anwender die Möglichkeit alle GENERAL-

MIDI Schlagzeug- und Percussioninstrumente in natürlicher Weise zu spielen. Mit der

dynamischen Belegung der verschiedenen Sounds im Raum kann der Benutzer die

Klänge an die Spielsituation anpassen und damit auch neue Spieltechniken erfinden.

81

82 KAPITEL 7. AUSBLICK/SCHLUSSFOLGERUNGEN

Der gleitende Übergang von einem Klang zum nächsten bietet die Möglichkeit feinste

Klangnuancen und und Mischungen von mehreren verschiedenen Sounds zu spielen.

Die Visualisierung der Instrumente auf der Leinwand und deren Animation gibt dem

Benutzer ein Feedback und ermöglicht das Erlernen von neuen Rhythmen.

7.2 Offene Probleme

Natürlich treten durch technische Limitierungen, wie Veränderung der Lichtverhältnisse

und Verdeckung der Marker durch Hände oder andere Marker, immer wieder Probleme

bei der Nutzung von Augmented Reality auf. Diese könnten durch geeignete Algorith-

men verbessert, aber leider nie ganz gelöst werden.

Bei der Kombination von verschiedenen Trackingmethoden und dem Erzeugen von

Musik ist die Latenz immer das größte Problem. Die Latenz bezeichnet die Zeitspan-

ne vom Auslösen bis zum Hören des jeweiligen Musik-Events. Latenz ist damit die

Summe aus den Zeitdauern von der Bestimmung der Position durch den Tracker, Wei-

terleitung des Signals über das Netzwerk und den Computer, der Verarbeitung und dem

Abspielen des Klangs. Dabei stellt die Bestimmung der Position durch den Tracker den

größten Beitrag zur Latenz. Beim ARToolKit werden im Idealfall bis zu 30 Bilder pro

Sekunde geliefert. Damit ist zwischen zwei Bildern eine rechnerische Lücke von 33,3

Millisekunden, in der keine Bewegungen erfasst werden. Findet in dieser Zeitspanne

ein Auslösen eines Musik-Events statt, wird dies im schlechtesten Fall erst 33,3 Mil-

lisekunden zu spät erfasst und verarbeitet. Latenzen unter zehn Millisekunden sind für

die meisten Menschen nicht mehr wahrnehmbar, alle Zeitspannen darüber werden als

Verzögerung empfunden. Der ARTTracker bietet eine Updaterate von bis zu 60 Hertz.

Rein rechnerisch ergibt sich damit ein Latenz von 16,6 Millisekunden, was sich in der

Praxis als gut spielbar herausgestellt hat. Jedes System bietet seine eigenen Vor- und

Nachteile. Das Tracking mit dem ARToolKit ist kostengünstig , kabellos, aber leider

auf 30 Bilder pro Sekunde beschränkt, so dass eine schnelle Bewegung nie genau genug

erfasst werden kann. Der ARTTracker bietet eine geringe Latenz, ist aber sehr teuer in

der Anschaffung.

7.3. ANREGUNGEN FÜR WEITERFÜHRENDE ARBEITEN 83

7.3 Anregungen für weiterführende Arbeiten

Die Eingabe von Musik im Raum bietet ein hohes Potential für Innovationen. Hier konn-

ten nur einige von vielen Eingabestilen implementiert werden. Neben der Realisierung

von klassischen Anschlagsformen können neue entwickelt oder mit alten kombiniert

werden. Die dynamische Visualisierung bietet noch viel Raum für bessere Entwicklun-

gen. Musik kann dem Benutzer noch einfacher präsentiert werden. Zum Beispiel könnte

man sich eine Visualisierung mit Farben vorstellen.

Die AnwendungARTDrumsbietet dem Anwender eine neue Art Schlagzeug und

Percussioninstrumente zu spielen. Neben dem klassischen Spiel auf den Drumpads kön-

nen die Klänge aber auch auf Klangflächen verteilt werden. Sind die Klänge bei klassi-

schen oder elektronischen Schlagzeugen auf die Drumpads beschränkt, können sie bei

der Eingabe im Raum auf Flächen im Raum verteilt werden. Damit enden die Klänge

nicht an einer bestimmten Grenze, sondern gehen in den nächsten Klang über. Dadurch

befinden sich im Raum Klangflächen, die durch feine Nuancen im Klang und durch

den gleitenden Übergang zum nächsten Klang bestimmt sind. Diese Klangflächen kön-

nen nun funktional nicht nur durch eine bestimmte Höhe, sondern auch durch beliebi-

ge Funktionen definiert werden. Somit können schräge Ebenen oder auch wellenartige

Flächen realisiert werden. Solche Klangflächen können nun auch übereinander gesta-

pelt oder um geometrische Objekte arrangiert werden. Der Vorteil dieser Arrangements

von Klangflächen liegt in der Vielzahl ihrer Klänge und der Kontrolle feinster Klangnu-

ancen, da der komplette Raum zur Verfügung steht. Die Positionierung von einzelnen

Klängen im Raum oder innerhalb von Klangflächen kann damit sehr dynamisch ange-

passt werden, um eine bessere Spielbarkeit zu gewährleisten.

84 KAPITEL 7. AUSBLICK/SCHLUSSFOLGERUNGEN

Anhang A

Programmdokumentation

Beispiel für das Auslösen eines Treffers, der Berechnung der Anschlagdynamik und des

Senden der MIDI-Events in derARTDrums-Applikation:

/ / s t i c k one p l a y i n g l e f t conga ,

/ / i f y−p o s i t i o n under 270 mm and

/ / x−p o s i t i o n on t h e l e f t o f t h e midd le

/ / and t h e sound i s no t a l l r e a d y p l a y i n g

i f ( t . sensor ==0 && Position [2 ] <270 && Position [0 ] >20 &&

StickOneConga2Playing == f a l s e )

{

/ / c a l c u l a t e v e l o c i t y

way=MaxYMarkerOne −270;

time =MIDIGetTime ( )−VelocityTimer1 ;

VelocityOne =(way / time ) ∗100;

/ / c a l c u l a t e t h e vo lumes f o r bo th sounds

VolumeForSoundOne =VelocityOne ∗ ( ( ( ( t . pos [0] −20)∗(−1) +480) )

/ 4 8 0 ) ;

VolumeForSoundTwo =127−VelocityOne ;

/ / send panorama

I

II ANHANG A. PROGRAMMDOKUMENTATION

sendControlChange ( 10 ,t . pos [ 0 ] , 1 0 ) ;

/ / send t h e MIDI−Even ts

playNote ( 63 ,VolumeForSoundOne , 2 0 0 , 1 0 ) ;

playNote ( 62 ,VolumeForSoundTwo , 2 0 0 , 1 0 ) ;

/ / and some p i t c h

sendPitchWheel ( t . pos [ 0 ] , 1 0 ) ;

/ / r e s e t v a r i a b l e s f o r v e l o c i t y and g r a p h i c s

MaxYMarkerOne =0;

StickOneConga2Playing = t rue ;

}

Listing A.1: Beispielcode aus der ARTDrums-Applikation

Die Eingabemethode InputStyleMatrix() aus der AnwendungARMusic:

vo id MSALARMAPI InputStyleMatrix ( long dt , shor t ref , long a1 ,

long a2 , long a3 )

{

/ / i f t h e end o f t h e rhythm−t i meb ase i s reached , s e t i t o

ze ro

i f ( i >=timebase ∗2)i =0;

/ / i f t h e markers are v i s i b l e

i f (switchKeyInput ==4 && object [ 1 ] . visible && object [ 6 ] .

visible

&& ! object [ 7 ] . visible ) {

/ / t a k e t h e y−c o o r d i n a t e f o r p i t c h

Matrix [ i ] = ( object [ 1 ] . trans [ 1 ] [ 3 ] ∗ ( −1 ) +50) / 3 + 3 0 ;

/ / and t h e z−c o o r d i n a t e f o r volume

Volume [ i ] = ( object [ 1 ] . trans [ 2 ] [3 ] −50) ∗0 . 5 3 ;

i f (Volume [ i ] >=127) Volume [ i ] =127 ;

/ / x−c o o r d i n a t e f o r t h e d u r a t i o n

Duration [ i ]=object [ 1 ] . trans [ 0 ] [ 3 ] + 1 8 0 ;

i f (Duration [ i ] >=250) Duration [ i ] =250 ;

III

/ / t a k e t h e c o r r e c t n o t e l e n g t h and check i f t h e no te w i l l be

p layed

sw i tch (switchDrum ) {

case 0 :playnote =RhythmFunk [ i ] ;

notelength =NormalBeetweenStep ∗RhythmFunkNote [ i ] ;

break ;

case 1 :playnote =RhythmJazz [ i ] ;

notelength =NormalBeetweenStep ∗RhythmJazzNote [ i ] ;

break ;

case 2 :playnote =RhythmBossa [ i ] ;

notelength =NormalBeetweenStep ∗RhythmBossaNote [ i ] ;

break ;

case 3 :playnote =RhythmChachacha [ i ] ;

notelength =NormalBeetweenStep ∗RhythmChachachaNote [ i ] ;

break ;

case 4 :playnote =RhythmHeavy [ i ] ;

notelength =NormalBeetweenStep ∗RhythmHeavyNote [ i ] ;

break ;

}

/ / p l a y i n g t h e mix o f two sounds

/ / c a c u l a t e t h e vo lumes f o r bo th sounds

VolumeForSoundOne =Volume [ i ] ∗ ( ( Duration [ i ]−100) / 1 6 0 ) ;

VolumeForSoundTwo =Volume [ i ]−VolumeForSoundOne ;

/ / check i f t h e no te i s i n C

check =isInC (Matrix [ i ] ) ;

/ / i f yes , p lay bo th sounds

i f (check == t rue ) {

i f (Matrix [ i ] ! = 0 )

i f (object [ 6 ] . visible && playnote ==1)

IV ANHANG A. PROGRAMMDOKUMENTATION

playNote2 (Matrix [ i ] , VolumeForSoundOne ,

notelength , 4 ) ;


playNote2 (Matrix [ i ] , VolumeForSoundTwo ,

notelength , 7 ) ;

savePitchMatrix =Matrix [ i ] ;

}

e l s e {

/ / i f no , p lay h a l f a tone h i g h e r

i f (Matrix [ i ] ! = 0 )


playNote2 (Matrix [ i ]+1 ,VolumeForSoundOne ,

notelength , 4 ) ;


playNote2 (Matrix [ i ]+1 ,VolumeForSoundTwo ,

notelength , 7 ) ;

savePitchMatrix =Matrix [ i ] + 1 ;

}

i ++;

}

Listing A.2: Die Eingabemethode InputStyleMatrix() aus ARMusic

Literaturverzeichnis

[1] ARToolKit Dokumentation Version 2.33, Human Interface Technology Laboratory

University of Washington

http://www.hitl.washington.edu/people/grof/SharedSpace/Download/ARToolKit2.33doc.pdf,

Zugriff am 25.07.2005

[2] DeFuria, Steve (1990).Das MIDI-Buch: die Nutzung von MIDI und den zugehöri-

gen Interfaces.Schott, Mainz

[3] MidiShare Player-Bibliothek Downloadseite

http://cvs.sourceforge.net/viewcvs.py/midishare/midishare/libraries/player/, Zu-

griff am 25.07.2005

[4] MidiShare Downloadseite

http://sourceforge.net/projects/midishare/, Zugriff am 25.07.2005

[5] ARToolKit Homepage

http://www.hitl.washington.edu, Zugriff am 25.07.2005

[6] ARToolKit Downloadseite

http://www.hitl.washington.edu/research/shared_space/download/, Zugriff am

25.07.2005

[7] Überblick über alternative MIDI-Controller

http://www.stoffelshome.de/alt_controller/alt_midi_controller.html, Zugriff am

25.07.2005

V

VI LITERATURVERZEICHNIS

[8] MidiShare Developer Dokumentation Version 1.68

ftp://ftp.grame.fr/pub/Documents/MidiShare.pdf, Zugriff am 25.07.2005

[9] MidiShare Player Library Version 2.0

http://cvs.sourceforge.net/viewcvs.py/midishare/midishare/libraries/player/doc/Player2.0.pdf,

Zugriff am 25.07.2005

[10] Milgram, P., Takemura, H.,Utsumi, A., Kishino, F.;Augmented Reality: A Class of

Displays on the Reality-Virtuality Continuum; SPIE Vol. 2351 Telemanipulator and

Telepresence Technologies, pp. 282-292, 1994

[11] Müller, S.;Computergraphik 2; Universität Koblenz, 2002-2003

http://www.uni-koblenz.de/∼cg/veranst/ws0203/cg2.html, Zugriff am 25.07.2005

[12] Müller, S.;Virtuelle Realität und Augmented Reality; Universität Koblenz, 2003

http://www.uni-koblenz.de/∼cg/veranst/ss03/vrar.html, Zugriff am 25.07.2005

[13] Sikora, Frank (2003).Neue Jazz-HarmonielehreSchott, Mainz

[14] Schwall, Johannes (2004).3D-Interaktion www.schwall.de/dl/20041004_3d-

interaktion.pdf, Zugriff am 25.07.2005

[15] Woo, M.; Neider, J.; Davis, T.OpenGL Programming GuideThird Edition,

OpenGL Architecture Review Board