Hochauflösender Export aus vvvv

Bitte beachten Sie, dass die HTML Version vor allem dazu dient, die indizierbarkeit des Inhals durch Suchmaschinen zu erleichtern. Eine wesentlich lesbarere Version enthält dieses pdf.

 

2| vvvv als Grafikwerkzeug

vvvv ist ein Vertreter der sich zur Zeit sehr schnell verbreitenden, visuellen Multimedia-Programmiersprachen (auch „grafische Programmierumgebungen“ genannt), welche eine gänzlich andere Strategie verfolgen als Programmiersprachen mit textbasierten Syntax:
“A visual language manipulates visual information or supports visual interaction,
or allows programming with visual expressions.”
(Golin 1990, 141ff)
Diese, von E. J. Golin in seinem Artikel “The Specification of Visual Language Syntax” gemachte Aussage sagt also, dass eine visuelle Sprache visuelle Informationen manipuliert, eine visuelle Interaktion unterstützt oder programmieren über visuelle Ausdrücke ermöglicht.
B.A. Myers hingegen definiert eine grafische Programmiersprache als ein Programm, das in zwei oder mehr Dimensionen geschrieben wird:
“Any system where the user writes a program using two or more dimensions.”
(Myers 1990, 97ff)
Damit spielt er auf die Positionierung von Funktionsblöcken auf den Arbeitsflächen von visuellen Entwicklungsumgebungen an.
Eine noch präzisere Definition liefern uns M. Burnett, A. Goldberg und T. Lewis in ihrem Buch ”Visual Object-Oriented Programming: Concepts and Environments”:
“A visual language is a set of spatial arrangements of text-graphic symbols with a
semantic interpretation that is used in carrying out communication actions in the world.”
(Burnett 1994)
Eine visuelle Sprache ist ein räumliches Arrangement von beschrifteten grafischen Symbolen, die semantisch interpretiert werden müssen, um innerhalb der Programmierumgebung miteinander kommunizieren zu können. Auf diese 3 Definitionen bezieht sich jede Erwähnung einer “grafischen Programmiersprache” oder “grafischen Programmierumgebung” in diesem Werk. Dieser Begriff ist nicht mit integrierten Entwicklungsumgebungen (IDEs) wie Borland Delphi oder Eclipse (www.eclipse.org) zu verwechseln, die grafische Oberflächen für textbasierte Programmiersprachen sind.
Die zwei bekanntesten Vertreter dieser grafischen Programmierumgebungen sind: puredata (puredata.org) und max|msp (cycling74.com).

 

2|1| Über grafische Programmierumgebungen

Alle grafischen Programmierumgebungen benutzen so genannte „Knoten“ (engl. „nodes“), um Funktionen der Programmiersprache darzustellen. Diese Funktionsblöcke, die nach Belieben auf einer Arbeitsfläche verteilt werden können, erfüllen die unterschiedlichsten Aufgaben, die, je nach verwendeter Software, unterschiedliche Anwendungsgebiete abdecken. Es gibt Spezialsoftware für Klangerzeugung und Audioanalyse, Prototyping Systeme für die Spieleindustrie, ein Tool, das sich ganz auf die Bildanalyse konzentriert und auch stark visuell orientierte Technologien, die sich für die Erstellung von Designobjekten eignen. Eine Gemeinsamkeit dieser grafischen Programmierumgebungen ist, dass alle Knoten nach genau festgelegten Regeln miteinander verbunden werden können, was den Knoten erlaubt, untereinander Daten auszutauschen, wie Abbildung 2 zeigt.

Abb.2

Diese Daten können einfache Zahlenwerte, aber auch Media Streams (Audio|Video), 3D Modelle oder Sensordaten sein. Je nach Art des Knotens werden die Daten nach der Ankunft verarbeitet und in irgendeiner Form an einen oder mehrere verbundene Knoten weitergereicht.
Dies sind die beiden Grundeigenschaften von grafischen Programmierumgebungen: Verhaltensweisen werden programmiert indem Funktionsblöcke auf einer Arbeitsfläche arrangiert und verknüpft werden.
Ein sehr grafischer Ansatz, da der Datenfluss zwischen den Funktionsblöcken sehr gut nachvollziehbar ist. Deswegen heißen Programme von grafischen Programmierumgebungen auch „Patches“ (engl. Flicken aber auch Steckbrett oder Schalttafel).

