Das feine Beatport.com mit seiner umfangreichen Auswahl an Club-Musik hat ein Schwesterportal erhalten, diesmal ausschliesslich der Urban Sektion gewidmet: www.beatsource.com.

obenstehender Player bringt Euch eine Chartauswahl und spielt durch die Liste. ALSO SCHOEN LAUT MACHEN !!

Das feine Beatport.com mit seiner umfangreichen Auswahl an Club-Musik hat ein Schwesterportal erhalten, diesmal ausschliesslich der Urban Sektion gewidmet: www.beatsource.com.

obenstehender Player bringt Euch eine Chartauswahl und spielt durch die Liste. ALSO SCHOEN LAUT MACHEN !!

Durch Dirk’s Clubaktivitäten habe ich mich mal wieder bei den VideoMixern umgeschaut und bin auf eine unglaubliche Anzahl von Applikationen gestossen. Die häufige Verwendung von Flash als Umgebung ist auffällig, das bringt gewisse Performance Einschränkungen mit sich, hat aber den Vorteil der vorhandenen riesigen Auswahl von Video-Versatz-Stücken (kurz auch Loops) genannt, die im Flash Format vorliegen. Diese lassen sich teilweise direkt einbinden (online) sodass keinerlei Formatänderung nötig ist, ja selbst Youtube direkt zur Quelle werden kann.
Wer mehr als 5 Kanäle mischen will, das möglichst im HD Format und vielleicht auch 3D Elemente integrieren möchte, ist wohl mit einer “echten” Applikation mit DirectX Unterstützung besser bedient.Gut gefallen hat mir der vielen Features wegen, auch wegen des taffen Layouts (back to the end 90s) –> flxer

kurze vermögensliste:

• 7 channels video mixer
• HD output resolution starting from 800×600 and higher
• Supported media: .swf (full ActionScript 8 support), .flv, .mp3, .jpg, .gif, .png, .txt
• Advanced live text editor over all channels
• Http media loader over all channels
• DV-IN Analog and digital over all channels
• Full Colors and Trasform palette
• Blend options over all channels
• Effects and Analog effects as blur over all channels
• Full customizable list of wipes
• Video Sequencer over all channels
• XML Video Recorder to share or recall your livesets in a few bytes
• XML Video Player
• Broadcast Video Delivery to share in real time your liveset all over the world or to use more pc to do a live set
• Broadcast Video Player
• MIDI interface
• 3D ENGINE

Flxer Install Howto zum anschauen:

Software Listings:
http://www.softwarevj.com
http://www.audiovisualizers.com/toolshak/vjprgpix/softmain.htmVideo Loops zum selber mixen : http://www.flxer.net
gutes Beispiel: http://www.flxer.net/abusers/?skip=5&act=mdw auch gute Software: http://www.resolume.com

Grundidee
Auf der Suche nach Flaschenhälsen und Ineffizienz in einem meiner Codes fiel mir Folgendes auf:

1. es gibt eine einfach Berechnung, die immer wieder verwendet und häufig aufgerufen wird
2. Auslagerung dieser Berechnung in eine statische Methode einer Bibliothek macht also Sinn

Dies führt also zu einem Aufruf der Art Bibliothek.Mathe.degToRad (x) statt die Lösung des Problems jedes Mal aufs Neue an Ort und Stelle zu formulieren. Kurz: der Gedanke der Wiederverwertung. Aufbauend darauf der Gedanke der objektorientierten Programmierung, welche einen jede Komplexität beherrschen läßt.

Problem 1 – Instanztiefe
Mit jeder Instanztiefe wird der Aufruf brutal langsamer. Sprich wenn wir die Methode endlos von Instanz zu Kind-Instanz verlinken, dann wird diese Methode niemals fertig. (!) Das klingt jetzt trivial, aber das ist es nicht: die Instanz-Struktur beeinflußt im hohen Maße die Geschwindigkeit einer Methode. Sicher kann man an dieser Stelle dafür sorgen, daß man flach in der Instanzstuktur bleibt (egoistische Diktator-Instanz) …, aber wer will denn das? Widerspricht das nicht dem objektorientierten Streben eines jeden, der Komplexität durch Greifbarkeit und Analogien zu meistern versucht? Oder wiederverwendbare Bibliotheken anzulegen, die in Grenzfällen dafür sorgen, daß sie gar nicht nutzbar sind aufgrund ihrer Kapselung und dem damit verbundenen “Kommunikations-Overhead” …

