vj - towards an electronic art

inhalt „vj - towards an electronic art“ Projekt an der Fakultät Medien Bauhaus Universität Weimar Sommersemester 2003 Betreuer Prof. Sattler (PD) Prof. Fröhlich (MS) Dipl.-Ing. Hendrik Wendler Dipl.-Ing. Stefan Krause Dokumentation Christian Lessig Bahnhofstraße 29a 99843 Kittelsthal Matrikel-Nummer: 10029 [email protected]

inhalt intro Performance „Skulptur instant“ workshop „Kabelsalat“ „Froschtrampolin“ programmierung - einleitung einarbeitung / VI DVV - konzept VI - anpassung funktionsweise: VI /DVV programme - diverses zusammenfassung

03 04 04 05 06 08 10 12 13 14 16 17 18 20 22 23 24 26 27 29 30 32

pflichtaufgaben - einleitung videoloops konzept referat visualisierungstechniken motivation notwendigkeit middleware DVV - umsetzung konfiguration VI / DVV mögliche erweiterungen allgemeine projektarbeit anhang

Bild: Verpackung von „Skulptur Instant“

2

vj - towards an electronic art

intro

vj - towards an electronic art

Das Ziel des Projektes lag für mich in der Schaffung eines Software-Systems mit dem man ein beliebiges VJSetup umsetzen kann. Die Aufgabe der Studierenden der künstlerischen Studiengänge sollte dabei die Vorgabe der Funktionalitäten des Systems und die Entwikklung einiger exemplarischer Setups sein. Die Studierenden der Mediensysteme hatten die Aufgabe diese Funktionalitäten zu implementieren und damit die Realisierung der Setups zu ermöglichen.

vj - towards an electronic art

3

aufgaben

der anfang - die pflichtaufgaben Aufgabe I

Bereiten Sie eine ca. 5 minütige Präsentation vor. Die 5 Minuten Skulptur Die 5 Minuten Terrine - einfach mit kochendem Wasser aufgießen und genießen. Natriumglutamat als Katalysator des schnellen Genußes. Die Skulptur - gemeißelt aus Granit, Marmor oder Travertin. Ein Werk für die Ewigkeit, ein Anker im Strom der Geschichte. Verbinden Sie diese beiden Konzepte zu einer schlüßigen Inszenierung, zu einem schnellen Kick, zu einem kurzlebigen Monument der Vergänglichkeit.

4

Zu Beginn des Projektes musste ich mich zunächst in das Thema VJ’ing einarbeiten. Neben der hier gefragten Eigeninitiative konnte ich dazu die Aufgaben und Workshops nutzen, bei welchen jeweils ein präsentierbares Ergebnis erstellt und dieses den Kommilitonen im Projektplenum vorgestellt werden sollte.

Neben dem Einstieg in das Thema gab es dabei für den Einzelnen zwei weitere Ziele: Es sollten eigene Vorstellungen über die Eigenschaften des Systems entwickelt werden und sich jeder den Bereich suchen, auf welchen er seine Arbeit in der Realisierungsphase des Projektes konzentrieren möchte.

„Skulptur Instant“ Die erste Aufgabe war eine kurze Performance, zu einem von drei vorgegebenen Themen, wobei ich Die 5 Minuten Skulptur gewählt habe. Reizvoll fand ich an dieser Aufgabe besonders die Gegensätze zu einem homogenen Gesamten zu vereinen. Im Gegensatz zu den meisten anderen Projektteilnehmern, empfand ich bei der Umsetzung der Aufgabe weniger den Auftritt und das Reden vor einer Gruppe als schwierig; mir bereitete es vielmehr Probleme meinen Auftritt einen unterhaltsamen Cha-

rakter zu geben. Deshalb habe ich mich für einen humoristischen Vortrag1 entschieden und mit „Skulptur instant“ dieses Ziel hoffentlich auch erreicht. Angeboten hat sich diese Art der Präsentation für mich deshalb, da ich zur Umsetzung keine Technik benötigt habe, was aus Erfahrung immer ein Fehlerquelle ist und deshalb nur dann eingesetzt werden sollte, wenn dies tatsächlich notwendig ist. 1

CD: .../SkulpturInstant/Verkäuferschulung.pdf

aufgaben

Aufgabe II

Erarbeiten sie einen VideoLoop ( max. 30 sec ) zu einem der folgenden Themen:

VideoLoops Die nächste Aufgabe, die Produktion eines Video-Loops, orientierte sich bereits stärker am Bereich des VJ’ing. Dabei sollten die Filme mit Standard-Videobearbeitungssoftware geschnitten werden, um so die Vor- und Nachteile der vorhandenen digitalen Videobearbeitungssysteme kennen zu lernen. Da ich mich in den vorherigen Semestern bereits mit solchen Systemen beschäftigt hatte, war für mich ein zweiter Aspekt wesentlich interessanter: die

Suche nach geeignetem Material für den Loop. Hierbei waren vor allem ein „wacher Geist“ und ein „offenes Auge“ gefragt um sich wiederholende Szene - und damit Loops - zu finden. Exemplarisch kann hier der Film „Schreibmaschine - vor und zurück“1 angeführt werden, der nur als Nebenprodukt der eigentlichen Dreharbeiten zum Film „Das Schaf“1 entstand. 1 CD: .../VideoLoop/

Kindergarten Autobahn Supermarkt oder unterstreichen Sie mit dem Loop Ihre Vision vom VJ Tool !

-

Bereiten Sie den Loop so auf, daß Sie ihn im Plenum am 29.04 vorführen können. Machen Sie den Loop auf Ihrer persönlichen Uni Homepage verfügbar. Posten Sie einen Link zum Loop auf das Weblog.

Sequenz: Szene aus dem Film „Das Schaf“ zur Aufgabe VideoLoop Seite 6 und 7: Plakate zum Workshop „Kabelsalat“ CD: .../Kabelsalat.pdf

5

aufgaben

Sequenz: mögliche Folge von Gesten zur Interaktion in der augmented reality - Bild 2.1 bis 2.6: mit der linken Hand wird ein Element eines Interface, wie zum Beispiel in Bild 4 modelliert, aktiviert - Bild 2.7 und 2.8: mit der rechten Hand wird eine Bewegung im Raum gesteuert

Konzept Die Formulierung eines Konzeptes für unser System war die nächste Aufgabe. Ich konzentrierte mich dabei auf den Bereich des Gesamtsystems, welcher zu diesem Zeitpunkt in meinen Augen das größte Problem darstellte: Die Frage war, wie sich ein komplexes, virtuelles Setup visualisieren und intuitiv Bild: Vision für das Flugzeug-Cockpit der Zukunft: Der Pilot wird durch eine augmented reality Umgebung bei der Navigation unterstützt

bedienen läßt; und dies so, dass der VJ nicht an Schieberegler oder ein Laptop-Display gebunden ist, sondern auch eine Performance gestalten kann? Damit dies gelingt müssen zwei konträre Dinge, Performance und Systemkontrolle, zu einer Einheit verbunden werden. Im Idealfall sollte also die beste Performance mit dem Interface des komplexesten Systems, welches wir noch kontrollieren können, zu einer Einheit verschmolzen werden. Damit ergeben sich zwei Fragen: Wies sieht die ideale Bühnenperformance aus? Was ist das komplexeste System, mit welchen wir umgehen können? Meine Antworten: Die ideale Performance? Die Show eines Rockstars. Das komplexeste System? Unser alltägliches Leben.

8

vj - towards an electronic art

aufgaben

Für mich folgte daraus sehr schnell die weitere Richtung meiner Überlegungen: augmented reality - die Überlagerung einer künstlichen dreidimensionalen Welt mit der Wirklichkeit. Orientiert habe ich mich dabei an Systemen, wie sie zum Beispiel für Jet-Piloten existieren (Bild 2). Dort wird die Orientierung der Piloten durch eine vereinfachte, virtuelle Abbilldung der Realität unterstüzt. Übertragen auf unser System bedeutete dies die Darstellung der Video-Pipeline als eine Menge dreidimensionaler, virtueller Körper für mich logisch. Jeder Körper stellt ein Element der Grafikpipeline dar und jeder Parameter des Elementes wird durch eine Seite des Körpers repräsentiert. Zwei Vorteil eines solchen Interface gegenüber klassischen zweidimensionalen waren für mich dabei entscheidend. Zum einen die einfachere Orientierung im aus dem Alltag gewohnten dreidimensioalen Raum, insbesondere bei einer großen Anzahl von Elementen. Zum anderen

vj - towards an electronic art

stehen zur Manipulation wesentlich mehr intui- Metaphern und Interaktionstechniken zu evalutiv erfassbare Möglichkeiten offen. So ieren. weiß man sofort, dass man einen KörIm weiteren Verlauf dieses Projektes per mit seinen Händen drehen und wurde die Idee auf Grund der techschieben kann, dass man mehrere Obnischen Probleme bei der Umsetjekte zu einem Turm aufstapeln kann, … zung nicht weiterverfolgt, obwohl Die Performance sollte dabei durch die ähnliche Fragestellungen, wie die BeManipulationen und die Gesten geschedienbarkeit äußerst komplexer techhen - denn schließlich ist auch Tanz nischer Systeme, in Zukunft auch in nichts anderes als eine Aneinanderzahlreichen anderen Bereichen aufreihung von Gesten und Bewegungen. treten werden. Die fortschreitende Ich denke, bei einer entsprechenden Entwicklung in den InformationsGestaltung des dreidimensionalen Rautechnologien wird jedoch wahrmes, wäre mit einem solchen Interface scheinlich in einigen Jahren die Vordie Verbindung von Performance und raussetzungen schaffen um die Idee Steuerung des Systems zu einer Einheit noch einmal aufgreifen und weitermöglich. Zur Veranschaulichung meiner verfolgen zu können. Ideen und habe ich einen Film sowie ein interaktives Demo erstellt. Konzentriert Bild : Entwurf eines Menübalkens für den 3D Raum mit dem bestimmte Funktionen aktiviert werden können habe ich mich dabei zunächst auf die Gezum Beispiel könnte das Aktivieren eines Elementes staltung der künstlichen Welt, um mögliche einen Filter zur Grafik-Pipeline hinzufügen