Andrew Begel, vom MIT Media Lab, schrieb 1996 in einer Abhandlung über eine vom MIT entwickelten grafischen Programmiersprache für Handheld-Computer über die Eigenschaften sowie Vor- und Nachteile von grafischen Programmierumgebungen. Dabei hebt er hervor, dass Zusammenhänge zwischen Knoten auf einer visuellen Logik beruhen, die das Gehirn auf einer anderen, viel direkteren Ebene als bei textbasierten Programmiersprachen interpretieren kann. Während das Vokabular einer textbasierten Programmiersprache ziemlich genau bekannt sein muss, um den Datenfluss im Programm oder auch nur die Verbindungen zwischen zwei Programmfunktionen herauslesen zu können, kann aus der grafischen Verknüpfung zwischen zwei Knoten einer grafischen Programmiersprache sofort gefolgert werden, dass diese Knoten in irgendeinem Verhältnis zueinander stehen. Dieses intuitive Verständnis erleichtert die Kontrolle des Datenflusses auch bei komplexeren Programmen mit vielen Knoten.
Weiters schreibt Begel:
„Using graphical representations of objects, you can more concretely show object orientation […], eliminate annoying syntax […] and better visualize the pathways that your program is following. Parallelism can also be made more explicit […] Graphical programming can also use metaphors from real life to make programming easier. […] Graphical programming also allows for easy sharing of programs. […] Another advantage is easy browsability. Looking at a picture of a program, a user might more easily be able to discern its meaning, rather than looking at a large textual program that is composed of many code files. […] Perhaps one of the best advantages is the use of visual cues in graphical languages. Connections between objects can be made more explicit through the design and graphical representation of the constructs.”
(Begel 1996, 9f)
Bei der grafischen Repräsentation kann die lästige Syntax eliminiert, und der Datenfluss im Programm besser visualisiert werden. Metaphern aus dem real-life machen das Programmieren einfacher und
ermöglichen den leichten Austausch von Programmen zwischen Programmierern. Ein grafisch visualisiertes Programm lässt sich einfacher begreifen als ein langer Quellcode. Die visuellen Hilfen, wie Linien als Verbindungen zweier Funktionen, sind dabei wohl der größte Vorteil. So lassen sich die von Begel aufgelisteten Vorteile von grafischen Programmierumgebungen zusammenfassen.

Der nächste Absatz listet die von ihm definierten Nachteile auf:
“Some graphical languages are graphical to the core, which leads to frustration for sophisticated programmers who want to concisely express a statement that might be better represented using text. Screen real estate is also a limiting factor. This is called the ‚Deutsch Limit.’ ‚The problem with visual programming is that you can’t have more than 50 visual primitives on the screen at the same time.’ […] In order for icons and graphics to be understandable they need to be big enough to see or have a textual label. Some languages also depict function calls by lines between clusters of graphics. If there are too many functions on a ‚page’, the code becomes messy and hard to follow.“
(Begel 1996, 10)
Ein Nachteil ist laut Begel, dass die meisten grafischen Programmierumgebungen keine Programmierung über eine textbasierte Syntax erlauben, was für viele fortgeschrittene Programmierer eine Einschränkung darstellt. Für die in dieser Arbeit besprochenen Probleme reicht die grafische Programmierung jedoch aus.
Das „Deutsch Limit“ ist ein von Fred Lakin geprägter Begriff, der das Maximum an Symbolen bezeichnet, das sich in einer grafischen Programmierumgebung überschaubar darstellen lässt. Lakin und Peter Deutsch unterhielten sich über grafische Programmierumgebungen, als Deutsch plötzlich fragte:
“Well, this is all fine and well, but the problem with visual programming languages is that you can’t have more than 50 visual primitives on the screen at the same time. How are you going to write an operating system?” (Baeza-Yates, 2005)
Das Problem mit grafischen Programmierumgebungen ist also, dass nicht mehr als 50 primitive visuelle Objekte auf einem Bildschirm Platz finden, was Deutsch zu der Frage veranlasste: „Wie soll man damit ein Betriebssystem programmieren?“ Diesen Vorteil der größeren Informationsdichte von textbasierten gegenüber grafischen Programmierumgebungen führt Begel als Nachteil an. Ob es eine ähnliche Beschränkung wie das Deutsch Limit auch für textbasierte Programmierumgebungen gibt, bleibt allerdings offen. Dass bei sehr vielen Symbolen ein Programm sehr schnell unübersichtlich werden kann, ist jedoch ein ernstzunehmendes Problem, das sich allerdings durch eine Gruppierung von vielen Knoten und deren Verknüpfungen zu einem einzigen Symbol umgehen lässt. Wie dies genau funktioniert, wird in Kapitel 5|2 gezeigt und von Abbildung 10 illustriert.
Dies ist ein wichtiges Feature, das jede grafische Programmiersprache besitzen sollte: Jede Gruppe von Knoten und deren Verknüpfungen muss auch als Modul verwendet werden können, das als einfacher Knoten mit definierten Ein- und Ausgängen, beliebig oft, in unterschiedlichen Situationen, wiederverwendet werden kann. Dieses Konzept der Module oder „Unterprogramme“ findet sich selbstverständlich auch in modularen, textbasierten Programmiersprachen. Der grafische Ansatz ist allerdings weit weniger abstrakt.

 

