Umgehen lässt sich dies mit Hilfe der der extract() Methode der Sound-Klasse. Hier wird das gesamte Frequenzspektum des Sounds augelesen und kann weiter verwendet werden. Aber es gibt einen gravierenden Unterschied bei beiden Mehtoden. Die computeSpectrum liefert von Haus aus eine schnelle Fourier Transformation mit. Hingegen liefert die extract()-Methode nur RAW-Daten zurück. Kurz zusammengefasst bedeutet dies, dass mit Hilfe der computeSpectrum die zurückgelieferten Frequenzen nach Bereich sortiert werden und bei der anderen Funktion eben nicht.

Klar könnte man hingehen und selbst eine einfache Sortierfunktion schreiben. Doch bei der etwas größeren Datenmenge die bewältigt werden muss, wird dies das Script auf jeden Fall verlangsamen. Eine Methode die verwendet werden kann zur Sortierung ist die Schnelle Fourier-Transformation, die auf der Diskreten Fourier-Transformation basiert. Aber leider gab es diese Funktion, wie gesagt, nur innerhalb der computeSepctrum() Methode.

Nun hat Eugene Zatepyakin sich die Mühe gemacht und eine Implementierung der schnellen Fourier-Transformation in ActionScript 3 geschrieben, die frei verfügbar bei Google-Code ist. Mit Hilfe dieser Klassen konnte ich, nach ein paar Tests, den SoundVisualizer mit der Funktionalität zur Sortierung der Sound Daten erweitern, ohne die oben kurz angerissenen Probleme wieder aufzureißen.

Die Implementierung ist, wie Eugene sie auch beschreibt, sehr einfach. Für die Verwendung mit Sound wird die FFT-Klasse verwendet. Des weiteren gibt es noch die FFT2D-Klasse, welche die Möglichkeit eine zweidimensionale Transforation durchzuführen bietet, wie sie etwa bei Bildern Verwendung findet. Bei der Initialisierung der Klasse mit deren init()-Methode sollte man auch nicht über 2048 Bytes gehen, da sonst wiederum die Performance leidet. Besonders ist darauf zu achten, dass die Anzahl der ausgelesenen Bytes über die extract-Methode mit der bei der init Methode übereinstimmt.

Der eingentliche Analyzer ist in der FFTSpectrumAnalyzer-Klasse. Hier wird in der initLogarithmicAverages-Methode zunächst die Mindestbandbreite angegeben und die Anzahl an Bändern, in die eine Oktave unterteilt werden soll.
Sehr wichtig ist auch die Einstellung “Little Endian” für den ByteArray, welcher die resultierenden Daten hält. Innerhalb des onSampleDataEvent-Handlers werden die ausgelesenen Bytes dann der fft-Klass mittels setStereoRAWDataByteArray(bytes) mitgegeben, um dann anschließend die forwardFFT() aufzurufen, welche die eigentliche Transformation ausführt. fftHelp.analyzeSpectrum() liefert dann den analysierten ByteArray, welcher dann weiter benutzt werden kann für alle möglichen visuellen Ausgaben, zurück. Noch ist hier der Sound selbst noch nicht ausgegeben. Dafür müssen die Bytes zurück transformiert werden über fft.inverseFFT(). Nach dem Zurücksetzen der Position innerhalb des BytesArrays können nun die SoundBytes an event.data zur Ausgabe übergeben werden. Den genauen Ablauf der Funktionen kann man auch auf Google Code nachlesen. Hier hat Eugene zwei Beispielscripts eingefügt. Und als anschauliches Beispiel für die Verwendung seiner Bibliothek einfach den zeroseven SoundVisualizer anschauen. Hier ist im letzten Reiter eine weitere Checkbox, in der man angeben kann, ob die Daten sortiert (FFT) oder unsortiert (RAW) verwendet werden sollen.

Links:

• Vergleich computeSpectrum und extract: http://labs.zeroseven.de/development/actionscript-development/soundmixer-computespectrum-vs-sound-extract-2/
• Wikipediaeintrag zur Schnellen Fourier-Transformation: http://de.wikipedia.org/wiki/Schnelle_Fourier-Transformation
• Wikipediaeintrag zur Diskreten Fourier-Transformation: http://de.wikipedia.org/wiki/Diskrete_Fourier-Transformation
• Eugenes Blog zu ASFFT: http://blog.inspirit.ru/?p=405
• Eugenes Blog zu Update von ASFFT: http://blog.inspirit.ru/?p=410
• Google Code Seite: http://code.google.com/p/in-spirit/wiki/ASFFT
• Beispiel zur Verwendung von ASFFT: http://visualizer.zeroseven.de

Native Installers
AIR Applikationen können nicht nur als *.air Dateien exportiert und weitergegeben werden, sondern auch als “Native Installer” also *.exe für Windows bzw. *.dmg für MacOS. Dies ist die Voraussetzung um mit Systemprozessen kommunizieren zu können. Ein weiterer Vorteil von Native Installers ist, dass die AIR Runtime mit der Applikation installiert wird, falls diese noch nicht auf dem System des Benutzers verfügbar ist und eine Internetverbindung besteht. Falls der Benutzer nicht mir dem Internet verbunden ist, kommt wenigstens eine Meldung man solle sich doch bitte die aktuelle AIR runtime von der Adobe Seite herunterladen. Weiterhin gibt es die Möglichkeit die AIR Runtime zum Beispiel auf einer CD/DVD mitzuliefern, dafür ist allerdings eine Re-Destributable Lizenz von Adobe nötig, siehe Blogeintrag von Mike Chambers.

Erstellen eines Native Installers
Da man aus FlashBuilder standardmäßig nur *.air Files exportieren kann müssen hier auf die Konsole zurückgreifen. Das Packagingprogramm hierfür heißt ADT und befindet sich im bin Ordner des AIR sdks. Es gibt grundsätzlich zwei verschiedene Arten Native Installers zu erstellen:

• aus dem Sourcecode eines AIR Projekts
• aus einer bereits bestehenden AIR Datei

Dieser Aufruf erstellt eine Anwendung mit Native Installer für MacOS aus den Quelldaten der Applikation.

adt -package -storetype pkcs12 -keystore myCert.pfx -target native myApp.dmg main-app.xml main.swf

Folgender Aufruf erstellt eine Anwendung mit Native Installer für MacOS aus einer AIR Datei

adt -package -target native myApp.dmg myApp.air

Um einen Native Installer für Windows zu erstellen wird einfach anstatt myApp.dmg myApp.exe verwendet. Einschränkung: Native Installers können immer nur für das Betriebssystem erstellt werden das gerade genutzt wird. Will mal also ein *.exe für Windows erstellen muss ADT unter Windows aufgerufen werden.

Mehr Infos dazu auf der Adobe Hilfe.

NativeProcess API
Die NativeProcess Klasse bietet die Möglichkeit mit einem Systemprozess zu interagieren. Über die Funktionen start(info:NativeProcessStartupInfo):void und exit(force:Boolean = false):void werden Prozesse gestartet und beendet. Über die Eigenschaften running, standardError, standardInput und standardOutput kann der Prozess überwacht werden.

Der Funktion start() wird eine NativeProcessStartupInfo Objekt übergeben das Informationen zum Prozess enthält der gestartet werden soll. Die Eigenschaft executable muss eine Referenz auf die Datei enthalten die gestartet werden soll und über arguments kann eine Vector von Strings
mit Parametern angegeben werden.

var file = new File('/Applications/Firefox.app/Contents/MacOS/firefox-bin');
var nativeProcessStartupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
nativeProcessStartupInfo.executable = file;
var process:NativeProcess = new NativeProcess();
process.start(nativeProcessStartupInfo);

Dies ist nur ein kleines Beispiel das natürlich beliebig erweiter werden kann. Schön ist auf jeden Fall, dass sich dadurch ganz neue Möglichkeiten für AIR Applikationen auftun. Der große Nachteil von AIR bleibt aber weiterhin, dass die AIR Runtime auf jeden Fall installiert werden muss, es ist also zum Beispiel kein Starten von CD möglich.

Links und weitere Beispiele:

• Adobe DevNet: Interacting with a native process
• Adobe Help: Packaging an AIR application in a native installer
• Mike Chambers: Redistributing the Adobe AIR Runtime Installer
• Adobe: Distribute Adobe® AIR® Runtime