9

aufgaben

Aufgabe IV

Die CAD Zahnbürste: „Das Froschtrampolin“

“Die CAD Zahnbürste“ Es stehen 5 Objekte des täglichen Gebrauchs zur Auswahl. Finden Sie sich in überdisziplinären Gruppen zu ca. 3 Personen zusammen und entwickeln Sie aus dem Gebrauchsgegenstand Ihrer Wahl ein Performance-Eingabegerät : -Eine beliebige Computerapplikation (Flash, Website, Sound, etc ... ) wird qualitativ gesteuert. Das Eingabegerät soll eine Vorstufe unserer Performance Interfaces sein. Denken Sie an Bedienbarkeit, notwendige Präzision und Robustheit. -Denken Sie an den Conrad Katalog, Denken Sie an optische und mechanische Mäuse, Denken Sie an Touchpads, Potentiometer, Lichtschranken, Feldeffekte und Trackingsysteme (auch optische). Löten Sie!

10

Die letzte Aufgabe beschäftigte sich mit dem Entwurf eines Eingabegerätes auf Grundlage eines vorgegebenen „Dings“; eines Gegenstandes, der normalerweise nicht dazu geeignet ist, einen Computer zu steuern. Schnell konnte wir uns innerhalb der interdisziplinären Arbeitsgruppe „Gummiband“ darauf einigen, dass nicht nur eine qualitative Steue-

rung Ziel sein sollte. Es bestand Konsens darüber, dass ein Eingabegerät erst dann Sinn macht, wenn Applikation und Gerät aufeinander abgestimmt sind. Damit musste auch die Hard- und die Softwareentwicklung parallel geschehen. So konnten Probleme, welche auf einer Ebene nur schwer zu lösen waren, auf die andere Ebene ausgelagert werden. Einige Pro-

vj - towards an electronic art

aufgaben

Screenshot (links): Programm zur Darstellung der Eingaben auf dem Bildschirm

bleme in der Hardware, deren Korrektur eigentlich Stunden in Anspruch genommen hätte, konnten so zum Beispiel in wenigen Minuten mit Hilfe der Software gelöst werden. Als Resultat1 konnten wir eine virtuelle Ebene im Computer präsentieren, auf der man über eine Matrix von Tastern - von uns als „Froschtramplin“ bezeichnet - Erhebungen erzeugen konnte. Ein Problem konnten wir bei der Bearbeitung der Aufgabe jedoch nicht zu meiner Zufriedenheit lösen: Wie gelingt es die mechanischen Signale in den Computer einzulesen? Wir nutzten eine alte Computertastatur die so weit zerlegt wurde, dass die Kontakte der Tasten mit den Tastern des „Froschtrampolins“ verbunden werden konnten. Es zeigte sich jedoch, dass dies keine Lösung für andere Eingabegeräte sein konnte: Der Arbeitsaufwand für den Umbau der Tastatur war enorm und die Größe ließ sich kaum reduzieren. Gravierender

vj - towards an electronic art

war jedoch, dass wir keine quantitativen Aussagen über die eingelesenen Werte machen konnten. Das heißt, wir konnten zwar bestimmen, ob eine bestimmte Stelle am Trampolin gedrückt wurde oder nicht, wir konnten jedoch nicht messen wie stark der Druck war. Dieses Problem stellte für mich eine wesentliche Motivation dar, mich im weiteren Projektverlauf näher mit der Einbindung der Eingabegeräte in unser Framework zu beschäftigen. Trotz der Probleme hat die Idee einer Eingabematrix einige sehr gute Eigenschaften gezeigt. Insbesondere auf Grund der intuitiven Bedienbarkeit, der leichten Handhabung sowie der Eignung zur Eingabe und Steuerung praktisch jeder Art von Daten sollte die Idee zukünftig weiterverfolgt werden1.

Bild: Aufbau für die Präsentation, links die Eingabematrix

1 Froschtrampolin.exe 2 Hierzu wurde bereits ein Schaltplan entwickelt mit dem sich auch die Intensität des Drucks mit Hilfe einer VribIn Box einlesen läßt

11

aufgaben

kommentar Trotz der zahlreichen Erfahrungen, welche ich bei der Bearbeitung der Aufgaben und den Workshops sammeln konnte, und der Freude, die ich daran hatte, denke ich, dass der Verlauf des Projektes dadurch nicht nur positiv beeinflusst wurde: Mir - und ich denke den anderen Medien-system-Studierenden im Projekt ebenso - ist es kaum gelungen, die Erfahrungen aus den Workshops und Aufgaben tatsächlich in den Entwurf des Frameworks zu integrieren. Zwar fand jeweils eine gemeinsame Auswertung statt, jedoch blieb diese meist so allgemein, dass kaum konkrete Schlüsse gezogen werden konnten. Hilfreich wäre hier die klare Zielstellung gewesen, die Erfahrungen festzuhalten, welche unbedingt in unser System einfließen sollten Ebenfalls problematisch für den Verlauf des Projektes war der hohe Zeitaufwand, welche die Bearbeitung der Aufgaben mit sich brachte. Insbesondere bei den Mediensystem-Studierenden sind dadurch Defizite bei ihrer eigentlichen Aufgabe, dem Entwurf und der Realisierung des Frameworks, entstanden.

12

Referat1 Neben diesen, für alle identischen Aufgaben, musste jeder Projektteilnehmer ein Referat erarbeiten, welches uns zusätzliches Hintergrundwissen zu einem bestimmten Thema vermitteln sollte. Bei meinem Vortrag zum Thema Visualisierungstechnik1 habe ich meinen Schwerpunkt auf diejenigen Geräte gelegt, welche für eine VJ-Performance in Frage kommen. Der erste Teil des Referates beschäftigte sich exemplarisch mit einige klassischen Einsatzfeldern, wie etwa Eventgestaltung oder Innenarchitektur, und im zweiten Teil wurden dann die verschiedenen Gerätetypen vorgestellt wurden. Dabei war es mir wichtig, auf einige grundsätzliche

technische Aspekte einzugehen. Erst dieses Wissen ermöglicht es, sich für die richtige Projektions- und Bildschirmtechnik für einen bestimmten Zweck entscheiden zu können, da erst dadurch die Vor- und Nachteile der einzelnen Systeme klar werden. Bedauerlich ist, dass die Inhalte des Vortrages im weiteren Projektverlauf weitgehend unbeachtet blieben. In meinen Augen liegt dadurch gerade bei der Ausgabe noch ein großes Potential für die Zukunft.

Bild: Projektion eines Amphietheaters in einer Aufführung von Marc Aurel

Bild: Projektion auf Schnee in Österreich

1 Folien: Darstellungstechniken.pdf 2 am 6. Mai im Projektplenum 3 offzielles Thema: „Projektion , Architektur, Interaktion“

vj - towards an electronic art

programmierung

programmierung Der technische Bereich des Projektes umfasste zunächst die Entwicklung von drei Komponenten: - Engine - Selektors - Performers Die Engine ist das Kernstück des Systems, welches die Videoverarbeitung realisiert. Als Grundlage wird dabei GStreamer verwendet, ein Knoten-basiertes opensource System für Linux zur Verarbeitung von Mediendaten. Jede Art der Erzeugung, Manipulation und Darstellung von Daten wird darin durch einen Knoten repräsentiert, dem jeweils ein Plugin1 für das Framework zu Grunde liegt. Ein VJ-Setup ist lässt sich damit als eine Pipeline oder ein Graph von Knoten im GStreamer-System umsetzen. Als Basissystem war GStreamer für uns insbesondere deshalb geeeignet, da Plugins2 selbst programmiert und dem bestehende System hinzugefügt werden können, womit sich dessen Funktionalität nahezu beliebig erweitern lässt. Damit GStreamer für unser Zwecke genutzt werden konnte, wurde im Verlauf des Projekts ein GStreamer-Server entwickelt, welcher die Steuerung einer Pipeline von Knoten von außen, d.h. zum Beispiel über eine Netzwerkverbindung, ermöglicht.

vj - towards an electronic art

Die Engine sollte außerdem ein verteiltes System sein, in dem die GStreamer-Knoten auf beliebigen Rechnern verteilt sind. Der Selektor und der Performer bilden die Anwendungsschicht des Systems, welche mit dem GStreamer-Server kommuniziert. Während der Selektor vor allem zur Konfiguration der Engine für eine Performance vorgesehen ist, dient der Performer zur Steuerung der GStreamer-Pipeline während der Performance. Im Verlauf des Projektes zeigte sich, daß zusätzlich eine middleware als Schicht zwischen Performer und Engine notwendig ist, um die Verwendung beliebiger Eingaben als Steuerdaten für den GStreamer-Server zu ermöglichen. Die Anwendungsschicht und die middleware lassen sich dabei zur Peripherie eines GStreamer-Servers zusammenfassen. Programm ähnlich einer Bibliothek für das GStreamer System welches sich mittels eines Registrierungsmechanismus in das Framework integriert wird 2 entsprechend den GStreamer Spezifikationen 1

13

programmierung

Motivation

Bild: Größenvergleich herkömmlichen Multimeter - VribIn Box

VribIn-B Box: Eigenschaften - Analog-Digital Wandler - USB Anschluss - 4 Eingänge für analoge Signale mit jeweils 10 Bit Auflösung - 6 oder 10 Eingänge für binäre Signale - 2 integrierte Zähler - miniaturisiert (45x15x5mm) - preiswert

14

