Core: Vom Zählen

Die Möglichkeit, in Core Variablen zu speichern und zu lesen, eröffnet neue Optionen für die GUI. Zum Beispiel wenn man per Plus-/Minus-Taste aus verschiedenen Modulationsquellen wählen möchte. Kurz: Wir bauen heute einen Zähler, und stoßen am Ende auf ein unerwartetes Problem …

Um was wird es gehen?

Es geht erneut um ein Projekt, an dem schon der bereits vorgestellte Core-Selector und der Multi-Regler beteiligt sind. In diesem Fall soll möglichst Platzsparend zwischen mehren Modulationsquellen gewechselt werden. Traditionell bietet die Primary-Ebene das List-Module an, das ausser Buttons, Ausklappmenüs und Textpanels auch die Option „Spin“ bietet: Eine Kombination aus plus/minus-Tasten und einem kleinen Textfeld für die gewählte Option. in Darstellung und Größe ist das Element nicht anpassbar und auf großen Monitoren kaum zu lesen/nutzen. Also bauen wir uns ein solches Modul selbst. Im Grund genommen ist das nur ein Zähler und somit ein Kandidat für ein Latch-Element (oder mehrere…), weshalb es sich anbietet – sollte man Latch-Elemente noch nicht kennen – noch einmal hier vorbei zu schauen.

One-Button

An einem Selector soll zwischen 8 LFOs und einer OFF-Stellung gewählt werden könne, wobei OFF=0 ist und die Werte zwischen 1 und 8 den jeweiligen LFO adressieren. Beginnen wir ganz einfach mit einem Zähler, der mit einem Button weiter geschaltet wird und nach dem erreichen des Grenzwertes wieder auf Anfang geht. Der Button selbst liefert den Wert „1“ am Eingang der Core-Cell ab.

Die Elemente, die hier zum Einsatz kommen, sind alle aus diesem Tutorial bekannt. Lediglich die Anordnung ist gewöhnungsbedürftig anders. Bisher hatten wir zuerst ein Write- und dann ein Read-Modul. Bei unserem Zähler wird das genau umgekehrt der Fall sein, da wir beim Hochzählen ja den bisherigen Inhalt (bzw. Zählerstand) berücksichtigen müssen. Deshalb steht zu Beginn, das Read-Modul, das von der eingehenden „1“ zunächst zum Auslesen seines Inhaltes getriggert wird. Der ausgelesene Wert wird im +-Modul mit der neuen „1“ zusammengezählt. Jetzt muss noch geprüft werden, ob der neue Wert innerhalb der Grenze liegt.

• Dazu läuft der neue Wert sowohl in ein Compare-Module, als auch in den nachfolgenden Router, der je nach Testergebnis den weiteren Verlauf entscheidet.
• Fällt der Test „Speicherwert > 8“ positiv aus, wird der Router angewiesen, den Speicherwert am oberen Ausgang auzugeben. Der Speicherwert triggert das Read-Modul des anderen Latch, in dem eine „0“ abgelegt ist. Die „0“ wandert dann zum Merger.
• Fällt der Test „Speicherwert > 8“ negativ aus, wandert der Speicherwert direkt zum Merger.
• der Merger leitet den jeweils zuletzt eingegangenen Wert sowohl an den Ausgang der Core-Cell, als auch in das Write-Modul unseres Zählers.

Damit schließt sich der Kreis und der Zähler ist bereit, für den nächsten Zählimpuls.

Two-Buttons

Der Aufwand, einen Button zum Runterzählen hinzuzufügen ist minimal:

Hinter dem Eingang fügen wir lediglich einen Merger hinzu, um die Werte des Plus-Buttons (+1) und des Minus-Buttons (-1) in die Schaltung zu bekommen. Danach folgt erst mal das selbe Procedere, wie vorhin: Der bestehende Speicherinhalt wird ausgelesen und zu dem neuen Wert hinzu addiert.
Zwei verschiedene Navigationsrichtungen erfordern nun aber auch zwei verschiedene Tests bezüglich der Ober- und Untergrenzen. Den ersten Test (Speicherwert > 8) kennt ihr ja schon. Hinzu kommt jetzt noch der Test „Speicherwert < 0“, der im positiven Fall den Maximalwert „8“ ausliest. Am Ende landen wieder alle Werte im Merger, der diese an den Ausgang der Core-Cell und in das Write-Modul des Zählers schreibt.  

Umbauen & Aufräumen

Was jetzt kommt, kennt ihr schon von vielen Primary-Tutorials: Wir bauen um und räumen auf. Dadurch erhöht sich die Übersichtlichkeit und die Schaltung wird leichter verständlich. 

Links oben (mit einem grünlichen Rahmen hervorgehoben) befindet sich unsere eigentliche Core-Cell nach dem Aufräumen. Bevor wir uns anschauen, warum das jetzt so komplett anders aussieht (und doch noch immer das Selbe ist), ein Wort zu den Farben der Verbindungen:
Mit Ausnahme der Button-Eingänge, sind alle weißen Verbindungen mit den runden Anschlüssen, blauen Verbindungen mit eckigen Anschlüssen gewichen. Leser des Core-Intro-Tutorials wissen: Hier wurden FloatingPoint– durch Integer-Verbindungen ersetzt. Wo keine Nachkommastellen auftreten, muss auch keine Infrastruktur dafür vorgehalten werden. Das Selbe gilt auch für die OBC-Leitungen in den Latches: Aus braunen Verbindungen mit runden Anschlüssen, wurden hier gelbe Leitungen mit eckigen Anschlüssen. Zusätzlich habe ich einige der Leitungen durch einen „QuickBus“, einer Art drahtlosen Verbindung ersetzt. Das reduziert den Drahtverhau erheblich. Auch das findet ihr im Core-Intro-Tutorial.