Die Voraussetzung ist natürlich eine entsprechende Hardware. Um die Multitouchfähigkeit testen zu können ist entweder ein multitouchfähiger Touchscreen oder ein Touchpad wie zum Beispiel beim MacBook Pro erforderlich. Außerdem kommt es darauf an wie viele Touchpunkte das Eingabegerät unterstützt, von Flash Seite gib es hier keine Einschränkungen.

Doch wie sieht das Ganze in ActionScript aus? Die Multitouchfähigkeit basiert hauptsächlich auf folgenden Events

• flash.events.TouchEvent
• flash.events.GestureEvent
• flash.events.TransformGestureEvent

Multitouch Input Mode
Es gibt zwei Multitouch Modi MultitouchInputMode.TOUCH_POINT und MultitouchInputMode.GESTURE. Um Multitouch Events verwenden zu können, muss die statische Variable inputMode der Multitouch Klasse gesetzt werden: Multitouch.inputMode = MultitouchInputMode.GESTURE;. Wird der Modus “touchPoint” gewählt werden TouchEvents dispatched, wird der modus “gesture” gewählt werden GestureEvents und TransformGestureEvents dispatched. Anhand der TouchPoint Events können die verschiedenen Berührungspunkte ausgelesen und verarbeitet werden.
In diesem Eintrag will ich aber auf die Gestures eingehen. Es werden die vom IPhone bekannten Gesten für zoomen, drehen und wischen (mit zwei oder drei Fingern) und der tab mit zwei Fingern unterstützt.

• TransformGestureEvent.GESTURE_ZOOM
• TransformGestureEvent.GESTURE_ROTATE
• TransformGestureEvent.GESTURE_PAN (2 Finger)
• TransformGestureEvent.GESTURE_SWIPE (3 Finger)
• GestureEvent.GESTURE_TWO_FINGER_TAP

Test Anwendung
Um die Funktionen zu testen habe ich eine einfach AIR Anwendung gemacht in der Bild über die Gesures gedreht, gezoomt, und bewegt werden kann. Mein Test AIR App kann hier heruntergeladen werden, es wird allerdings die AIR 2.0beta Runtime benötigt und natürlich ein Eingabegerät das Multitouch unterstützt.

Anwendung auf Propeller
Mein Kollege Alex hat gestern einen Beitrag zu seinem Propeller-Experiment geschrieben, diesen habe ich genommen und mit Multitouchfähigkeiten ausgestattet. Über die Geste Rotation kann der Propeller rotiert werden, über zoom kann gezoomt werden und das Wischen mit 3 Fingern wechelt die Farbe. Hier gibts die AIR Applikation, viel Spaß beim ausprobieren.

In Gesprächen entwickelte sich dann die Idee, eine Plattform zu schaffen, welche Sounds eines Users analysiert, visualisiert und später dann ein Bild zum Download der aktuellen Visualisierung anbietet. Ein einfacher Screenshot wäre hier möglich gewesen und die Bilder jpg- oder png-kodiert zum download anzubieten. Aber solche Bilder sind sehr klein und können dann z.B. nicht als Plakat gedruckt werden. Also suchte ich nach einer anderen Lösung. SVG wäre eine Variante gewesen. Dazu hatte ich auch schon die Grundzüge eines Exporters geschrieben, der die XML-Struktur aus Graphics-Elementen in ActionScript bilden kann. Hiermit wäre zumindest die freie Skalierbarkeit des Plakates gewährleistet. Etwa zu dieser Zeit bin ich dann auf die Bibliothek AlivePDF von Thibault Imbert gestoßen und hab auch hier erste Versuche betrieben (siehe labs-Eintrag dazu). Und nach ein paar Tests war klar, das ist der Weg, den ich für den Visualizer gehen muss.

Aber der SVG Exporter war nicht ganz gestorben. Das Logging-Tool das im Hintergrund mitläuft ist noch immer Teil der Anwendung. Einfach gesagt, merkt sich dass Tool die Spezifikationen aller Elemente. Dieses Log nutze ich jetzt beim PDF-Export zum Erstellen der Elemente des PDFs.