Bei der Bearbeitung der Aufgabe zum Bau eines Eingabegerätes1 zu Beginn des Semesters hatte sich gezeigt, dass uns im Projekt eine Möglichkeit zum Einlesen beliebiger Signale in den Computer fehlte. Da zunächst eine Fortführung der Arbeit am „Froschtrampolin“2 geplant war, versuchte ich, für dieses Problem eine Lösung zu finden. Die Bemühungen konzentrierte sich dabei insbesondere auf das Einlesen beliebiger elektrischer Signale, da für nahezu jede beliebige Signalquelle ein Sensor existiert, mit dessen Hilfe sich dieses in ein elektrisches Signal umwandeln läßt3. Das entsprechende Gerät zum Einlesen der Werte in den Computer sollte außerdem möglichst klein und preiswert sein. Nach Recherchen in Fachkatalogen und diversen anderen Quellen musste ich feststellen, dass es sehr schwer sein würde ein für uns ge-

eignetes Gerät zu finden, da noch immer nur wenige Messgeräte existieren, deren Werte sich direkt in einen Computer übertragen lassen. Das nächste Problem zeigte sich im Bereich der Software. Die existierenden Programme sind zum Erstellen von Messkurven und ähnlichen geeignet, nicht jedoch zum Einlesen von Steuerdaten. Diese Programme sind jedoch, ebenso wie die Geräte selbst, kommerzielle Produkte, so daß die Quellkodes und Hardware-Spezifikationen in der Regel nicht zugänglich sind. Ohne diese ist jedoch die Programmierung eines eigenen Treibers äußerst schwierig. Das Projekt „_handgriff“, das Schwesterprojekt von vj, beschäftigte sich jedoch ebenfalls mit der Herstellung von Eingabegeräten, so dass dort ähnliche Probleme aufgetreten sein mussten. Die Projektgruppe verwendeten zum Ein-

vj - towards an electronic art

programmierung

Grafik: Schichtenmodell des Systems Mai 2003

lesen von elektrischen Signalen in den Computer die VribIn Box; ein speziell für solche Anwendungen von logitech (amerikanischer Hersteller von Eingabegeräten) entwickelter A/D Wandler. Da dieser an der Universität verfügbar und offensichtlich für unseren Zweck sehr gut geeignet war, entschied ich mich meine Arbeit auf die Integration dieser Geräte in unser Framework zu konzentrieren. Damit wurde die Anwendungsschicht unseres Frameworks um das zu entwickelnden Programm zum Einlesen der Werte aus einer VribIn-Box, im folgenden als VribIn Input (VI) bezeichnet, erweitert.

Anwendungsschicht VribIn

APE

Engine GStreamer-Server

GStreamer-System mit Grafik Pipeline 1 Aufgabe: „Die CAD Zahnbürste“ 2 Eingabegerät zur Aufgabe „Die CAD Zahnbürste“ an

dem ich beteiligt war 3 Conrad Katalog: pdf.conrad.de

Hauptkatalog: Aktive/Passive Bauelemente

vj - towards an electronic art

15

programmierung

Einarbeitung Zunächst war eine Einarbeitung in die existierenden Programme zum Auslesen von Werten aus den VribIn-Boxen notwendig. Unter Linux erforderte dies auf Grund der bereits vorhandenen Programmbibliotheken keinen wesentlichen Arbeitsaufwand. Eines der Ziele für das gesamte Framework war jedoch, dass eine einfache Bedienung und Konfiguration ohne Spezialkenntnisse möglich sein sollte. Da viele VJ’s kein Linux benutzen, lag für mich die Implementation eines weiteren Programms für Windows nahe. Nach mehreren Gesprächen konnte auch für dieses Betriebssystem ein Basisprogramm gefunden werden, welches die Werte aus der VribIn-Box ausliest. Programmiertechnisch interessant ist dabei die technische Lösung, welche die Softwareentwickler von logitech, für die Basis-Implementation unter Windows gewählt haben. Um die Programmierung eines völlig neuen Treibers zu vermeiden, entschieden sie sich, das Betriebssystem-Interface eines Standard-HID-Joysticks1 zu verwenden und über dieses die Werte auszulesen. Damit konnten für das Basis-Programm die bereits durch das Betriebssystem

16

zur Verfügung gestellten Funktionen für Joysticks verwendet werden konnten. Der folgende Schritt zur Integration der VribInBoxen in das Framework war die Einarbeitung in die HTTP-Netzwerkprogrammierung unter C, da zu diesem Zeitpunkt noch das HTTPProtokoll zur Kommunikation mit dem GStreamer-Server verwendet werden sollte. Unter Linux bestand dabei zunächst das Problem eine geeignete Bibliothek zu finden, da es für C/C++ nur wenige Bibliotheken gibt, welche eine solche Funktionalität zur Verfügung stellen. Um die Konsistenz im Framework zu gewährleisten, entschied ich mich für die ghttp2 Bibliothek, welche bereits von den anderen Projektteilnehmern verwendet wurde. Unter Windows entschied ich mich auf Grund der sehr guten Dokumentation auf der microsoft Homepage3 dafür, die Standardbibliothek zu verwenden. Bei der Integration der HTTP-Verbindung in das Programm VI gab es unter beiden Betriebssystemen keine nennenswerte Probleme. Zum Zwischenrundgang lag damit die erste funktionsfähige Version des Programms VI vor,

so dass bei diesem die VribIn-Boxen bereits zur Steuerung einer Gstreamer-Pipeline über das HTTP-Protokoll verwendet werden konnten. Mit Hilfe eines einfache Eingabegerätes konnten so eine GStreamer-Pipeline auf Play, Pause und Stop gesetzt werden. Die endgültige Integration der VribIn-Boxen in das Framework war zu diesem Zeitpunkt noch nicht möglich. Zum einen existierte keine endgültige Version des Servers, welcher die Daten empfängt und damit die GStreamer-Pipeline steuert und zum anderen fehlte ein Protokoll, in welchem die Kommunikation mit diesem Server erfolgen sollte. Zwar war bereits zu Beginn des Semesters der ovjDemon5 entstanden, dass dieser jedoch nur eine Zwischenlösung sein konnte und eine vollständige Neuimplementation erforderlich sein würde, war auf Grund zahlreicher Probleme absehbar. 1 human interface devices 2 3 4 5

Details: HID.pdf CD: .../Programmierung/ghttp http://msdn.microsoft.com/visualc/ header: wininet.h erste Version eines GStreamer-Servers

vj - towards an electronic art

Elektrischen Kontakte Bild: VribIn Box (vergrößerte Darstellung)

Notwendigkeit middleware Im Verlauf des Projekts gewann jedoch ein zunächst nicht berücksichtigter Aspekt der Aufgabenstellung an Bedeutung. Das dieser jedoch in das Gesamtsystem integriert werden musste, wurde mit der Vorstellung des Konzepts für das Trampolin 1deutlich: Bei diesem war vorgesehen, dass auf Knopfdruck ein Fenster seine Größe ändert, was aus technischer Sicht eine Folge von Befehlen ausgelöst durch ein einzelnes Eingangssignal bedeutet. Ähnliche Probleme hatten sich bereits bei der Arbeit am Programm VI ergeben: Die Signale einer VribIn-Box2, oder jedes beliebigen anderen Eingabegerätes, besitzen einen spezifischen Wertebereich; genauso wie jeder Parameter eines Filters in einer GStreamer Pipeline ebenfalls einen bestimmten Wertebereich akzeptiert - es wäre in der Praxis dem Glück zu verdanken, wenn diese Intervalle übereinstimmen würden. Ungelöst war bis dahin auch, wie man mit einer VribIn-Box einen beliebigen Steuerbefehl an die GStreamer Pipeline senden kann; zum Beispiel eine existierende Pipeline auf play setzen kann.

vj - towards an electronic art

Es war damit ein Programm notwendig, welches Eingangswerte, zum Beispiel eingelesen aus einer VribIn Box, nach vorher definierten Regeln verarbeitet und die Ergebnisse anschließend an den GStreamer-Server sendet. Nach gemeinsamen Überlegungen im Plenum wurde eine Entscheidung gegen die Integration "logischer" Funktionalitäten in den GStreamerServer oder einen speziellen GStreamer Knoten getroffen, da diese Teile der Videoverarbeitung vorbehalten bleiben sollten. Eine Erweiterung des VI-Programms erschien mir ebenfalls nicht sinnvoll. Zum einen wäre dadurch eine doppelte Implementation5 notwendig gewesen und zum anderen hätte man die Funktionalität dann nicht für andere Datenquellen, wie zum Beispiel eine Maus, verwenden können3. Die benötigte Funktionalität wurde durch ein eigenes Programm, Daten VorVerarbeitung4 (DVV), in das Framework integriert, womit bei diesem nun zwischen Engine und Anwendungsschicht eine zusätzliche middleware Ebene eingefügt wurde

USB-Anschluss

1 Performance von Carmen Bergmann und Theresa

Große

2 maximaler Wertebereich [ 0 , 1023 ]; in der Praxis durch

den Aufbau der Eingabegeräte meist jedoch nur ein Teilintervall 3 Rückblickend betrachtet kommt noch der Punkt hinzu, dass sich ein eigenständiges Programm wesentlich leichter verändern und in anderes Framework integrieren lässt 4 der Arbeitstitel lautete zunächst noch Logik 5 einmal unter Linux und einmal unter Windows

17

programmierung

Grafik: Schichtenmodell des Systems Juni 2003

DVV - Konzept

Anwendungsschicht VribIn

APE

Anwendungsschicht Daten VorVerarbeitung

Engine GStreamer-Server

GStreamer-System mit Grafik Pipeline

Da ich mit den VI Programm bereits für die Realisierung eines Teils der Anwendungsschicht zuständig war, übernahm ich auf Grund der zum Teil ähnlichen Fragestellungen auch die Umsetzung der middleware. Zunächst musste ich mich dabei erneut in die Netzwerkprogrammierung einarbeiten. Für die Kommunikation mit dem GStreamer Server sollte nun das TCP und UDP Protokoll verwendet werden. Dies war jedoch ohne größere Probleme möglich, da hierzu zahlreiche gute Tutorials1 verfügbar sind und die Implementation unter Linux und Windows nahezu identisch ist. Vor der Realisierung des Programms war jedoch der Entwurf eines Konzepts und einer Programmstruktur erforderlich:Für das Framework auch die Möglichkeit von Setups mit mehreren GStreamer-Servern vorgesehen war, wurde im Konzept für das Programm DVV eine entsprechende Möglichkeit zum Versenden von Daten an mehrere Zielrechner, vorgesehen. 1 BEEJ - network programming:

- http://www.ecst.csuchico.edu/~beej/guide/net/ -network_programming.pdf

18

vj - towards an electronic art

programmierung

Logische Knoten Ausgang Bei dem Entwurf der Programmstruktur versuchte ich mich an den vorhandenen Systemen wie MAX/MSP zu orientieren, aber auch eine möglichst konsistente Integration in das Gesamtframework zu verwirklichen. In Anlehnung an die Signal-Netzwerke in MAX/MSP aber auch an die Filter Pipelines in GStreamer entwickelte ich die Idee eines Graphen von Knoten zur Realisierung der benötigten Funktionalität. Drei Klassen von Knoten erschienen mir dafür unbedingt notwendig: Eingänge, Logische Knoten, welche die Funktionalität realisieren und Ausgänge. Der gesamte Graph kann als eine Menge von Bäumen betrachtet werden, wobei über die Eigenschaften der Bäume die zulässigen Konfigurationen des Programms definiert werden. Für eine solche Programmstruktur bot sich die Realisierung in einem objekt-orientierten Programm an, wobei auf Grund der STL1 C++ als Sprache gewählt wurde. Vor der Implementation war es ebenfalls notwendig zu definieren, wie das Programm konfiguriert werden sollte; dass heißt, wie der Graph nach dem Programmstart erstellt wird. Die Ähnlichkeit der Struktur zu einer GStrea-

vj - towards an electronic art

Eingang

Logische Knoten Ausgang

Eingang

Logische Knoten Ausgang Logische Knoten

Eigenschaften der Bäume: mer-Pipeline und die Fortschritte bei der Realisierung des Selektors führten dazu, daß sich entschieden wurde, daß dieser auch das DVVProgramm konfigurieren sollte. Damit musste zur Konfiguration des DVV Programmes das gleiche Protokoll wie zur Erzeugung einer GStreamer Pipeline verwendet werden.

- alle Bäume haben die Tiefe zwei - Tiefe 0: Eingänge - jeder Eingang ist eine Wurzel - Tiefe 1: Logische Elemente - Tiefe 2: Ausgänge - jedes Element kann beliebig viele Kindund beliebig viele Vater-Knoten besitzen - ein Element kann zu mehreren Bäumen gehören

1 Standard Template Library: www.sgi.com/tech/stl

19

programmierung

Übersicht: Elemente im Programm DVV

Element-K Klasse

DVV - Umsetzung

Element-T Typ input

Eingänge list

Logische Elemente

Ausgänge

20

Beschreibung Eingang für beliebige Werte Eingang für eine Folge von Logischen Elementen, wobei bei einem Eingangssignal jeweils nur eines davon ausgeführt wird

corrector

Funktion, welche mit dem Eingangswert als Argument berechnet wird

message

string, welcher bei jedem Eingangssignal versendet wird

generator

- Funktion welche Werte generiert - Argument der Funktion ist die verstrichene Zeit seit dem Start des Elementes

ramp

- Funktion welche für ein Zeitintervall berechnet wird - Argument der Funktion ist die verstrichene Zeit seit dem Start des Elementes

sink

Ziel an welches die Daten versandt werden

Bei der Umsetzung des Programms stellte der Entwurf der Klassenhierarchie für mich die größte Herausforderung dar. Nach mehrfacher Umstellung habe ich mich dafür entschieden, jeden Elementtyp in nur einer Klasse zu realisieren. Rückblickend betrachtet ist dies keine optimale Lösung, da die Integration weiterer "logischer" Elemente damit relativ schwierig ist. Besser wäre hier eine Oberklasse für alle Logischen Elemente und eine davon abgeleitete Klasse für jeden logischen Elementtyp, wie zum Beispiel corrector gewesen. Die Datenstruktur des Programmes wird in der Klasse Liste verwaltet1, wo je eine map für jeden Elementtyp vorhanden ist. Die maps haben dabei folgende Struktur std::map Der Key ist dabei vom Datentyp string und enthält den Name des Objektes. Data ist eine Referenz auf eine Instanz der Elementklasse. Diese Verwaltung in unterschiedlichen maps ermöglicht die eindeutige Unterscheidung wel-

vj - towards an electronic art

programmierung

Übersicht: Klassen im Programm DVV

Klasse che Instanz der Klasse Logic_Node welche Funktionalität repräsentiert und welche Bedeutung damit die Member Variablen jeweils besitzen. Die Verbindungen zwischen Knoten im Graphen werden durch Referenzen auf das Element in der jeweiligen map in Liste realisiert, wobei jeder Knoten eine Referenz auf alle Kind- als auch auf alle Vater-Knoten hat. Die Namen der Elemente werden vom Programm automatisch erzeugt und sind im ganzen Programm eindeutig. Dies ermöglicht eine effektive Konfiguration des Graphen durch den Selektor2. Ein interessanter Aspekt bei der Programmierung war der Funktionsparser3, welche für die Elemente corrector, ramp und generator benötigt wurde, wobei es sich bei diesem als sinnvoll erwies, alle Daten soweit wie möglich als string zu verwenden. 1 Anhang IX: Teil der header Datei der Klasse Liste 2 Anhang VIII: Manipulation eines Elementes durch den

Selektor 3 Anhang VII: Berechnung einer Funktion

vj - towards an electronic art

Beschreibung

Liste

- enthält die Datenstruktur - jeweils eine Map bestehend aus Namen und Referenz auf eine Instanz für jeden ElementTyp - singleton

Init

- erzeugt die Datenstruktur auf Grundlage der Daten, welche über den TCP Port empfangen werden - wird nur zu Programmstart aufgerufen

Logic_Node

-

Logischen Knoten enthält die Parameter realisiert die Funktionalität Unterscheidung der verschiedenen ElementTypen erfolgt über die Verwaltung in verschiedenen Datenstrukturen

Verbindung

- enthält alle Parameter einer Verbindung - realisiert das Versenden der Daten - Aufbau der TCP Verbindung auf welchen die Initialisierungsdaten empfangen werden

Definition

-Typdefinitionen, welche in mehreren Klassen benötigt werden - Hilfsfunktionen welche in mehreren Klassen benötigt werden

21

programmierung Grafik: Graph bestehend aus Bäumen im Programm VI

VI - Anpassung sink0

analog0 analog1

ip: 128.19.122.10 port: 5001 protocol: udp parameter: “/input0”

analog2 sink1 ip: 224.117.20.19 port: 5003 protocol: tcp parameter: “/list0”

digital0

sink2

digital10

ip: 142.168.0.10 port: 3901 protocol: tcp parameter: “/openglsink0”

Aus den Arbeiten zum Programm DVV sowie der Veränderung der benutzten Protokoll ergab sich die Notwendigkeit einer Überarbeitung des VI-Programms. Bei der Implementation der TCP- und UDP- Verbindungen wurden auch in diesem Programm mehrere ZielSysteme ermöglicht, um eingelesene Werte an mehrere GStreamer-Server und/oder DVVProgramme versenden zu können. Zu diesem Zeitpunkt war im VI-Programm noch ungelöst, wie einzelne Eingänge der VribIn-Box bestimmten Filtern einer GStreamerPipeline oder bestimmten Eingängen im DVVProgramm zugeordnet werden sollten. Die Ähnlichkeit der Problemstellung mit denen, welche im DVV Programm bereits aufgetreten waren, legten dabei eine ähnliche Lösung wie in diesem nahe. Dabei kann man auch das VI-Programm als Graph bestehend aus einer Menge von Bäumen auffassen. Die input-Elemente1 sind dabei durch die VribIn-Box fest vorgegeben und werden mit den Senken im Programm verbunden. 1 Anhang VI: Zuordnung der Anschlüsse der Vrib-In Box

zu den input Elementen in VI Daten innerhalb des Programmes

22

Netzwerkverbindungen

vj - towards an electronic art

programmierung

Konfiguration1 Ein weiterer interessanter Aspekt bei der Programmierung für VI und DVV war die Kommunikation zur Konfiguration der Graphen. Da die Programmierung des Selektors in Macromedia FlashMX erfolgte, konzentrierte ich meine Arbeit hier ebenfalls auf dieses Programm. Dabei nutzte ich den XML-Socket, welchen Actionscript2 zur Verfügung stellt. Da nicht dokumentiert ist, auf welchem Netzwerk-Protokoll diese Verbindung basiert, war es nur aus den Eigenschaften und der Funktionsweise ersichtlich, dass es sich um einen TCP-Socket handelt, über welchen XML-konforme string Nachrichten versendet werden. In C/C++3 können diese TCP-Nachrichten über die durch die entsprechenden Bibliotheken zur Verfügung gestellten Funktionen empfangen werden. In Actionscript existieren dabei Funktionen zum Erzeugen und Verarbeiten von XML-Nachrichten, welche allerdings einen eigenen XML-Dialekt erzeugen, bei dem ein Befehl und alle zugehörigen Parameter in einem einzigen Tag enthalten sind.

Übersicht: Klassen im Programm VI

Klasse

Liste

- enthält die Datenstruktur - jeweils eine Map bestehend aus Namen und Referenz auf eine Instanz für jeden ElementTyp - singleton

Init

- erzeugt die Datenstruktur auf Grundlage der Daten, welche über den TCP Port empfangen werden - wird nur zu Programmstart aufgerufen

Element

- Eingang an der VribIn Box - enthält eine Referenz auf jeden Kind-Knoten - Referenz zeigt auf das entsprechende Element in der Map in Liste

Verbindung

- enthält alle Parameter einer Verbindung - realisiert das Versenden der Daten - Aufbau der TCP Verbindung auf welchen die Initialisierungsdaten empfangen werden - Inistialisierung der VribIn Box - Einlesen der Werte aus der VribIn Box und Weiterleitung an die korrekte Instanz von Element