Problem 2 – statische Fremdmethoden (Bibliotheken)
Der Geschwindigkeitseinbruch bei statischen Aufrufen schon bei Methoden 1. Ordnung ist fast unglaublich. Es macht einen Riesenunterschied, ob ich 10.000.000 Mal eine eigene Methode aufrufe oder eine statische Fremdmethode.

Ein Beispiel:
10.000.000 Mal 1 * 1 berechnen = 49 ms
10.000.000 Mal eine statische Methode aus einer Bibliothek aufrufen, die 1 * 1 berechnet = 2534 ms (um den Faktor 50 langsamer!)

Jetzt stellen wir uns die Berechnung mal komplizierter vor: in der Berechnung wird zum Beispiel die Konstante PI aus der AS3-Standardklasse Math benutzt und schon sind wir wieder eine Schritt weiter im Sumpf des Zeitverbratens …

Bedeutung
Es ist logisch, daß 1 * 1 schneller ist als pow (1, 2), weil beim Methodenaufruf noch diverse Checks durchgeführt werden, die wir in unserem trivialen Fall gar nicht benötigen. Bedeutend ist aber, das jeder Versuch der Kapselung Geschwindigkeit kostet … – und zwar in einem Maße, daß man gleich wieder geneigt ist, stupide Kilometer-Codes zu erzeugen, wo alles flach hintereinander abgearbeitet wird. Ohne Methodenaufrufe und Kapselung …

Vielleicht nichts, was einen Programmierer überraschen sollte. Mich überraschte nur, daß dies gleich 50% der kompletten Rechenzeit beansprucht. Vielleicht betrifft dies auch nur AS3 & Flash so extrem? Abhängig vom Grad der Kompilierung? Oder bin ich einfach zu objektorientiert? Vielleicht übertreibe ich auch maßlos? Entweder man programmiert also wie eine Maschine (alles hintereinander weg) oder man hat einen Kompiler, der die Nachteile der Objektorientierung ausbügeln kann. Aber ist der Kompiler zur Laufzeit wirklich noch relevant? Wenn das Programm im Speicher ist, dann gibt es doch eigentlich nichts mehr zu optimieren … – und trotzdem kleckert die Zeit weg, als würde man eine Wand dressieren wollen.

Code
Hier ein kurzer Prüfcode, der das Problem konkret macht für die, die es interessiert …
Das Ergebnis ist einfach, daß mit steigender Tiefe die Abarbeitungszeit für die gleiche Arbeit immer weiter ansteigt. Man könnte meinen, daß dies durch die Prüfung (oChild ?) passiert: sicher verbraucht dies Rechenzeit, aber nicht 25% (variiert natürlich mit dem Rechenaufwand, den eine Methode selber verursacht) mit jeder weiteren Instanztiefe. Wenn ich darüber nachdenke wohl ein eher schlechtes Beispiel, aber wer das selbst mal ausprobiert, wird sehen, wo es brennt …

Folgender Code soll das Problem veranschaulichen:

var oTest:Object = new Object ();
for (var sY:String = '', uX:Number = 0; uX < 10; uX ++) {
sY = String.fromCharCode (uX + 65);
oTest[sY] = uX;
trace (sY + " = " + uX);
}
trace ("-------- for in ----------->");
for (var sI:String in oTest) {
trace (sI + " = " + oTest[sI]);
}

Dieser Code in AS2 kompiliert führt zu folgendem Ergebnis:

A = 0
B = 1
C = 2
D = 3
E = 4
F = 5
G = 6
H = 7
I = 8
J = 9
——– for in ———–>
J = 9
I = 8
H = 7
G = 6
F = 5
E = 4
D = 3
C = 2
B = 1
A = 0

Das Erstellen von Eigenschaften fuer ein Objekt wird intern also in einem Stack geführt, wodurch die Reihenfolge erhalten bleibt (natürlich gedreht wie es bei einem Stack erwartbar ist).
Kompiliert man den selben Code in AS3, dann ist das Ergebnis:

A = 0
B = 1
C = 2
D = 3
E = 4
F = 5
G = 6
H = 7
I = 8
J = 9
——– for in ———–>
H = 7
C = 2
I = 8
D = 3
J = 9
E = 4
F = 5
A = 0
G = 6
B = 1

Welchem Schema folgt die Ausgabe der Methoden nun? Wohl keinem. Sicherlich ist dies kein großes Problem, wenn man denn weiß, daß es so ist. Und siehe da, es wird sogar in der Doku erwähnt:

Object properties are not kept in any particular order, so properties may appear in a seemingly random order.

Jemand eine Idee, warum das so sein muß? Denn nur durch das Stack-Verhalten bei der Zuweisung von Objekteigenschaften kann man die Reihenfolge bewahren. Nun muß man Arrays benutzen, die Objekte enthalten, welche wiederrum Eigenschaften haben, die abgefragt werden müssen. Um ein bestimmtes Objekt mit einer bestimmten Eigenschaft zu erhalten, ist also eine Suche über alles nötig, was bisher durch einen Direktverweis anhand des Eigenschaftsnamen möglich war. Warum muß das so sein? Wo PHP & Co das Durchlaufen von Objekteigenschaften auch in definierter Ordnung realisieren können …

Bug || Feature?

Folgender Code soll das Problem veranschaulichen:

var oTest:Object = new Object ();
for (var sY:String = '', uX:Number = 0; uX < 10; uX ++) {
sY = String.fromCharCode (uX + 65);
oTest[sY] = uX;
trace (sY + " = " + uX);
}
trace ("-------- for in ----------->");
for (var sI:String in oTest) {
trace (sI + " = " + oTest[sI]);
}

Dieser Code in AS2 kompiliert führt zu folgendem Ergebnis:

A = 0
B = 1
C = 2
D = 3
E = 4
F = 5
G = 6
H = 7
I = 8
J = 9
——– for in ———–>
J = 9
I = 8
H = 7
G = 6
F = 5
E = 4
D = 3
C = 2
B = 1
A = 0

Das Erstellen von Eigenschaften fuer ein Objekt wird intern also in einem Stack geführt, wodurch die Reihenfolge erhalten bleibt (natürlich gedreht wie es bei einem Stack erwartbar ist).
Kompiliert man den selben Code in AS3, dann ist das Ergebnis:

A = 0
B = 1
C = 2
D = 3
E = 4
F = 5
G = 6
H = 7
I = 8
J = 9
——– for in ———–>
H = 7
C = 2
I = 8
D = 3
J = 9
E = 4
F = 5
A = 0
G = 6
B = 1

Welchem Schema folgt die Ausgabe der Methoden nun? Wohl keinem. Sicherlich ist dies kein großes Problem, wenn man denn weiß, daß es so ist. Und siehe da, es wird sogar in der Doku erwähnt:

Object properties are not kept in any particular order, so properties may appear in a seemingly random order.

Jemand eine Idee, warum das so sein muß? Denn nur durch das Stack-Verhalten bei der Zuweisung von Objekteigenschaften kann man die Reihenfolge bewahren. Nun muß man Arrays benutzen, die Objekte enthalten, welche wiederrum Eigenschaften haben, die abgefragt werden müssen. Um ein bestimmtes Objekt mit einer bestimmten Eigenschaft zu erhalten, ist also eine Suche über alles nötig, was bisher durch einen Direktverweis anhand des Eigenschaftsnamen möglich war. Warum muß das so sein? Wo PHP & Co das Durchlaufen von Objekteigenschaften auch in definierter Ordnung realisieren können …

Bug || Feature?

Unter den Sammeltipps 1-3 von Thomas Dreher 1-3 werden Projekte zusammengefasst, die folgenden Kriterien genügen:

Die Projekte schaffen Stadtereignisse oder Möglichkeiten zur Stadterfahrung mit den Medien Telefon, Computer, Internet (mit schnurlosen Zugängen), Mobilfunk und digitale Lokalisierung (GPS u.a.). Alle Projekte bieten TeilnehmerInnen Möglichkeiten an, Alternativen zu wählen, eigene verbale und visuelle Beiträge einzubringen oder auf Anforderungen zu reagieren.

Einiges kennt man schon … trotzdem eine spannende und interessante Sammlung.

Interaktive Stadterfahrung mit digitalen Medien (Internet, Mobiltelefon und Locative Media)

Es gibt Menschen, denen sich das Tarifzonenmodell des VVW immer noch nicht erschließen mag. Oder anders ausgedrückt: Man steht vor einem der vielen Fahrscheinautomaten und verzweifelt an der Vielfalt der Tasten. Dabei ist es ganz einfach. Und das wird eine datenbankgestützte Applikation im Internet zeigen: Stichwort "Interaktive Tarifauskunft". JAKOTA wurde mit der Konzeption und Umsetzung beauftragt.