2|2| Über vvvv

vvvv ist eine Eigenentwicklung der Designagentur meso (www.meso.net). Auf der Webseite vvvv.meso.net findet sich jedoch eine große Menge an Informationen und auch das Programm selbst zum kostenlosen Download. Von den Entwicklern wird ihre Software so beschrieben:
“vvvv is a toolkit for real time video synthesis and connecting physical devices. We use the word “synthesis” because vvvv generates or “synthesizes” video through the usage of moving graphical objects.“
(meso 2005a)
vvvv ist also ein Werkzeug für Echtzeit-Videosynthese und zum Verbinden von externen Geräten.
„Synthese“ deshalb, weil vvvv Videobilder mit Hilfe von bewegten grafischen Objekten generiert. Auf der Webpage findet sich auch eine Liste mit den Funktionen (“Core Features”) von vvvv, wobei nur die relevantesten Punkte hier besprochen werden:
1. Sophisticated objects for high level animation and problem solving
2. Simple handling of a multitude of logical objects (Spreads)
3. Runtime graphical programming for easy prototyping and testing
4. High-Speed, High-Quality, High-Resolution DirectX9.0 based rendering
5. Runs on standard windows xp platforms. DirectX9.0 graphics card recommended.
[...]
(vgl. meso 2005b)

Die große Palette an Funktionen und die einfache Handhabung von vielen Objekten gleichzeitig (Punkt eins und zwei) sind in dieser Auflistung die wichtigsten Punkte um vvvv für Grafik Design einsetzen zu können, wie in Kapitel 2|3 noch genauer erklärt.
Punkt 3 beschreibt die unterbrechungsfreie Arbeitsweise von vvvv. „Runtime“ bedeutet, dass es keinen Unterschied zwischen einem Programmier- und einem Ausführungsmodus gibt. Jede Veränderung im Programm bewirkt sofort eine Veränderung im Verhalten da die mit vvvv erstellten Programme nicht erst in eine ausführbare Datei übersetzt werden müssen um lauffähig zu sein. Es gibt nur den einen Modus in dem das Programm sowohl läuft als auch verändert werden kann. Dies vereinfacht das Erstellen und Testen („prototyping & testing”) von vvvv-Programmen erheblich.
Punkt 4 bezieht sich auf schnelles und hochqualitatives Rendering für die Darstellung auf Bildschirmen (Screen Design). Das in dieser Arbeit zu erstellende Exportmodul soll diese Aussage auf die Ausgabe von hochqualitativen und auflösungsunabhängigen Designs für Print Design erweitern. Dadurch würde vvvv nicht länger durch die gängigen Videoauflösungen (ca. 4096x4069 Pixel) eingeschränkt.
Der letzte Punkt stellt die grundsätzliche Benutzbarkeit von vvvv sicher, da es auf allen Standard-Rechnern mit Windows XP läuft und keine exotischen Anforderungen an die Hardware stellt.

Abb.3