1 Anhang I: Kommunikation FlashMX - C/C++ 2 Scriptsprache, die von FlashMX unterstützt wird 3 oder beliebigen anderen Hochsprachen, welche einen

TCP-Socket unterstützen

vj - towards an electronic art

Beschreibung

Definition

-Typdefinitionen, welche in mehreren Klassen benötigt werden - Hilfsfunktionen welche in mehreren Klassen benötigt werden

23

funktionsweise Screenshot: Programm VI - Arbeistphase

Programme: VI / DVV Die Programme VI und DVV sind als Pre-Release verfügbar. Beide sind unter Visual C++ 6.0 als Windows Kommandozeilen-Applikation entstanden, wobei das Kommandofenster lediglich zur Ausgabe von Status- und Kontrollmeldungen zu den Programmen dient. So werden unter anderem alle Nachrichten, welche über das Netzwerk versendet werden, hier angezeigt. Bei der Arbeit mit den Programmen VI und DVV lassen sich zwei Phasen unterscheiden:

1. Konfiguration2

2. Arbeitsphase

Die Konfigurationsphase dient zur Initialisierung der Graphen der Elemente. Dabei warten VI bzw. DVV zunächst darauf, dass das konfigurierende Programm eine Verbindung zu ihnen aufbaut über welche dann die Befehle zur Erzeugung des Graphen empfangen werden. Als konfigurierendes Programm wurde bis jetzt ausschließlich Macromedia FlashMX verwendet und als Protokoll TCP. Implementiert ist jedoch auch eine UDP Verbindung, so dass zur Konfiguration jedes Programm denkbar ist, welches XML-konforme TCP oder UDP Nachrichten versenden kann. Die XML-Nachrichten zur Erzeugung des Graphen müssen dabei dem warsaw pakt message protocol1 entsprechen, wobei die Befehle create, set, connect und 2 play zur Verfügung stehen und jeder Befehl mit einer Statusmeldung bestätigt wird.

Die Arbeitsphase beginnt in beiden Programmen mit dem Aufbau der Verbindungen, welche zum Versenden der Daten benötigt werden. Auf Grund der Protokoll-Spezifika wird nur ein Socket1 für alle UDP-Senken2 benötigt, da hier der Socket jeweils nur für den Sendevorgang an ein Zielsystem3 gebunden ist. Bei TCP-Verbindungen wird jedoch für jedes Ziel-System ein eigener Socket benötigt. Dabei ist eindeutig zwischen einer TCP-Senke4 und einem TCP-Socket zu unterscheiden ist, da eine TCP-Senke den zusätzlichen Parameter parameter besitzt. Das Versenden von Daten geschieht im Programm sequentiell5, was es ermöglicht, für alle Senken, welche das identische Ziel-System adressieren, dieselbe TCP-Verbindung zu verwenden.

1 www.subsignal.org/pakt 2 Anhang III & IV: Beschreibung der verfügbaren Elemente und Befehle

24

1 definiert auf einem Rechner durch die IP des Rechners, einen Port auf diesem sowie das Protokoll

(TCP oder UDP) in welchem die Daten versendet werden sollen 2 eine Senke, bei welcher der Parameter protocol den Wert UDP hat und damit das UDP Protokoll

zum Versenden der Daten verwendet 3 definiert durch Ziel-IP und Ziel-Port 4 eine Senke, bei welcher der Parameter protocol den Wert TCP hat und welche damit das TCP Pro-

tokoll zum Versenden der Daten verwendet 5 es kann zu einem Zeitpunkt nur über eine Verbindung ein Wert versendet werden

vj - towards an electronic art

funktionsweise

2.1. Arbeitsphase in VI

2.1. Arbeitsphase in DVV

Im Programm VI wird das Einlesen der Werte aus der VribIn-Box in einen eigenen thread realisiert. Wird ein Signal von der VribIn Box eingelesen so kann dieses über die ID2 dem korrekten Eingang an der VribIn-Box zugeordnet werden und der eingelesene Wert damit dem korrekte Eingangs-Element im Programm. Dieses Element ruft anschließend auf allen KindKnoten die Send-Funktion auf, welche das Versenden der Werte realisiert. Die eingelesen Werte werden mit dem Befehl 3 set des warsaw pakt message protocol versendet:

Die Arbeitsphase im Programm DVV lässt sich in vier Schritte unterteilen:

target muss dabei die vollständige Adresse des Zielelementes sein4, welche bereits in der Konfigurationsphase festgelegt wurde. 1 Signal wird nur festgestellt, wenn eine Wertänderung an

1. Warten auf Werte 2. Empfangen von Werten 3. Verarbeiten der Werte 4. Versenden der Ergebnisse der Verarbeitung Die Schritte werden dabei zyklisch durchlaufen, wobei der nächste Zyklus erst dann begonnen werden kann, wenn der letzte vollständig abgearbeitet wurde. 1 Auf dem in der Konfigurationsphase definierten Port und Netzwerk-Protokoll wird auf Nachrichten gewartet Format der XML-Nachricht, damit diese akzeptiert und zugeordnet werden kann:

der VribIn Box stattgefunden hat 2 Anhang VI: Anschlüsse der Vrib-In Box 3 www.subsignal.org/pakt 4 Beispiel: zur Adressierung eines Elements im DVV Pro-

gramm muss als Präfix ‘’/logic’’ vervendet werden

vj - towards an electronic art

2. Werden Nachrichten1 empfangen, so werden diese an den korrekten Eingang weitergeleitet. Der Eingang ruft mit dem erhaltenen Wert als Parameter die mit ihm verbundenen Logischen Knoten auf



input2 - alle Knoten - nur den aktiven Knoten list2 3. Der Typ des Logischen Knoten bestimmt dann ob und wie der Wert verarbeitet wird. corrector message ramp generator

-

Argument der Funktion Sendesignal Startsignal Startsignal

4. Jeder Logischer Knoten welcher aufgerufen wurde, versendet das Ergebnis seiner Verarbeitungsphase über alle Senken, welche mit diesem verbunden sind. 1 Nachrichten müssen dem warsaw pakt message proto-

col entsprechen und den Befehl set verwenden: 2 Anhang IV: Beschreibung der verfügbaren Elemente

25

programmierung

Mögliche Erweiterungen -Portierung des VI-Programmes unter Linux - VI für eine VribIn-Box mit 2 x 8 Eingängen. - Als Erweiterung ist dann ein Programm denkbar, welches für beide Typen von VribIn-Boxen verwendet werden kann und den Typ automatisch erkennt. - grafisches Interface zur Initialisierung des VI- und des DVV-Programms - Es sollte überlegt werden, in wie weit neben der Integration in den Selektor ein eigenständiges Interface geschaffen werden muss damit eine vom VJ-Framework unabhängige Nutzung möglich ist. - Die Konfigurationsphase sollte zum Start der Arbeitsphase nicht beendet werden müssen - Erzeugung, Prametrisierung und Verbindung neuer Elemente während des Arbeitsphase - Jedes logische Element des Programms DVV sollte in einer eigenen Klasse, abgeleitet von einer gemeinsamen Oberklasse, implementiert sein - Damit wäre eine ähnliche Funktionalität zum Einbinden von weiteren Logischen Elementen denkbar, wie sie GStreamer bereits für die Integration neuer Filter zur Verfügung stellt. D.h. die Logischen

26

Elemente stehen als Bibliotheken zur Verfügung, welche durch einen Registrierungsvorgang ihre Funktionalität dem Gesamtprogramm zugänglich machen. - Verbindungen von Logischen Elementen zu Logischen Elementen. - Neben der Erweiterung des Funktionsspektrums des Programms würde dies außerdem erlauben, dass Element list ( im Moment noch ein spezieller Eingang ) als Logisches Element zu realisieren, was die Gesamtstruktur des Programms wesentlich vereinfachen würde. - Im Programm VI wird die spezifische Funktionalität zum Einlesen der Werte aus den VribIn Boxen in einer einzelnen Klasse zur Verfügung gestellt. Es würde sich anbieten die anderen Klassen als Bibliothek zur Verfügung zu stellen, so dass eine einfache Integration weiterer Eingabegeräte, wie zum Beispiel Mäusen, in das Framework möglich wird - Löschen von Verbindungen von Elementen - Löschen von Elementen - Bennennung der Elemente durch den Nutzer

vj - towards an electronic art

programmierung

Weitere Ergebnisse Programmierung Während des Semesters sind bei meiner Arbeit neben VI und DVV zahlreiche weitere Programme entstanden. Insbesondere interessant ist dabei das Programm Vrib_Display sowie das Programmpaket Vrib_Flash.

1. Vrib_Display

Screenshot: Vrib_Display

Darstellung der aus der VribIn Box eingelesenen Werte auf dem Bildschirm. Insbesondere während der Entwicklung von Eingabegeräten hilfreich, da mit diesem Programm zunächst kontrolliert werden kann: - ob Werte eingelesen werden können - welchem Kanal sie zugeordnet sind - in welchem Wertebereich sie liegen Download: Vrib_Display.zip

2. Vrib_Flash

Screenshot: XML_Socket.fla

Das Programmpaket enthält ein Beispiel wie aus einer VribIn-Box ausgelesene Werte in einem Macromedia FlashMX Programm zur Verfügung gestellt werden können. Durch die enge Anbindung von Macromedia DirectorMX an FlashMX können die aus der Hardware ausgelesen Werte auch verwendet werden. Zur Kommunikation mit FlashMX wird dabei ebenfalls der XML-Socket aus Actionscript verwendet über welchen die Kommunikation mit dem Selektor erfolgte. Download: Vrib_Flash_Director.zip

vj - towards an electronic art

27

kommentar

