REAKTOR 6

[MvKeinen]

WoW.... durch das table Framework könnte sich bei mir einiges vereinfachen. Und Event ausgänge in den unified Corezellen! Genial!

[herw]

core )) , ja endlich wurde auf diesem Gebiet etwas getan.
Nun ich bin ja überzeugter Core-Anhänger, meistens euphorisch und vielleicht etwas einseitig im Urteil. Also bitte nur die neutralen Kommentare von mir beachten
Dass daran gearbeitet wurde, wusste ich schon sehr lange, aber es hat dann doch ein, zwei Jahre gedauert, bis klar war, dass es auch wirklich weitergeht. Als Nicht-Eingeweihter habe ich natürlich auf jede kleinste Äußerung im Betatester-Forum (zum Melden von Bugs) geachtet. Manchmal erkennt man an der Art der Bugs, dass etwas läuft, aber nichts genaues weiß man nie.

Nun, als Alpha-Betatester kann man zwar Wünsche äußern, ob diese auch berücksichtigt werden, ist aber nie klar. Ich hätte mir gewünscht, dass es in Core eine Iteration und Ordermodule und auch ein Voicemanagement. Nun ja das wurde nicht erfüllt.

Die erste Entscheidung war sicherlich, ob ein völlig neues Produkt entsteht oder auf R5 aufgebaut wird. Sicherlich ist die Entscheidung auf R5 aufzubauen von NI Seite aus richtig, da man ja auf die bisherige Library zurückgreifen kann und das möchte man natürlich nicht missen.

Vorweg: alle R5-Ensemble laufen auch in R6. Wer also nicht vorhat, neue R6-Features in sein Ensemble einzubauen, belässt es dabei. Will man sein Ensemble durch R6 erweitern, dann muss man einwenig ändern; das hält sich aber in Grenzen.

Ich habe mal Lazerbass in R5 und R6 geladen:

bild_29.jpg

R5 verbaucht für den ersten snapshot 7,4%, R6 nur 6,3%. Ob das nun ein Zeichen ist, dass R6 effektiver ist oder die CPU-Leistung nur anders berechnet wird, mag dahingestellt sein. In der Regel, kann man auf einem MacBookPro (late 2013) beobachten, dass bei einem 30%-igen Ensemble R6 etwa 1% mehr verbraucht. Ob das nun einfach an der Übertragung aus R5 liegt kann ich nicht beurteilen.
PC-User berichten allerdings von höherem CPU-Verbrauch. Zu meinem Erstaunen stellt sich heraus, dass MacBookPro wohl ein richtiges Audio-Monster ist, während PCs generell höheren Verbrauch haben. Nun gravierend ist das nicht, da NI sich bemüht, für alle Ensembles 35% als Obergrenze anzustreben.

Wir schauen nun in eine Corecell:

bild_30.jpg

Abgesehen davon, dass in Core die Kabel ebenfalls flexibel sind, weisen sie mehr Farben auf, um zu kennzeichnen, welche Art Datenfluss herrscht.

Alle CoreCells, die in einem R5-Ensemble stecken, haben oben links ein eigentümliches neues Makro

bild_31.jpg

Es stellt sicher, dass R6 eine R5-Datei richtig behandelt.

[herw]

Zunächst fällt auf, dass die Ränder gestrichelt sind: das Makro ist „non solid”.

bild_32.jpg

Im Core Manual findet man auf der Seite 104 die Erläuterung. Man benötigt „non solid” Strukturen in Feedback-Schleifen zum Beispiel in Filtern, um einen loop aufzulösen. Letztlich basiert es auf memory-Schreib- und Lesemodulen und legen damit eindeutig die Verarbeitungsreihenfolge fest.

Das Einfügen dieses Makros erfolgt ohne Rücksicht, ob es sich um eine ehemalige Event-CoreCell oder eine Audio-Corecell handelt.

Übrigens liefert die SR.C keinen Initialisierungsevent mehr. Das vereinfacht den Initialisierungsprozess sehr. Wenn man den ehemaligen Intialisierungsevent nicht benutzt hat, ist das ohne Belang.

Wir öffnen das Makro:

erstaunlich wenig: ein Bundle Pack

bild_33.jpg

Wie der Name schon sagt, werden verschiedene „Fasern” (fibers) zu einem Bündel zusammengepackt. Dies geschieht sehr einfach: man ergänzt Eingänge mit sinnvollen Namen und verbindet es mit dem Bundleausgang - einfacher geht es nicht.
Das Bündel hat in der Regel keinen Namen und kann alles Mögliche übertragen: Events und Audiosignale. Hier habe ich mal ein einfaches Beispiel konstruiert:

bild_34.jpg

Ich habe eine Corecell erzeugt, die sowohl Event- als auch Audiosignale empfängt. Möchte ich nun diese Signale, oder auch nur einige davon, in ein oder mehrere Makros übertragen, dann benötige ich nur ein Kabel, das Bundle.
Das Makro Bundle Pack akzeptiert nicht nur event- und Audio-Signale, sondern auch andere Bundles. D.h. man kann diese sogar verschachteln.