Wie aus Abbildung 3 ersichtlich, besteht ein vvvv-Programm (Patch) aus einzelnen, mit Namen versehenen Blöcken („Knoten“ genannt) und Verbindungen zwischen diesen. Auf der Oberseite des Knotens befinden sich alle Eingänge, auf der Unterseite alle Ausgänge. Es gibt sehr einfache Knoten, wie etwa die Addition von 2 Werten (2 Eingänge, ein Ausgang) aber auch komplexe Knoten mit dutzenden Ein- und Ausgängen. Die Ein- und Ausgänge werden als „Pins“ bezeichnet. Durch diese Pins fließen alle Datenströme und auch wenn einzelne Knoten, für sich betrachtet, nicht besonders mächtig sind, lassen sich durch eine kreative Kombination dieser Knoten äußerst komplexe Vorgänge berechnen und darstellen.
Jeder Knoten, von denen es bisher über 300 verschiedene Typen gibt, bearbeitet die Daten, die von anderen Knoten übergeben werden, auf eine vorgegebene Art und Weise bevor das Ergebnis über seine Ausgänge an andere Knoten weitergereicht wird.
Einige Beispiele, für Anwendungen für die vvvv eingesetzt werden kann:
* Analyse von Daten (Bilderkennung, Audioanalyse, Sensoren…)
* Rendering und Shading von importierten oder live erstellten 3d Objekten
* Kontrolle von angeschlossenen Geräten wie Motoren, Lichtern und auch anderen Computern
* Erzeugung von komplexen Formen mit Hilfe von mathematischen Algorithmen

 

2|3| Erzeugen und manipulieren von
.... Objekten mit vvvv

Zur Generierung von Design muss ein Designwerkzeug diverse Objekte bereitstellen, die auf einer Arbeitsfläche angeordnet werden können. Dies geschieht mit vvvv nur selten per Hand, da seine große Stärke darin besteht, große Objektmengen in regelbasierte Strukturen zu verwandeln. Die darstellbaren Grundformen werden in Kapitel 3 genau beschrieben und auch Knoten, die Positionen und Aussehen von Objekten manipulieren werden nun kurz vorgestellt. Ein zentraler Begriff ist hierbei das Konzept der Spreads:
“vvvv can simultaneously handle a large count of objects, either graphical or data, with very little effort by the user. This means that it is just as easy to do an operation on a single value or on a hundred, in the same sense it is as easy to draw one object as it is to draw a whole swarm of objects. This technique is called spreading. It is somehow similar to the concept of vectors, arrays or lists in other programming languages, but it lacks most of the overhead usually associated with these constructs.” (meso 2004b)
Technisch gesehen ist ein Spread nichts weiter als eine Liste von Werten, die in vvvv von vielen Knoten generiert und von praktisch jedem Knoten verarbeitet werden kann. So kann die Rotation eines Objektes um eine Achse mit einem Wert von 0 bis 1 beschrieben werden. Ist dieser Wert 0, beträgt die Drehung 0°, bei 1 360°. Wenn jedoch statt nur einem Wert ein Spread mit zwei Werten eingegeben wird, entstehen zwei Objekte: jedes mit seiner eigenen Drehung.
Abbildung 4 zeigt ein Beispiel für einen Knoten LinearSpread (Spreads), der eine definierte Anzahl von Werten auf einer Achse liefert, die alle den selben Abstand voneinander haben. Diese Werte werden dann an einen Knoten übergeben, der Punkte in das schwarze Ausgabefenster zeichnet. Abbildung 5 zeigt einige Knoten, die vvvv zur Erzeugung von Spreads bereithält und welche Formen diese erzeugen. Dies sind nur sehr einfache Beispiele und Komplexität wird vor allem durch Verknüpfung dieser Knoten untereinander und mit anderen Knoten erreicht.

Abb. 4 & 5

Durch die individuelle Verknüpfbarkeit jedes Pins mit einem Spread entsprechenden Datentyps (d.h. Farben zu Farben, Textstrings zu Textstrings etc.), lassen sich auch mehrere verschiedene Typen von Spreads mit unterschiedlicher Größe an einen Knoten hängen.

Die mit vvvv erzeugten Objekte besitzen bestimmte Eigenschaften, welche die hochauflösende Ausgabe beeinflussen können. Darauf wird im nächsten Kapitel eingegangen.

 

<< zurück || weiter >>

0| Einleitung
1| Auflösung von Bilddateien
2| vvvv als Grafikwerkzeug
3| Zeichenbare Objekte in vvvv
4| Bildexport mit vvvv
5| Export von Bildausschnitten mit vvvv
6| Das Zusammensetzen der Teile
7| Conclusio

A| Anhänge

Zurück zur Diplom-Hauptseite

 
 

(c) by Thomas Hitthaler, ampop.net