Probleme Engine Arbeitsgruppe Trotz des funktionsfähigen Prototypen des Frameworks zum Ende des Semesters sind in meinen Augen gravierende Defizite in der Arbeit der Engine Gruppe im Laufe des Projektes aufgetreten. Zu Beginn des Semesters bestand schnell Konsens über die allgemeinen Spezifikationen, so dass bereits zu diesem Zeitpunkt eine gemeinsame Einarbeitung in die vorgesehenen Systeme wie GStreamer möglich gewesen wäre. Damit hätte man vermeiden können, daß die meisten Projektteilnehmer bei der Umsetzung ihrer Komponente auf sich alleine gestellt waren und eine gemeinsame Diskussion von Problemen und Alternativen auf einen sehr allgemeinen Rahmen beschränkt blieb. Ein weiteres Problem war, dass es im Verlauf des Projektes nicht gelungen ist, die allgemeinen Spezifikationen in eine konkretes Pflichtenheft für unser Framework umzusetzen. Dies wäre jedoch die Grundlage für alle weiteren Schritte gewesen und hätte für die Orientierung bei der Arbeit erleichtern können. Die Kommunikation zwischen den Projektteilnehmern war ein weiterer problematischer Bereich. So ist es zum Beispiel im Projektverlauf nicht gelungen, eine Plattform zu schaffen, die einen Einblick in die Arbeitsstände und

28

Grafik: Entwurf eines Konzeptes, welches nahezu unkommentiert geblieben ist

Fortschritte der einzelnen Teilnehmer ermöglicht hätte. Exemplarisch kann hier das warsaw pakt message protocol genannt werden, bei dem nur durch Zufall die Veröffentlichung, welche zu diesem Zeitpunkt allerdings schon zwei Wochen zurücklag, bekannt wurde Aber nicht nur die Kommunikation, sondern auch die Kooperation zwischen den Projektteilnehmern ließ Defizite erkennen. So wurde erst zum Endrundgang versucht die Komponenten zu einem Gesamtsystem zu vereinen. Vor allem, da vorher kein gemeinsames Arbeitstreffe vereinbart werden konnte.

vj - towards an electronic art

Bild: „Trampolin“ während des Rundgangs

Allgemeine Projektarbeit Die Programmierung im Rahmen des Projektes begann jedoch nicht erst mit der Arbeit am Framework, sondern bereits zu Beginn des Semesters bei der Bearbeitung der Pflichtaufgaben. Ich nutzte dabei vor allem Lingo1 unter Macromedia DirectorMX zur Visualisierung meiner Ideen. Dabei sind unter anderem eine interaktive Demo zu meinem Konzept sowie die Applikation, welche über das „Froschtrampolin“ angesteuert wird, entstanden2. Interessant waren dabei die Möglichkeiten, welche Lingo und Macromedia DirectorMX für den Entwurf virtueller Umgebungen und interaktiver Systeme bieten. Modelle und dreidimensionale Umgebungen können aus Standard-3D-Programmen3 direkt in DriectorMX importiert werden5 und lassen sich dort ohne weiterführende Programmierkenntnisse4 in interaktive Umgebungen integrieren. Für zukünftige interdisziplinäre Projekte bietet dies zahlreiche Möglichkeiten, da Gestalter und Designer nun nicht mehr auf Papierskizzen oder die Hilfe eines Informatikers angewiesen sind, um ihre Ideen darzustellen. Vielmehr können sie selbstständig interaktive Prototypen erstellen und so ihre Konzepte testen und optimieren. Die endgültige Implementation im

vj - towards an electronic art

Echt-System ist dadurch nur noch für tatsächlich ausgereifte und funktionsfähige Konzepte notwendig. Durch die Programmierung an den VribInBoxen war ich auch der Ansprechpartner für die Integration von Eingabegeräten in das Framework, so dass ich unter anderem an der Umsetzung des „Trampolins“6 und des „Performance Anzugs“6 beteiligt war. Bei dieser Arbeit trat unter anderem das Problem auf, wie mehr als vier analoge Eingangssignale mit Hilfe einer VribIn-Box eingelesen werden können. Durch die Verwendung eines Wertebereichsmultiplexing3 konnte hier eine Lösung gefunden werden. Zum Rundgang vom 3. bis 6. Juli gehörte die elektrotechnische Betreung des „Trampolins“ und der Aufbau des Demo-Setups zu meinen Aufgaben. Auf Grund einiger organisatorischer Probleme zum Rundgangs, übernahm ich die Koordination der Vorbereitung für die Endpräsentation. Als Hauptproblem erwies sich dabei die Installation des pakt-Servers, da zu diesem Zeitpunkt keine funktionsfähige Version verfügbar war. Mit der Unterstützung durch die Mitglieder von subsignal9 konnte dieser, ebenso wie

der Selektor, jedoch rechtzeitig installiert werden. Insgesamt verlief die Endpräsentation erfolgreich und es konnte, wie bei der Performance zur CMC10 am Vortag, ein funktionierendes Setup gezeigt und anhand der Folien erläutert werden. 1 2 3 4

Scriptsprache, die von DirectorMX unterstüzt wird Froschtrampolin.exe wie AliasWavefront MAYA oder Discreet 3DSMax mit Hilfe vordefinierte Objekte, welche nur auf die importierte Szene angewendet werden müssen 5 die Geometrie muss dazu mit dem Shockwave-Exporter-Plugin aus dem 3D-Programm exportiert werden 6 Performance von Carmen Bergmann & Theresa Große 7 Performance Idee von Patrick Borowski 8 möglich wird dies in dem man den Wertebereich der analogen Eingänge von 0 bis 5V in Zonen, zum Beispiel von 0 bis 1V, 1,5 bis 2,5V etc., aufteilt. Durch die hohe 10Bit Auflösung der Eingänge ist damit im allgemeinen immer noch eine ausreichend genaue Auflösung gewährleistet 9 Initiative des StuKo: www.subsignal.org 10 Performance von Max Schreier

29

zusammenfassung

Zusammenfassung

30

Das Ziel des Projektes lag in der Schaffung eines Software-Systems, mit dem man ein beliebiges VJ-Setup umsetzen kann. Die Aufgabe der Studierenden der künstlerischen Studiengänge sollte dabei die Vorgabe der Funktionalitäten des Systems und die Entwicklung einiger exemplarischer Setups sein. Die Studierenden der Mediensysteme hatten die Aufgabe diese Funktionalitäten zu implementieren und damit die Realisierung der exemplarischen Setups zu ermöglichen.

de Konvergenz zeigt sich besonders deutlich bei der Umsetzung des Trampolins1 und der CMC2, wo jeweils ein spezielles und nur für diesen Zweck entwickeltes Setup verwendet wurde. Das zweite Problem war ein für mich spürbarer Mangel an Organisation und Koordination. So fehlte während des gesamten Projektes eine Instanz welche Aufgaben zugeteilt, Termine gesetzt und diese nötigenfalls auch eingefordert hätte.

In meinen Augen wurde das Projektziel damit nicht vollständig erreicht. Das Framework - das zu entwickelnde Software-System - hat mittlerweile ein funktionsfähiges Stadium erreicht, zu einer allgemeinen Verwendbarkeit fehlt jedoch noch Erfahrungen beim Umgang und der Konfiguration. Neben den Problemen im technischen Bereich, gab es meiner Meinung nach auch zwei allgemeine Probleme: Zum ersten ist im Projekt keine Konvergenz der verschiedenen Ideen und Vorstellungen über die Eigenschaften des Systems gelungen. Nach der kreativen Phase der Ideenfindung fehlte die koordinierte Suche nach Gemeinsamkeiten in den Konzepten und die Formulierung allgemeiner Anforderungen. Diese mangeln-

Bei einer weiteren Arbeit am entstandenen System muss zunächst eine Evaluierung des vorhandenen Frameworks stattfinden, um dann die vorhandenen Probleme, insbesondere in Bezug auf die allgemeine Verwendbarkeit, zu lösen. Aus technischer Sicht sollte dabei die Arbeit an der OpenGL-Senke sowie die Erweiterung des Selektors im Vordergrund stehen. Beim Selektor wären dabei für mich auch anderen Programmiersprachen vorstellbar, insbesondere um die, im Bereich des Interfacedesign bereits angedachten, Ideen weiterverfolgen zu können. 1 Performance von Carmen Bergmann und Theresa Große 2 Performance von Max Schreier

vj - towards an electronic art

anhang Anhang I: Kommunikation zwischen FlashMX und C/C++ Zum Versenden oder Empfangen von XML-Nachrichten muss sich Macromedia FlashMX zunächst mit einem TCP-Socket verbinden. Dies bedeutet, dass Macromedia FlashMX sich als Client mit einem C/C++ Programm verbindet, welches damit Server-Funktionalität besitzen muss. Actionscript-Kode zum Aufbau eines XML-Sockets: // Kontrolle ob die Verbindung korrekt ist this.Verbindung_Testen = function( Rueck ) { if (Rueck) trace("Verbindung erfolgreich initialisiert.") else trace("Fehler bei der Initialisierung der Verbindung") } // Verarbeiten der Daten this.Nachricht_Empfangen = function( doc ) { if (doc.firstchild != null) { var Daten = doc.firstchild trace(doc) }} //----------------MAIN-----------------------Flash_Socket = new XMLSocket() // EventHandler zuweisen Flash_Socket.onConnect = this.Verbindung_Testen; Flash_Socket.onXML = this.Nachricht_Empfangen; // Verbindungsaufbau if ( Flash_Socket.connect( "localhost" , 5100 ) == 0 ) { trace("Fehler bei Connect."); }

32

vj - towards an electronic art

vj - towards an electronic art int Bytes_Server_Gesendet; // Versenden der Bestaetigungsmeldung an den Selektor Bytes_Server_Gesendet = send( Sender , Send_Buffer , Init.size() ,0 ); if (Bytes_Server_Gesendet == -1) { WSACleanup(); return false; } return Sender; }

// Schreiben des Inhaltes des zu sendenden Buffers char * Send_Buffer =(char *)calloc( Init.size() , sizeof( char) ); sprintf( Send_Buffer , "%s\0" , Init.c_str() );

// Bestaetigung des Verbindungsaufbaus std::string Init="\n\n";

std::cout

set

Beispiel:

zum Verändern von Parametern von Elementen