Anfangs mit random-Farben ausgestattet, brachte Sebastian die Idee ins Spiel Kuler für Farbprofile zu nutzen. Also erfolgte mit Hilfe des Adobe Syndication Packages das Laden und Auslesen des Feeds der 20 beliebtesten Farben von Kuler. Dennoch hat auch der User die Möglichkeit eigene Farben zu verwenden. Ein eigenes ColorPicker-Tool kommt hier zum Einsatz.

Auch die Formen wurden vielfältiger. Anfangs nur mit Kreisen gezeichnet, kamen weitere Grundformen und Polygone hinzu. Auch die Möglichkeiten der Ausgabe erweiterten sich, je mehr ich mich darin “reingetestet” hatte. Eigene Formate entstanden sowie Hilfstools zur Umrechnung von Pixelwerten aus dem Logger hin zu Zoll und Millimeter. Die Oberfläche bekam ein schickes Design verpasst und weitere Funktionen spendiert, um dem User mehr Möglichkeiten zu geben sein eigenes Plakat zu erstellen.

Ein Problem das es zudem zu bewältigen galt, waren die Probleme der SoundMixer.computeSpectrum() Methode. An sich eine tolle Sache und auch die Möglichkeit den ByteArray als RAW-Daten oder als Daten mit einer schnellen Fourier-Transformation zu erhalten ist sehr viel wert. Aber der SoundMixer hat einen entscheidenden Nachteil. Er ist eine globale Klasse und greift somit auf alle möglichen Sounds zu. Das führte dazu, dass der Visualizer zum Beispiel versucht auf die Sounds eines Videos von YouTube zuzugreifen, wenn dieses in einem anderen Browser Tab oder Fenster läuft. Und ganz klar entsteht dabei ein Sandbox-Problem. Umgangen habe ich diese Problematik mit Hilfe der Sound.extract() Methode. Sie liefert den ByteArray gleich zu Anfang zurück und zwar für den gesamten Audiostream. Daher erfolgt hier die Abtastung anders und etwas komplizierter als bei der computeSpectrum() Methode. Aber auch hierzu gibt es schon einen labs-Eintrag von mir (Link).

So entwickelte sich mit der Zeit eine Oberfläche, die für mich zum einen als Versuchs- und Testprojekt diente, aber letztendlich ein Tool darstellt, das ein breites Spektrum der Flashfunktionen abdeckt und auch zeigt was man performancetechnisch mit Flash so anstellen kann.

Aber nun nicht länger lesen sondern einfach ausprobieren:
http://visualizer.zeroseven.de/

Des weiteren möchte ich noch Thibault Imbert für seine Mühe und Arbeit bei AlivePDF danken, ein wirklich hammerkrasses Tool! Ebenso Sascha Wolter für seinen SystemManager, den Junges von Greensock für TweenLite & TweenMax, den Entwicklern des De MonsterDebugger und denen von pixelbreaker.com für das MacMouseWheel.

www.alivepdf.org
www.wolter.biz
www.greensock.com
www.pixelbreaker.com
www.adobe.com
www.demonsters.nl

Baut man diese Animation weiter aus, kann man die Überlagerungen und Alpha-Werte dazu nutzen, einen DisplacementMapfilter zu verwenden. Durch dessen Einsatz bekommt die Animation einen fluiden Eindruck.

Ohne eine serverseitige Programmierung geht hier nichts. Zum Beispiel Java oder PHP müssen zur Hilfe genommen werden. Ärgerlich und vor allem umständlich wenn es darum geht, das PDF und die auf dem Screen enthaltenen Inhalte zu synchronisieren. Es muss hier nun überlegt werden, welche Informationen sende ich wie an den Server, um das Ergebnis zu reproduzieren, welches clientseitig eigentlich schon da ist. Wie gesagt sehr umständlich.

Thibault Imbert hat hier einen Ansatz geschaffen, der es Flash und Flex Entwicklern ermöglicht, PDFs clientseitig zu generieren. Nur ein kleines PHP Script ist noch nötig, um das PDF fertig zu stellen. Dieses ist im Package schon enthalten und fertig zum nutzen. AlivePDF heißt dieses Package und ist, was die Entwicklergemeinde freut, open source. Und die Handhabung des ganzen ist denkbar einfach.