Und dann sind da noch diese auffälligen orangen Verbindungen – eine Farbe, die man so nicht auswählen kann. In diesem Fall liegt ein harmloser Kurzschluss vor, was an dem QuickBus „OUT“ liegt, der den Eingang des „ACC“-Macros mit dem Ausgang des „CLIP“-Macros verbindet. Befindet sich innerhalb einer solchen Schleife ein Skalar-Objekt (in unserem Fall der Addierer), ist alles gut, Reaktor fügt irgendwo in der Schleife ein Verzögerung um ein Sample platziert und mit der orangen Farbe darauf aufmerksam macht. Sind die Leitungen allerdings rot, liegt ein Fehler vor, der behoben werden muss!

Und nun zum neuen Erscheinungsbild:

• Das erste Macro (zwischen dem Eingangs-Merger und dem Addierer) habe ich mit „ACC“ für Accumulator bezeichnet. Es enthält den Zählerspeicher.
• Das zweite Macro (zwischen dem Addierer und dem Ausgang) enthält die komplette Prüflogik mit den beiten Latches, die ggf. auf den Min- oder Max-Wert springen.

Wer sich mit dem orangen Kabel unwohl fühlt, kann zu dem Workaround greifen, den man auch bei roten Kabeln anwenden kann: Das Einfügen eines „z^-1 fbk“-Macros. Das findet ih in der Core-Cell via „Rechtsklick > Library > z^-1 fbk“. Ich habe das „z^-1 fbk“-Macro hier vor das „ACC-Macro“ geschaltet, jetzt sind alle Verbindungen wieder „unverdächtig“.

Das unerwartete Problem

Ich hatte euch zu Beginn ein Problem versprochen – und hier ist es auch schon: Wenn ihr diesen Zähler z. B. in einem Synthesizer einsetzt, um wie eingangs beschrieben, 8 LFOs bestimmten Zielen zuzuordnen und wenn ihr dann auf die Idee kommt, einen Snapshot des Synthesizers zu erstellen, um die aktuellen Einstellungen später wieder abrufen zu können – dann sind die Zähler nicht mit dabei! Der Zählerstand wird schlicht nicht gespeichert! Wohingegen die Einstellungen am Core-Selector und an den Latch- und Array-Beispielen sehr wohl gespeichert werden!

Vergleichen und Testen brachte folgende Erkenntnis: Snapshots speichern lediglich den Status von Primary-Elementen! Das kann man auch daran erkennen, dass man nur Primary-Elementen in deren Einstellungen in Snapshots ein- oder aus Snapshots ausschließen kann. In beiden oben genannten

In den Beispielen werden die Werte, die den Zustand der Core-Cell bestimmten, von einem Primary-Element geliefert. Aber halt! Wird unser Zähler nicht auch von den Buttons aus der Primary-Welt versorgt? Im Prinzip ja, aber nicht mit dem eingestellten Wert (z. B. „5“ für LFO Nr. 5), sonden ledglich mit Triggern in Form von „+1“ oder „-1“. Ein Snapshot speichert bei unserem Zähler also bestenfalls den Status der Buttons, aber nicht das, was in der Core-Cell geschrieben steht.
Nachdem mir das Problem klar war und ich es ausgiebig bewundert hatte, beschloss ich, in der NI-Community auf Antwortsuche zu gehen. Kurz darauf erfuhr ich von einem ebenso brillianten wie simplen Workaround – und das irgendwann zwischen nachts und morgends! Ich bin also nicht der Einzige mit einem exotischen Timing … 

Die Lösung findet in der Primary-Ebene, vermittelst eines „Snap Value“-Modules statt. Snap Values speichern den am Eingang anliegenden Wert beim Erstellen eines Snapshots und geben ihn wieder frei, wenn ein Snapshot geladen wird.

Wichtig! „Write Thru“ in den Voreinstellungen des Snap Value muss unbedingt deaktiviert sein. Ferner ist sicherzustellen, dass der Arbeitsbereich (Range) dem der zu verarbeitenden Daten entspricht.

Zuerst legen wir in der Core-Cell einen weiteren Eingang an, der hier mit „SNP“ für „Snap“ bezeichnet ist. In der Primary-Ebene werden nun der Ausgang der Core-Cell mit dem Eingang des Snap Value und der Ausgang des Snap Value mit SNP-Eingang der Core-Cell verbunden. Alles Weitere findet in der Core-Cell statt.
Im Fall eines Snapshot-Recalls, liefert das Snap Value seinen Inhalt über den SNP-Eingang in die Core-Cell. Über den Merger nach dem Clip-Macro findet dieser Wert dann Eingang in das ACC-Macro („Out“-QuickBus). Wir erinnern uns: Das ACC-Macro enthält den Zählerspeicher. Danach ist der Zähler mit dem alten Wert vorkonfiguriert.

Das „Dup Flt“ Macro zwischen dem Merger und dem  „Out“-QuickBus verhindert redundante Informationen. Es filtert mehrere identische Werte hintereinander aus und reduziert so die Datenflut. Ihr findet den Filter mit Rechtsklick > Library > Event Proc > Dup Flt.

Und hier seht ihr den Counter in Aktion: Der Aufruf eines Snapshots aus der Liste setzt den Zähler auf den zuvor gespeicherten Wert zurück.

Downloads