Erzeugung einer neuen Senke in DVV





vj - towards an electronic art

35

anhang Bemerkung

create

Die Antwortnachricht enthält den Namen des erzeugten Elementes, welcher zum Setzen der Parameter sowie dem Verbinden des Elements notwendig ist

- zur Erzeugung eines neuen Elementes - Elemente können in VI als auch in DVV nur auf root Ebene erzeugt werden

Beispiel Erzeugung einer neuen Senke in DVV

VI: DVV:

target="/vribin" target="/logic"



Beispiel

connect

Verbindung eines Eingangs mit einer Senke im Programm VI

- zum Verbinden von Elementen



- für to gelten die identischen Konventionen wie für target

Programmstart Ein vollständige Programmkonfiguration besteht aus einer Folge von Befehle. Im Allgemeinen werden dabei zunächst die notwendigen Elemente erzeugt, im nächsten Schritt die Parameter der Elemente gesetzt und abschließend die Elemente zu Bäumen verbunden. Im Programm DVV können zusätzlich Parameter für die Arbeitsphase gesetzt werden. Nach der Konfiguration des Graphen wird mit dem Befehl play die Arbeitsphase gestartet. VI bzw. DVV beenden daraufhin die Verbindung, welche zur Konfiguration genutzt wurde.

36

vj - towards an electronic art

anhang Anhang IV: Elemente der Graphen im VI- und DVV-Programm 1. Eingänge - können nur im Programm DVV frei erzeugt und parametrisiert werden

1.1 input:

Bemerkung

- Eingang für beliebige Daten - werden die Eingangsdaten akzeptiert, so werden diese von allen Kind-Knoten verarbeitet

werden min und/oder max nicht gesetzt so bestehen dafür keine Beschränkungen

Eigenschaften min max

Minimum des Eingangssignales damit es akzeptiert wird Maximum des Eingangssignales damit es akzeptiert wird

1.2 list

Achtung

- Folge von Logischen Knoten - bei jedem Eingangssignal wird jeweils der nächste Logische Knoten der Folge verarbeitet - ist das Ende der Folge erreicht, so wird wieder beim ersten Logischen Knoten begonnen, welcher verarbeitet werden soll

Die Reihenfolge der Logischen Knoten in der Folge wird durch die Reihenfolge in der die list mit diesen verbunden wird bestimmt

Eigenschaften Verwendung next end

erster Logischer Knoten der Folge welcher verarbeitet werden soll letzter logischer Knoten der Folge welcher verarbeitet werden soll

vj - towards an electronic art

- wurde zum Beispiel zur Endpräsentation zum Durchschalten der Beispielfilter verwendet

37

anhang

2. Logische Elemente - stehen nur im Programm DVV zur Verfügung

Verwendung

2.1 corrector

- zur Anpassung des Wertebereiches des Eingangssignales an einen bestimmten Filter der Grafik Pipeline - häufig in Verbindung mit dem VI-Programm als Datenquelle

- Funktion welche das Eingangssignal als Argument verwendet Eigenschaften: function:

Funktion welche verwendet werden soll

Arithmetik

- Argument: x - unäre Operatoren:sin, cos, tan, int (ganzzahliger Anteil) - binäre Operatoren: +,*,-,/ - beliebige Klammerung möglich

Verwendung

2.2 message

- Aktivierung/Deaktivierung von Elementen - zum Beispiel im Setup zur Endpräsentation - häufig in Verbindung mit list

- Nachricht welche ohne Veränderung bei jedem eingehenden Signal versendet wird - Wert des Eingangssignales wird nicht berücksichtigt Eigenschaften: message:

38

Nachricht welche versendet wird

vj - towards an electronic art

anhang

2.3 generator Verwendung - erzeugt anhand einer Funktion Werte welche versendet werden - das Argument der Funktion ist die verstrichene Zeit seit dem Start des Generators Achtung: Eigenschaften:

jedes Eingangssignal erzeugt einen eigenen Generator1

function:

Funktion welche zur Werterzeugung verwendet wird

- zum Beispiel Sinusgenerator

2.4 ramp Verwendung - erzeugt anhand einer Funktion für eine definierte Zeit Werte welche versendet werden - das Argument der Funktion ist die verstrichene Zeit seit dem Start des Generators Eigenschaften: function: time:

Funktion welche zur Werterzeugung verwendet wird Zeit für welche der Generator aktiv ist

vj - towards an electronic art

- langsame Verstärkung von Filtern ohne manuelles Regeln - zum Beispiel zum langsamen Vergrößern der Bildschirmausschnitte mit nur einem Knopfdruck als Startsignal

39

anhang 3. Ausgänge - stehen sowohl im VI- als auch im DVV-Programm zur Verfügung

3.1. sink - eine Verbindung über welche die eingelesen Daten versandt werden Eigenschaften ip port protocol

IP-Adresse des Ziel Rechners Port auf dem Ziel Rechner Protokoll über welches die Daten versandt werden - tcp oder upd - Standard: udp1 Ziel Element für welches die Daten bestimmt sind

parameter

Zulässige Verbindungen Verbindungen von Elementen mit dem Befehl connect sind nur zwischen folgenden Elementen zulässig Programm VI DVV

40

target Eingang Eingang Logische Knoten

to Senke Logische Knoten Senke

vj - towards an electronic art

anhang 4. Globale Parameter - stehen nur im Programm DVV zur Verfügung Bemerkung

4.1 port_send - erster Port welcher zum Versandt der Daten benutzt wird - werden mehrere Ports benötigt, so werden auch die folgenden Ports verwendet Standard

5004

Für alle UDP-Verbindungen wird der selbe Port verwendet. Besitzen mehrere Instanzen sinks den identischen ZielRechner und Ziel-Port zu wird zu diesem nur eine Verbindung aufgebaut

4.2 port_listen - Port auf welchem die Daten empfangen werden Standard

5001

4.3 protocol_listen - protocol in welchem die Daten empfangen werden - tcp oder udp Standard

udp

vj - towards an electronic art

41

anhang Anhang V: Beispiel Konfiguration DVV (analog VI) Die XML-Nachrichten müssen über die Netzwerkverbindung zur Konfiguration zum Programm übertragen werden. // Erzeugung eines neuen inputs Antwort: // es sollen keine Beschränkungen für min und max gelten // Erzeugung eines neuen correctors Antwort: // Setzen der Parameter des correctors Antwort: // Erzeugung einer neuen Senke Antwort: // Setzen der Parameter der Senke Antwort: Antwort: Antwort: Antwort: // Verbinden der Elemente // Starten der Arbeitsphase

42

vj - towards an electronic art

anhang Anhang VI: VribIn-Box mit 2 x 10 Anschlüssen - Zuordnung Anschluss

Kode

Element

Anschluss

Kode

Element

Anschluss

Kode

Element

Anschluss

Kode

Element

01

-

LED

06

0

analog0

11

1535

digital9

16

2039

digital3

02

-

0 Volt

07

1983

digital6

12

-

0 Volt

17

2031

digital4

03

3

analog3

08

1919

digital7

13

2046

digital0

18

2015

digital5

04

2

analog2

09

-

5 Volt

14

2045

digital1

19

-

5 Volt

05

1

analog1

10

1023

digital6

15

2043

digital2

20

1791

digital10

VribIn Box Analoge Eingänge Digitale Eingänge

LED

10 09

20 19

08 07

18 17

06 05

16 15

04 03

14 13

02 01

vj - towards an electronic art

12 11

43

anhang Anhang IX: private-Teil aus der header Datei der Klasse Liste // // // //

Datenstrukturen bestehen jeweils aus Namen und einen Zeiger auf das dem Namen zugeordnete Elmenet die Namen sind programm-weit eindeutig -> ein Name existiert ueber allen Maps nur einmal

// Datensrukutur fuer die Eingaenge Definition::Map_Input Liste_Input_; Definition::Map_Input Liste_List_; // Datenstrukutur fuer die funktioalen Knoten Definition::Map_LogicNode Liste_Ramp_; Definition::Map_LogicNode Liste_Nachricht_; Definition::Map_LogicNode Liste_Korrektor_; Definition::Map_LogicNode Liste_Generator_; // Datensrukutur fuer die Senken Definition::Map_Verbindung Liste_Verbindung_; // -------------------------------------------------------------------------------------// Fuer die automatische Benennunng der Elemente long Anzahl_Input_; long Anzahl_Korrektor_; long Anzahl_Nachricht_; long Anzahl_Verbindung_; long Anzahl_List_; long Anzahl_Ramp_; long Anzahl_Generator_;

44

vj - towards an electronic art

anhang Anhang VII: Berechnung eines Funktionswertes in DVV Bei der Berechnung einer Funktion wird in Vorbereitung_Funktion zunächst das Argument, im Moment mit ' x ' definiert, durch den empfangenen Wert ersetzt und eventuelle nicht C kompatible Zeichen (zum Beispiel Komma als Zahltrennzeichen) konvertiert. Anschließend wird die Funktion rekursiv zerlegt, bis eine direkte Berechnung eines Teiltermes möglich ist. Hier erwies sich die Entscheidung für C++ und die Benutzung der STL als sehr hilfreich. So konnte ein Funktor verwendet werden um mit der selben Funktion Eval_Funktion Potenzen, Punkt und Strichrechnung zu berechnen. Da gilt "(Potenzrechnung vor) Punktrechnung vor Strichrechnung" wird die Funktion zunächst mit dem Funktor für Potenz, anschließend mit dem Funktor für Punktrechnung und als letztes mit dem Funktor für Strichrechnung aufgerufen. // Funktion in welchem Eval_Funktion mit verschiedenen Funktoren aufgerufen wird std::string Logic_Node::Main( std::string Funktion , bool Nur_Klammern ) { // Evaluierung unaerer Operatoren: z.B. sin(x) // muss vor Berechnung der Klammern ohne Operator erfolgen, damit // hier nach der Berechnung der Klammern noch der Operator angewandt wird Funktion = Eval_Unaer( Funktion ); // Berechnung der Klammern Funktion = Eval_Klammern( Funktion ); // Aufruf aus Eval_Unaer -> keine Verknuepfung der Elemente if (Nur_Klammern) return Funktion; // Erstens: Berechnung der Potenzen Funktion = Eval_Funktion( Funktion , Funktor_Vergleich( Referenz_Potenz )); // Zweitens: Berechnung der Punktrechnung Funktion = Eval_Funktion( Funktion , Funktor_Vergleich( Referenz_Punkt ) ); // Drittens: Berechnung der Strichrechnung Funktion = Eval_Funktion( Funktion , Funktor_Vergleich( Referenz_Strich ) ); return Funktion; }