var pdf:PDF = new PDF(orientation:String, unit:String, pageSize:Object=null, rotation:int=0);

Mit dieser Zeile ist das Grundgerüst der PDF schon erstellt, wobei orientation Hoch- oder Querformat definiert, unit das Maß in dem das PDF angelegt wird (Pixel, mm, ..), pageSize definiert die Seitengrößen (A4, A3, usw.) und letztlich rotation die Drehung der Inhalte als letzten Parameter. Für die ersten drei gibt es Klassen mit statischen Variablen zur Definition. Interessant ist hier die Size-Klasse, die sich recht leicht um weitere Seitengrößen erweitern lässt.

pdf.setDisplayMode (zoom:String = "FullWidth", layout:String = "SinglePage", mode:String = "UseNone");

Hiermit lässt sich definieren wie die Seite selbst dargestellt werden soll. Mit zoom zum Beispiel ist die Vergößerung der Anzeige definiert oder mit layout das Layout des Dokumentes selbst. Einfache Seite, eine Spalte oder zwei Spalten links sind mögliche Parameter.

pdf.addPage(page:Page = null);

Hiermit wird eine Seite im PDF hinzugefügt, der dann schlussendlich die Inhalte hinzugefügt werden. Als Parameter ist es möglich ein Page-Objekt mitzugeben, welches wiederum andere Größen- und Formatausrichtungen haben kann, als das PDF selbst. Damit können im PDF auch unterschiedliche Seitengrößen erzeugt werden, je nach dem was gerade benötigt wird.

Nun ist die erste Seite erzeugt und lässt sich mit Inhalten befüllen. Dabei gibt es Funktionen zur allgemeinen Seitendefinition (z.B. setRightMargin) oder eben um Inhalte einzufügen. Dabei können Grafikobjekte wie Kreise, Flächen oder Pfade erzeugt werden, wobei hier die sehr große Ähnlichkeit zu den Graphics-Funktionen den Workflow von vorne herein einfach gestalten. Aber auch Texte oder Bilder können eingefügt werden. Aber auf all diese Funktionen nun einzugehen, würde jeden Rahmen sprengen.

Um nun aus dem PDF-Objekt ein richtiges PDF zu machen, wird nun das create.php aus dem Package benötigt. An diese sendet man den erzeugten ByteCode und das php-File sagt dem ByteStream: “Du bist ein PDF und jetzt kann man dich runterladen.” Das war es auch schon. Wie gesagt sehr einfach gehalten.

Um es kurz zusammen zu fassen, es gibt eine unglaubliche Masse an Funktionen und Einstellungsmöglichkeiten, dabei handelt es sich bei der aktuellen Version von AlivePDF um eine Alpha-Version und bisher ist mir noch kein Fehler untergekommen. Also hat Thibault ganze Arbeit geleistet! Vieles ist noch immer etwas experimentell, da die Dokumentation noch nicht sehr weit gediehen ist, aber bei einer Alpha Version ist dies glaub zu verkraften. Insgesamt also schon jetzt ein sehr gelungenes Werk.

Noch ein paar Links zum Thema:
www.alivepdf.org
Dokumentation
Download

Und drei kleine Videotutorials:
Getting Started
Flex & AlivePDF
Introduction on Adobe TV

Bei Flash und Flex Anwendungen war hier bisher Schluss. Die Seite wird aufgerufen, das SWF geladen und dies war der letzte Aufruf des Trackers, wenn der User sich ab nun innerhalb der SWF bewegt. Ein Zustand der jeden Marketingmenschen zur Verzweiflung treibt.

public var gaTracker:GATracker;

Der hier aufgeführte GATracker ist der Kern des com.google.analytics – Packages. Es enthält alle notwendigen Klassen um Google Analytics auf einer Flash oder Flex Anwendung anzusprechen. Dazu wird wie oben beschrieben eine Variable der GATracker erstellt. Über diese läuft dann die gesamte Kommunikation.
Nur wird bei applicationComplete (Flex) oder eben im Konstruktor (Flash) die oben beschriebene Variable instanziiert. Dazu müssen verschiedene Parameter mitgegeben werden damit die Kommunikation zu Google Analytics auch so funktioniert wie es soll. Wenn die Flash oder Flex Anwendung und auf dem MVC-Model basiert, bietet es sich zu dem an, die Tracker Variable im Model anzulegen. So lässt sie sich von überall nutzen.