bild_35.jpg

Das Entpacken geschieht genauso einfach; siehe die Strukturen der beiden Makros 1 und 2:

bild_36.jpg

[herw]

nun zurück zu diesem mysteriösem R5-legacy makro:

bild_37.jpg

Im Gegensatz zum letzten Bild, ist dies die Einsetzung in eine ehemalige R5-audio-corecell.
Man erkennt, dass nun auch der oberste (clock-) Eingang besetzt ist. Der merger stellt das alte Initialisierungsverhalten sicher; in R6 gibt es für die SR-Clock kein Initialisierungsevent mehr, daher die Simulation durch den unbesetzten unteren merge-Eingang. Wenn man den Initialisierungs-Event nie benutzt hat, kann man den merger auch weglassen.
Der obere merger-Eingang ist durch einen so genannten Pickup besetzt. Pickups entsprechen den globalen Variablen in normalen Programmiersprachen. Die Syntax lautet <name>.<fiber-name>.
Hier ist eine Besonderheit: der Name beginnt mit zwei Punkten. Der erste Punkt ist der Name! Was soll das? Nun, zwischen der core- und primary-Ebene befindet sich noch eine unsichtbare (!) Zwischenebene, die die Pickups SR.C und SR.R liefert. Das ist nur am Anfang verwirrend, wenn man es weiß, ist das kein Problem.

Die Systematik dieser Pickups möchte ich an einem Beispiel erläutern (nächste Post).
aber zunächst hilft ein

[herw]

Zunächst habe ich einen ganz einfachen Synth gebastelt, auch für diejenigen die noch Hemmungen haben, core zu nutzen - bis auf die Panelelemente alles in einer einzigen Corecell.

bild_38.jpg

bild_39.jpg

bild_40.jpg

Der Aufbau ist sehr einfach: Wir sehen die event-Eingänge der Regler, innen den multiwave-Oszillator, einen Filter, ADSR-Generator, einen Modultions-LFO und den Audio-Ausgang. Vorsicht Falle: fügt man einen Ausgang zu einer Corecell, dann handelt es sich zunächst nur um einen Eventausgang (gelber Punkt). Diesen muss man in den Properties auf Audio (weißer Punkt) umschalten.

bild_41.jpg

und damit keiner selbst basteln muss, hier das Ensemble:

Beispiel_1.ens.zip

[Quietschboy]

Schöner Einstieg, Herwig

[herw]

Schöner Einstieg, Herwig

danke - ja, es macht auch sehr viel Spaß, da ich selbst beim Schreiben immer mehr verstehe und die Eindrücke sortiere.

[herw]

Was sind das für komische Häkchen mit SR vor den Bundle-Eingängen?

bild_42.jpg

Das sind sogenannte Pickups, genauer hier der Standard Pickup SR.
SR haben wir doch schon gesehen? ja klar hier:

bild_43.jpg

an das Bundle wurde ein Distributor angehängt; dieser definiert quasi eine globale Variable, die in dem gesamten Makro (hier der gesamten Corecell), und zwar nicht nur wie bei den Quickbussen nur auf derselben Ebene, sondern auch in allen Untermakros abrufbar ist!
Bei Bundles wird nur der Name (hier z.B.) SR angegeben, oder wenn man nur an einem ganz bestimmten Aspekt interessiert ist zum Beispiel der Samplerate direkt mit SR.R.
Dies gab es in R5 auch schon, aber eben nur für die SampleRate. Jetzt können wir aber solche Pickups selbst definieren.
Ich verändere in den nächsten Posts mal das Beispiel 1 damit das Prinzip klar wird.

Man könnte nun noch fragen, warum man die Bundles dann nicht direkt in den Makros selbst mit Pickup abfragt, sondern extra von außen zuführt? Nun da gibt es noch spaßige Sachen, die man mit Bundles insbesondere der Clock anstellen kann: es gibt so genannte gated clocks, mit den man die Clock an- und abschalten kann und damit ungenutzte Ressourcen einspart, oder man verändert die SR.-Frequenz durch Überschreiben eines Bundles usw.. Damit man flexibel bleiben kann, gibt es diesen Außenanschluss.

Etwas darf man nicht vergessen: Distributoren sind toll, aber sie verstecken auch den Signalfluss. Also nur mit Vorsicht und bei wenigen wirklich wichtigen Signalen (Globale Clocks und Events) verwenden. Ansonsten sind direkte Bundleverbindungen viel deutlicher!

[herw]

Als erste Maßnahme fass ich alle Panel-Quellen zu einem Bundle zusammen:

bild_44.jpg

Ich benötige zehn Eingänge, denen ich die entsprechenden Namen gebe:

bild_45.jpg