vj - towards an electronic art

45

anhang // Funktion zur Berechnung von elementaren Ausdruecken mit binaerer Operatoren std::string Logic_Node::Eval_Funktion( std::string & Funktion , Funktor_Vergleich & Funktor ) { // Lokale Variablen int Min_Laenge; std::vector::iterator Operator = Funktion.begin() ; Operator--; while (true) { std::vector::iterator Temp; int Term_Ende; int Term_Anfang; // Laufvariable int k = 2; std::string Zahl_2; std::string Zahl_1; Operator++; // Operator + 1, da ansonsten das Vorzeichen mit beruecksichtigt wird Operator = std::find_if ( (Operator+1) , Funktion.end() , Funktor ); // Funktion vollstaendig verarbeitet oder Operator nicht enthalten if ( Operator == Funktion.end() ) break; // Ermittelung der Position des Operators int Pos_Operator = std::distance( Funktion.begin() , Operator ); char Operator_Char = Funktion[ Pos_Operator ]; // ---------------------------------------------------------------------------// Ermittelung des rechten Operanden // In einer validen Funktion muss nach dem rechten Operanden ein weiterer // arithmetischer Operator kommen oder die Funktion dort zu Ende sein Temp = std::find_if \ ( (Operator+1) , Funktion.end() , Funktor_Vergleich( Referenz_Operator ) ); if (Temp == Funktion.end() ) { // weiterer arithmetischer Operator hinter dem aktuellen enthalten Term_Ende = Funktion.size(); Zahl_2 = Funktion.substr( (Pos_Operator+1) , Term_Ende ); }

46

vj - towards an electronic art

anhang else { // kein weiterer arithmetischer Operator hinter dem aktuellen enthalten Term_Ende = std::distance( Funktion.begin(), Temp ); Zahl_2 = Funktion.substr( (Pos_Operator+1) , (Term_Ende - Erg_Zahl - 1) ); } // ---------------------------------------------------------------------------// Ermittelung des linken Operanden // Vom Operator wird solange nach "links" gegangen bis der Anfang der // Funktion erreicht ist, oder der vorhergehende arithmetische Operator ist Temp = std::find_if ( (Operator - 2) , (Operator - 1) , Funktor_Vergleich( Referenz_Operator ) while ( (Temp == (Operator-1) ) && (k Set_Ziel_IP( Wert ); else if (Parameter == "port") Ziel->Set_Ziel_Port( Wert ); else if (Parameter == "parameter") Ziel->Set_Gst( Wert ); else if (Parameter == "protocol") Ziel->Set_Protocol( Wert ); else return false; return true; }

vj - towards an electronic art

49

anhang // // // // // //

-----------------------------------------------------------------------Verarbeiten eine Set Anweisung Prinzip: Namen sind im gesamten Programm eindeutig -> Durchsuchen aller Maps in Liste wo das Element vorkommen koennte -> wird ein Element mit dem gesuchten Namen gefunden, muss es automatisch das korrekte sein

std::string Init::Set_Verarbeiten( {

Liste * List , std::string & Parameter )

// Konstruktion des Basis-Ergebnisstrings std::string Rueckgabe = \ ""; // Welches Element soll wie veraendert werden std::string Ziel = Definition::Get( Parameter , "target=\"/logic" ); std::string Wert = Definition::Get( Parameter , "value=\"" ); // Endgueltige Konstruktion des Ergebnisstrings Rueckgabe.replace( Rueckgabe.find( "*" , 0) , 1 , Ziel ); Rueckgabe.replace( Rueckgabe.find( "+" , 0) , 1 , Wert ); // Suche des Parameters welcher manipuliert werden soll // muss der String nach dem letzten '/' sein int Pos = Ziel.find_last_of( "/" ); std::string Feld = Ziel.substr( Pos+1 , (Ziel.size() - Pos - 1) ); // Suche nach dem Namen des Knotens welcher manipuliert werden soll // muss String zwischen dem vorletzten und letzen '/' sein std::string Rest = Ziel.substr( 0 , Pos ); Pos = Rest.find_last_of( "/" ); std::string Knoten_Name = Rest.substr( Pos+1 , (Ziel.size() - Pos) ); // Re-Ersetzung nicht korrekt konvertierter // i.a. Netzwerk Protokoll/Schicht Probleme Wert = Wert_Vorverarbeiten( Wert , "");

bool Ergebnis = true; // Ein Element des Programmes soll veraendert werden if (Knoten_Name == "") Ergebnis=Root_Manipulieren( List , Feld , Wert );

50

vj - towards an electronic art

anhang // -----------------------------------------------------------------------// Suche des Elementes in den Containern in Liste Definition::Iter_Input Input_Ziel = List->Get_Input( Knoten_Name ); Definition::Iter_Input Liste_Ziel = List->Get_Liste( Knoten_Name ); Definition::Iter_LogicNode Definition::Iter_LogicNode Definition::Iter_LogicNode Definition::Iter_LogicNode

Nachricht_Ziel = List->Get_Nachricht( Knoten_Name ); Korrektor_Ziel = List->Get_Korrektor( Knoten_Name ); Ramp_Ziel = List->Get_Ramp( Knoten_Name ); Generator_Ziel = List->Get_Generator( Knoten_Name );

Definition::Iter_Verbindung Verbindung_Ziel=List->Get_Verbindung( Knoten_Name ); // ----------------------------------------------------------------------------// Aufruf der korrekten Funktion zum Element if ( Input_Ziel != NULL ) Ergebnis = Input_Manipulieren( Input_Ziel->second , Feld , Wert ); else if (Korrektor_Ziel != NULL ) Ergebnis = Korrektor_Manipulieren( Korrektor_Ziel->second , Feld , Wert ); else if (Nachricht_Ziel != NULL ) Ergebnis = Nachricht_Manipulieren( Nachricht_Ziel->second , Feld , Wert ); else if ( Verbindung_Ziel != NULL ) Ergebnis = Verbindung_Manipulieren( Verbindung_Ziel->second , Feld , Wert ); else if ( Liste_Ziel != NULL ) Ergebnis = Liste_Manipulieren( Liste_Ziel->second , Feld , Wert ); else if ( Ramp_Ziel != NULL ) Ergebnis = Ramp_Manipulieren( Ramp_Ziel->second , Feld , Wert ); else if ( Generator_Ziel != NULL ) Ergebnis = Generator_Manipulieren( Generator_Ziel->second,Feld , Wert ); else Rueckgabe = ""; if (!Ergebnis) Rueckgabe = ""; return Rueckgabe; }

vj - towards an electronic art

51

anhang Anhang X (rechts): Initialisierung der Verbindungen zum Versenden der Daten in VI und DVV // Aufbau der notwendigen Verbindungen zum Versenden der Daten bool Liste::Init_Ports() { Definition::Iter_Verbindung Iter; bool Ergebnis = true; int Port = Port_Send_; // Initialisierung des Listen Ports auf dem die Daten empfangen werden if ( (Listen_->Get_Protocol()) == "tcp" ) Ergebnis = Listen_->Init_TCP(); else if ( (Listen_->Get_Protocol()) == "udp" ) Ergebnis = Listen_->Init_UDP(); else return false; if (! Ergebnis) return false; // Initalisierung des UDP-Sockets // -> wird von allen UDP-Verbindungen gemeinsam genutzt UDP_Standard_ = new Verbindung(); UDP_Standard_->Init_UDP( Port_Send_ ); SOCKET * UDP = UDP_Standard_->Get_Socket(); Port++; // Schleife zur Initalisierung aller Verbindungen for (Iter = Liste_Verbindung_.begin() ; Iter != (Liste_Verbindung_).end(); Iter++) { // Falls meherer Instanzen von Verbindung Daten an den selben Rechner und // den selben Port via TCP senden, ist ausreichend einen Socket zu binden // -> falls TCP Kontrolle notwendig, ob Verbindung bereits besteht if ( ((Iter->second)->Get_Protocol()) == "tcp") { Definition::Iter_Verbindung Iter_Check; sockaddr_in Adresse_Referenz = (Iter->second)->Get_Ziel_Adresse();

52

vj - towards an electronic art

anhang // Vergleich mit allen Knoten, welche "vorher" in Verbindung liegen resp. // bereits initialisiert wurden for(Iter_Check = Liste_Verbindung_.begin();Iter_Check != Iter;Iter_Check++) { // aktuelles Referenz-Element ist keine TCP Verbindung //-> interessiert nicht -> weiter if ( ((Iter->second)->Get_Protocol()) != "tcp" ) continue; sockaddr_in Adresse_Aktuell = (Iter_Check->second)->Get_Ziel_Adresse(); // Vergleich der Zieladress-Parameter if (( Adresse_Referenz.sin_addr.s_addr == Adresse_Aktuell.sin_addr.s_addr ) && \ ( Adresse_Referenz.sin_port == Adresse_Aktuell.sin_port )) { // Uebernehmen der Verbindung (Iter->second)->Set_Socket( (Iter_Check->second)->Get_Socket() ); break; } } // Es besteht noch keine passende Verbindung //-> Aufbau einer neuen TCP-Verbindung notwendig if (Iter_Check == Iter) { Ergebnis &= (Iter->second)->Init_TCP_Connection( Port ); Port++; } } else // UDP Connection Ergebnis &= (Iter->second)->Init_UDP_Connection( UDP , UDP_Standard_ ); } if (Ergebnis) std::cout