Im Bericht zum 1. Prototypen haben wir euch die einzelnen Schichten unseres Systems vorgestellt. So sind wir auch weiter vorgegangen und haben die einzelnen Schwärme für den 2. Prototypen erweitert und optimiert.

Aus technischer Sicht ist eine der größten Neuerungen in der Schwarm-Schicht, der Nahrungskreislauf. Schwärme besitzen ein Energieniveau, das durch die Ausführung von Aktionen sinkt. Damit Schwärme überleben, müssen sie Nahrung zu sich nehmen: Eine neue Aktion zieht der aktuellen Zone im Lebensraum einen gewissen Wert vom Nahrungsmittelvorkommen ab und führt sie dem Schwarm zu. Die Nahrungsmittelvorkommen füllen sich langsam über die Zeit wieder auf. Um jedoch eine Bewegung durch den Raum zu verlassen, passiert das deutlich langsamer als der Schwarm frisst. Wird die Nahrung knapp, ist der Schwarm daher gezwungen, die Zone zu wechseln – sonst würde er verhungern.
Der Zonenwechsel war unter dem gegebenen Umstand der freien Bewegung schwierig zu realisieren: Welche Zonen befinden sich in der Nachbarschaft der aktuellen Zone? Welche erreicht man am schnellsten? Welche bietet ausreichend Nahrungsmittelvorkommen? Die Komplexität wurde verringert, indem auf die freie Bewegung verzichtet wurde. Schwärme bewegen sich fortan nur noch in maximal vier Richtungen. Da der Lebensraum ein zweidimensionales Raster ist, sind diese Richtungen oben, unten, rechts oder links, sofern die aktuelle Zone nicht im Randbereich des Rasters liegt.
Das Action-Framework, sozusagen der Motor eines jeden Schwarms, wurde um den Zufall erweitert: Schwärme fressen nun auch, wenn sie keinen großen Hunger haben. Auch der Zonenwechsel kann schon dann passieren, wenn noch genug Nahrungsmittelvorkommen vorhanden sind. Ganz zufällig ist das Verhalten jedoch nicht: Es gibt Schwellenwerte, über welche man den Zufall “steuern” kann.

Neben dem Nahrungsmittelkreislauf gab es im Lebensraum noch eine weitere wichtige Neuerung: Es können nun beliebig viele Zonen flexibel erstellt werden. Der Lebensraum passt sich also an den Klangraum an: Mit vielen Boxen (wie im Kubus des ZKMs) lässt sich ein Klangraum aufspannen, in welchem sich einzelne Quellen in ihrer Raumposition akustisch deutlicher hervorheben als mit wenigen Boxen (wie im Media-Lab der Hochschule Furtwangen). Die jeweiligen Zoneninstanzen werden automatisch erstellt und initialisiert. Bei der Initialisierung spielt wieder der gerichtete Zufall eine Rolle: Die Zonen unterscheiden sich in ihrem Zustand, beispielsweise im maximalen Nahrungsmittelvorkommen.

Eine große Neuerung wurde auch in der Soundverarbeitung implementiert. Die vorher verwendete Granularsynthese “Granular2.5″ wurde duch eine einfachere, von den Funktionen allerdings analoge, Granularsynthese auf Basis des “sogs~”-Objektes ersetzt. Die Entscheidung fiel auf sogs~, da dies eine klar strukturierte Realisierung darstellt. Damit sogs~ funktioniert wird nur ein buffer~-Objekt und die Parameter von sogs~ benötigt, was die Komplexität von Granular2.5 um ein Vielfaches vermindert. Um weitreichende Veränderungen an den Parametern für das sogs~-Objekt vorzunehmen wurden Mechanismen implementiert, die eine Änderung von jeder Stelle im System zulassen. Nachdem die Granularsynthese getauscht worden war, mussten einige Presets erstellt werden, die aus andern Teilen des Systems zur Klangkontrolle verwendet werden können.
Damit das System alle buffer~ und sogs~ richtig initialisiert, wurde die Generierung der Namen und die Initialisierung der Startwerte automatisiert und mit Startwerten versehen. Die fehlerlose Generierung der Namen gestaltete sich hier nicht so einfach wie zuerst gedacht, da jeder Name für jeden Schwarm unterschiedlich sein muss, um Konflikte vorzubeugen.

Der nächste Schritt zur automatischen Initialisierung war es, das Erstellen der Schwärme zu automatisieren. Nach Eingabe der Anzahl der Schwärme sollen diese durch ein JavaScript wie die Zonen dynamisch erstellt werden.