Um nun aber auf die Parameter der Instanziierung einzugehen:

gaTracker = new GATracker(this, 'XX-XXXXXXX-X', TrackerMode.AS3, true);

Dies beschreebt die Instanziierung der GATrackers via ActionScript. Wobei ‘this’ das parent DisplayObject darstellt. Ich denke dass es sinnvoll ist, mit this auf root der SWF zu verweisen. Als nächstes kommt der Google Analytics-Account. Diese ID einfach hier als String eintragen. Nun wird es interessanter. Der dritte Parameter beschreibt den TrackerMode ausgehened von der App. Dabei gibt es zwei Modi: TrackerMode.AS3 oder TrackerMode.BRIDGE. Dabei lässt es sich recht einfach unterscheiden, welchen Modus man verwenden soll. Der BRIDGE Modus wird genutzt, wenn in der HTML-Seite, in welche das SWF eingebettet wird, bereits ein Google Analytics-Tracker vorhanden ist. Dieser Tracker wird im BRIDGE-Modus über External-Interface angesprochen und dann auch für die Kommunikation zu Google Analytics genutzt. Der AS3-Modus wird hingegen genutzt, wenn kein Tracker in der HTML-Seite vorhanden ist. Der letzte Parameter sagt aus, ob der Tracker im Debug-Modus laufen soll oder nicht. Dies ist besonders interessant während der Entwicklung um zu überwachen welche Informationen gesendet werden.

Für die Flex-MXML Syntax gibt es einen eigenen Tag zum implementieren:



Hier verhalten sich die Attribute wie oben beschrieben, nur eben das es keinen Verweis auf das DisplayObject gibt, da der Tag sowieso schon in einem liegt. Hinzu kommt aber eine ID um den Tracker aufrufen zu können.

Wie wird nun die Userinteraktion an Google Analytics übertragen? Um es vorweg zu sagen, man kann als Entwickler definieren was alles getrackt werden soll und wie es ankommt. So ließe sich zum Beispiel vom MouseClick bis hin zur kleinsten Mausbewegung alles mittracken. Das dies (meist) nicht sinnvoll ist, ist klar aber es zeigt auf, welche Möglichkeiten es gibt.

Es gibt zwei Aufrufe zum senden von Informationen. trackPageview und trackEvent. Mit dem ersten wird GoogleAnalytics eine Information übermittelt, entsprechend dazu, wenn der User auf eine andere Seite navigieren würde:

gaTracker.trackPageview("/aFakePage");

Dabei wird die “neue” Verzeichnisstruktur in der sich der User befindet, an Google übermittelt. Eben so als hätte sich die URL verändert.
Die zweite Möglichkeit dient dazu interne Events der RIA zu übermitteln, die nicht von der Usernavigation ausgehen.

gaTracker.trackEvent('category', 'action', 'label', [value:optional]);

Hier entspricht die “category” der Gruppe zu der der Event zugeordnet werden soll und die “action” ist inhaltlich an die “categorie” gebunden. Das heißt, wenn es sich um Events handelt, die beispielsweise von einer Videosteuerung ausgehen, ist es sinnvoll die “category” ‘video’ zu nennen und the “actions” wären zum Beispiel “play”, “pause” und so weiter. Das “label” bietet die Möglichkeit weitere Informationen zum category-action-Paar zu übermitteln, ebenso wie über “value“, wobei es sich hier um einen positiven Integer handeln muss.

Insgesamt eine sehr einfache Variante, um aus einem SWF heraus zu Google Analytics zu kommunizieren. Letztendlich würden sorgar zwei Zeile Code ausreichen, um den Datenaustausch zu erstellen. Das Package gibt es im übrigen zum Download bei GoogleCode.

Links:
http://code.google.com/p/gaforflash/
http://www.insideria.com/2009/02/using-google-analytics-within.html