Nun muss ich die entsprechenden Fasern wieder abrufen. Damit es sehr übersichtich wird, packe ich zusammengehörige Teile der Struktur in Makros, z.B. den Oszillator:

bild_46.jpg

innen sieht es dann so aus:

bild_47.jpg

Ich greife nur die Fasern auf, die für das Makro relevant sind.

[herw]

Das mache ich nun für alle anderen Strukturteil entsprechend. Die Namen der Pickups müssen genau mit den definierten Pickups übereinstimmen, sonst meckert REAKTOR sofort:

bild_48.jpg

Hier fehlte zum Beispiel der Buchstabe „u”.
Dann sieht das ganze schon sehr übersichtlich aus:

bild_49.jpg

Das i-Tüpflechen ist dann ein Quickbus für das Bundle:

bild_50.jpg

So sieht es in meinen Augen optimal aus; der Signalfluss ist noch erkennbar und alles sieht aufgeräumt aus.

Hier ist noch das Ensemble für Faule:

Beispiel_2.ens.zip

Wer noch etwas produktiv sein möchte, kann ja mal einen Regler für die Resonanz des Filters einfügen

[herw]

Übertrieben und unübersichtlich finde ich dagegen jetzt, wenn ich noch einen Distributor benutzen würde:

bild_53.jpg

bild_51.jpg

bild_52.jpg

oder völlig abgefahren der Direktzugriff auf einzelne Fasern:

bild_54.jpg

Das ist nun Unübersichtlichkeit pur. Wer noch unser „Genie” John Nowak aus dem englischsprachigen Forum kennt, könnte sich vorstellen, dass er mehrfach verschachtelte Bundles benutzt und über Distributoren teilt und splittet etc. pp

[herw]

Was gibt es sonst auf core-Ebene?

bild_55.jpg

Es gibt jetzt event-Ausgänge! Nun das gab es vorher auch schon, aber entweder es handelte sich um eine Event-CoreCell, die sowohl Event-Ein- und Ausgänge besaß, oder um eine audio-CoreCell die nur Audioausgänge zuließ.
D.h. aber nicht, dass eine Audio_CoreCell Events„verschluckte”. Nein sie waren nur schwer zugänglich und wurden zwischen den AudioTicks gesendet.
Durch die Reduzierung auf eine einzige Sorte von CoreCells wird nun der Zugriff völlig vereinfacht: entweder man möchte nur die Events, oder die AudioEvents oder beide aussenden. Ein lang gehegter Wunsch wurde erfüllt.
Dadurch könne zum Beispiel Event-Informationen (zum Beispiel ein Bus aus partials framework) zwischen verschiedenen CoreCells ausgetauscht oder weitergeleitet werden.
Wie könnte man das noch anwenden? Nun der oben erwähnte Decay/Gate-Block ist ein Beispiel: aus einer Audio-Verarbeitung wird ein Gate-Event abgeleitet und als isolierter Event ausgegeben.

[herw]

Was gibt es sonst noch Neues?
Viele Filter in verschiedenen Arten und das Wesentliche die TransferFuntionen ...

bild_56.jpg

... und das ZDF-Toolkit:

bild_57.jpg

Mehr kann ich dazu nicht sagen, da ich die Ausführungen von Vadim (siehe download-Seite von NI) zur Gestaltung von Filtern nicht verstehe.
Ich warte darauf, dass mir das jemand erklärt ?!

[herw]

Was ich allerdings verstehe, sind zum Beispiel die angebotenen Effekte und die Oszillatoren:

bild_58.jpg

bild_59.jpg

Die Oszillatoren wurden neu gestaltet und können synchronisiert werden.

[herw]

Es gibt noch andere interessante Neuerungen; ich empfehle einen ausgiebigen Blick in die Library und natürlich die Hints, die ja nun zum Handbuch gehören:

bild_60.jpg

Ich empfehle eine intensive Suche!
Ich habe noch längst nicht alles Neue ausprobiert. In jedem Fall ist dieses Upgrade eines Major-Upgrades würdig. Es ist gut zu wissen, dass NI endlich wieder REAKTOR Beachtung schenkt. Es müssen aber andererseits die angefangenen Konzepte (zum Beispiel table framework) auch zu Ende gedacht werden.
Der Hype um die REAKTOR-Blocks ist in jedem Fall ein Volltreffer.
Wenn man bedenkt, wie lange das schon in der Schublade lag?

Ich wünsche Euch einen guten Neueinstieg!

ciao herw

PS: Es taucht natürlich die Frage auf, ob man nun sofort upgraden sollte oder möglicherweise auf ein Komplete 11 wartet. Nun, wenn man sich die Zyklen von Komplete anschaut, dann ist dort wohl erst im Frühjahr ein Upgrade zu erwarten.
Jeder muss entscheiden, ob die 99€ es wert sind, sofort (zusätzlich) investiert zu werden, in jedem Fall viel Spaß!