Projekt#01 - Event-Smoother

[Eventmanager]

In diesem Projekt möchte einen Event-Smoother in Core erstellen. Ich möchte eure Expertise hier als "Assistenten", als Korrektur/Rotstift nutzen, die mich auf Fehler HINWEISEN, aber prinzipiell möchte ich mir die Lösungen selbst erarbeiteten.
Da ich in Core noch nicht so flink bin, baue ich Lösungsansätze erstmal in PRIM vor und wenn es eure Zustimmung erhellt, erst dann in Core nach.

In diesem Projekt gehts um einen dynamischen Event-Smoother. Son Teil benötigt anscheinend mehre Blöcke, die ich hier SEPARAT sukzessive durchgehen möchte. Als erstes benötigen wir wohl eine Art Ramp-Generator (Eventrate, gar display-rate sollte reichen).

Im Prim würde ich es wie im Bild machen.
Über den ModuloB-Knob liesse sich die Zeit dynamisch einstellen wie lange die Rampenzeit ist um hinten einmal den Durchlauf 0-1 zu generieren. Über den Trig-IN wird die Syncro sichergestellt.
Ist das so ok, gehts generell eleganter, oder speziell in Core?

Ich habe mal das Bild auf 50% skaliert, sonnst rutscht es aus dem Bildschirm. - herw

[herw]

In diesem Projekt möchte einen Event-Smoother in Core erstellen. Ich möchte eure Expertise hier als "Assistenten", als Korrektur/Rotstift nutzen, die mich auf Fehler HINWEISEN, aber prinzipiell möchte ich mir die Lösungen selbst erarbeiteten.
Da ich in Core noch nicht so flink bin, baue ich Lösungsansätze erstmal in PRIM vor und wenn es eure Zustimmung erhellt, erst dann in Core nach.

In diesem Projekt gehts um einen dynamischen Event-Smoother. Son Teil benötigt anscheinend mehre Blöcke, die ich hier SEPARAT sukzessive durchgehen möchte. Als erstes benötigen wir wohl eine Art Ramp-Generator (Eventrate, gar display-rate sollte reichen).

Im Prim würde ich es wie im Bild machen.
Über den ModuloB-Knob liesse sich die Zeit dynamisch einstellen wie lange die Rampenzeit ist um hinten einmal den Durchlauf 0-1 zu generieren. Über den Trig-IN wird die Syncro sichergestellt.
Ist das so ok, gehts generell eleganter, oder speziell in Core?

Ich habe mal das Bild auf 50% skaliert, sonnst rutscht es aus dem Bildschirm. - herw

Mark hat einen wundervollen eventsmoother vor einigen Monaten gebastelt. Er ist für alle Eventualitäten (große/kleine Sprünge) optimiert. Vor allem ist der CPU-Verbrauch minimalst. Die Lösungen sind um Längen besser als die von NI.
Der wichtigste Ansatz bei beiden ist, dass man den eventsmoother für den Bereich [0|1] optimiert. D.h. man arbeitet mit normierten Lösungen. Die real benötigten Bereiche werden auf [0|1] heruntergerechnet, dann gesmootht und zum Schluss wieder hochgerechnet.
Das erscheint zunächst mal umständlich, aber es gibt gar nicht so viele verschiedene Bereiche:
pitch-Werte für Oszillatoren, und Filter-Cutoff werden so genormt, dass man [0|120] auf [0|1] trimmt. Der Pitchwert 60 entspricht dann 0,5. Das ist praktisch, wenn man sich in allen Strukturen daran hält (in Monark und den Blocks und in Emscher ist das zum Beispiel der Fall.
Lautstärkewerte: [-60|20], Zeitwerte für Hüllkurven: [-20|80] und natürlich eventuell bipolare Werte.
Wenn man das für sich immer normiert, wird es zur Selbstverständlichkeit.
Da du den Smoother selbst erstellen willst, belasse ich es mal dabei. Mark ist aber eindeutig der Experte für die smoother.

BTW: ein event-smoohther ist ein anspruchsvolles Projekt. Einen Start mit primary und anschließender Übersetzung bringt hier nichts, da man in core einen völlig anderen Ansatz wählt. Aber wie schon gesagt Mark ist der Experte. Falls du in den NI-smoother schauen möchteset, am (realtiv) einfachsten ist der Lin Smoother (A). Allerdings arbeitet dieser nicht mit normierten Bereichen.
Es sind umfangreiche Testumgebungen nötig, damit man die verschiedenen Lösungen vergleichen kann.

Aber vielleicht denke ich viel zu komplex und du möchtest etwas ganz Einfaches produzieren. Der event-smoother von Mark eignet sich wunderbar, wenn man mit Hardware zum Beispiel die Cutoffs der Filter drangsaliert.

[Eventmanager]

Na, wenns das schon vom Meister gibt, sag ich natürlich auch nicht nein, stattdessen 1000 Dank;-)
Hab, aus der v11 (mW die letzte???, die mkII raff ich nicht ganz), ein LIN macro gerippt/reduced

Bildschirmfoto 2019-08-10 um 13.42.18.png

Schöne 10-Sekunden-"Fahrten" damit möglich... aber das Teil frisst schon etwas CPU, sofern aktiv (T >Null). (ca. 1% CPU bei 5 Sekunden auf mein imac2014 in MONO!).
Es scheint von der SR getaktet zu werden (CR-Pack ist unverbunden) und und ich hab keine Ahnung wie ich son Pack "speisse". Ich würd das Teil gerne auf Eventrate runterbrechen, wie mach ich das?

Verdrahte ich hier, also eine Ebene tiefer,

Bildschirmfoto 2019-08-10 um 16.04.55.jpg

das Time-Send statt mit dem R-Quick vom Pack direkt mit ner CR (test-CR-In) dann erhält natürlich der Rest weder korrektes Reset noch das C was sonst vom "Pack" rausgeht.
Ich denke meine Kernfrage ist, wie bekomme CR statt SR ins Pack rein? Es ist mir sowieso schleiehaft wo das Pack die SR hernimmt, es ist ja mit nix verbunden ausser mit dem Quick-In (->CR), der aber wiederum auch mit nix verbunden ist?

Und BTW: das ein In-port auch von anderem In-Punkt auf gleicher Ebene gespeisst wird, wie bspw. das unbenannte In zu dem (0) -IN, ist das sone ne Art Order?????

Andre Frage: Wenn ich mit BTT bspw. Retina-Screenies gleich jpge und 50% skaliere ist die Quali extrem schlecht und jeden Screeni extra in Affinity Photo reducen will ich auch nicht. Irgendwer ne Idee, ob man das GLEICH am besten mit Bordmitteln sauber hinkriegt?

[herw]

Für das Reduzieren der Bilder benutze ich GraficConverter. Gibt's aber nur für Macs, dafür unschlagbar preiswert (25€) und unglaublich nützlich.

[herw]

Um solcher Art Strukturen zu verstehen, musst du dich in das (engischsprachige) Handbuch REAKTOR 6 Building in Core einlesen.
Für die hier vorkommenden Clocks und Bundles genügt das Kapitel SR und CR Bundles (S. 91ff) und zum Nachschlagen Bundles S. 56ff.

[herw]

Na, wenns das schon vom Meister gibt, sag ich natürlich auch nicht nein, stattdessen 1000 Dank;-)
Hab, aus der v11 (mW die letzte???, die mkII raff ich nicht ganz), ein LIN macro gerippt/reduced

Bildschirmfoto 2019-08-10 um 13.42.18.png

Schöne 10-Sekunden-"Fahrten" damit möglich... aber das Teil frisst schon etwas CPU, sofern aktiv (T >Null). (ca. 1% CPU bei 5 Sekunden auf mein imac2014 in MONO!).
Es scheint von der SR getaktet zu werden (CR-Pack ist unverbunden) und und ich hab keine Ahnung wie ich son Pack "speisse". Ich würd das Teil gerne auf Eventrate runterbrechen, wie mach ich das?
[...]

Zum Einstieg mal zwei ganz einfache mögliche Lösungen:

einfache Clocls.jpg

Im oberen Beispiel wird von primary die Kontrolrate CR (hier auf 25Hz eingestellt) entnommen. Da die primary CR eine Eventquelle ist (siehe die Erläuterungen von Max Zagler zum Thema Thead-Safeness in REAKTOR) und nachdem die Clock-Frequenz auf 1s herunter getaktet wurde, kann man auch einen einfachen event-Ausgang in der CoreCell nehmen. Der ACEW zeigt nach jeder Sekunde einen clock-Event an.
Im unteren Beispiel greift die Corecell auf die intern vorhandene Controlrate der Corecell zurück. Sie liegt eigentlich in einer unsichtbaren Ebene zwischen Corecell und primary.
Du öffnest dazu mit einem Rechtsklick auf den Eingang des Clock-Teilers CR und wählst den pickup CR (später erkennbar am Häkchen vor dem pickup-Namen).

pickup cr.jpg

...
oder du öffnest mit einem Rechtsclick auf den Eingang CR den Punkt Pickup Distribution Bus:

Pickup Distibution Bus.jpg

...
und gibst einfach CR ein.

Die ControlRateClock ist völlig verschieden und unabhängig von der primary clock. Sie ist eine AudioQuelle, deswegen muss am unteren Ausgang der Corecell in den Eigenschaften ...

event-audio-Ausgang.jpg

Allow Audio Events aktivierten.
Von der Definition her stimmen die ControlRateClock und SampleRateClock überein. Man kann durch verschiedene Makros beide verändern. Da aber von mehreren Makros (Oszillatoren, Filter etc.) auf die SR.C zugegriffen wird (zum Beipiel bei den formal unbesetzten Eingängen der Filter etc.) benutzt man für veränderte Clockfrequenzen die core CR.C.
Bei dem Pickup CR (wie auch SR) handelt es sich um ein Bundle bestehend aus drei Werten: der eigentlichen Clock C, der ClockRate R und dem ClockReset Reset (du musst Groß- und Kleinschreibung beachten).
Ich habe beim unteren Bundle die Ausgänge C und Reset gelöscht, um an die eingestellte Hostfrequenz zu bekommen. Dividiert man die Clock durch die Hostfrequenz, dann gibt es wieder genau einen (Audio-) Event proSekunde.

PS: Wie du richtig erkannt hast, schluckt der einfache smoother von NI immens viel CPU. Wenn du dir vor Augen führst, dass EMSCHER und andere zukünftige Ensembles mehrere hundert smoother besitzen, dann kannst du dir vorstellen, welche Leistung Mark vollbracht hat.

[Paule]

Für das Reduzieren der Bilder benutze ich GraficConverter. Gibt's aber nur für Macs.

XnView tut's auch für nix. Gibt es für Mac und PC
https://www.xnview.com/de/

[Eventmanager]

Aha, danke. Das macht einiges klarer. Aber ja, hm, - ich komme wohl um RTFM! nicht drum rum;-) Hab ja sogar noch das v5 Core-Buch, gedruckt und auf DEUTSCH:-) Auch wenn da mitunter einiges wohl obsolet ist, sollte es den Einstieg erleichtern!

Was die Bilder betrifft, XNview iss schon echt deli, zum sichten/ordnen.... aber für Screenies gehts noch bequemer: hab ich mir schnell ne Automator-App geschrieben. Geht ruckzuck, einfach 3 Abläufe erstellen

Ohne Titel-3.jpg

Das ganze als APP speichern, Alias im Dock ablegen oder per BTT nen Shortcut zuweisen.... voila! Stolperschein gibts bei "sichern unter". Hier musstu erstmal Neu wählen, dann zum Speicherort hangeln und den bestätigen. Das Ergebnis sieht dann zwar verwirrend so aus, aber es speichert unter dem festgelegten Ort.
Automator ist schon echt nett, kann man paar schöne Stunts mit machen (wenn man die entsprechenden "Makros" erstmal (Bilderkram im Ordner Fotos...etc) ) findet

[herw]

Aha, danke. Das macht einiges klarer. Aber ja, hm, - ich komme wohl um RTFM! nicht drum rum;-) Hab ja sogar noch das v5 Core-Buch, gedruckt und auf DEUTSCH:-) Auch wenn da mitunter einiges wohl obsolet ist, sollte es den Einstieg erleichtern!
[...]

ja, es ist schade, dass es keine deutsche Version des core-Handbuchs mehr gibt.
Trotzdem muss man sich da durchbeissen.
Eigentlich wird Alles ziemlich klar erklärt, doch ist die Ungeduld oft viel schlimmer als der Inhalt.
Da aber core so viel mehr Möglichkeiten (in DSP) als primary besitzt, ist klar, dass der Lernaufwand auch beträchtlich größer ist. Ein einfaches Übersetzen von primary in core hat für manche einfache Berechnungen zwar auch einen Lerneffekt; spannend wird es aber erst dann, wenn man sich dem event-prinzip des core voll hingibt und einfach nur aus der Denkweise des core neue Ideen erwachsen lässt und primary-Denken beiseite schiebt.

[Paule]

Herwig, ich habe noch 'Reaktor 5 Core Manual german.pdf' für R5

[herw]

Herwig, ich habe noch 'Reaktor 5 Core Manual german.pdf' für R5

Ich habe sogar noch das Hardware-Handbuch von R 2.3

[Paule]

Core gibt es doch erst seit R5!?!

[Eventmanager]

Eigentlich wird Alles ziemlich klar erklärt, doch ist die Ungeduld oft viel schlimmer als der Inhalt.

Jo iss wirklich verständlich geschrieben. Mit der gedruckten Version kann man auch schön im Garten lümmeln Mit Eselsohren und Markern weiss man dann auch gleich was man schnell mal durch exerzieren will. Allerdings zerfelddert es schon etwas;-) Viellicht werd ich mir auch mal nen ipad gönnnen, sind die displays mittlerweile sonnenlichtgeeignet, zumindest im Halbschatten? (Mein Iphone 2 ist in dieser Hinsicht katastrophal, selbst bei ziemlicher Bewölkung). Weiss das jemand zufällig? Zumal mit catalyna soll ja ipad als Remote / 2. Monitor... ganz neue Möglichkeiten bekommen

[herw]

Jo iss wirklich verständlich geschrieben. Mit der gedruckten Version kann man auch schön im Garten lümmeln Mit Eselsohren und Markern weiss man dann auch gleich was man schnell mal durch exerzieren will. Allerdings zerfelddert es schon etwas;-) Viellicht werd ich mir auch mal nen ipad gönnnen, sind die displays mittlerweile sonnenlichtgeeignet, zumindest im Halbschatten? (Mein Iphone 2 ist in dieser Hinsicht katastrophal, selbst bei ziemlicher Bewölkung). Weiss das jemand zufällig? Zumal mit catalyna soll ja ipad als Remote / 2. Monitor... ganz neue Möglichkeiten bekommen

Ich benutze noch ein iPad 2 (ohne Retina-Auflösung). Ist wohl auch schon 10 Jahre alt. Ich hab's auch schon für die Bandprobe als Notenblatt verwendet. Diese iPads scheinen unverwüstlich. Wenn die Sonne auf das Display scheint, kann man auch noch lesen; allerdings ist der Kontrast dann nicht so toll.
Schlecht kann man lesen, wenn man gegen die Sonne liest. Dann spiegelt das Display das angestrahlte T-shirt. Im Schatten kann man super lesen. Wie gesagt es ist ein uralt-Modell.
Ich benutze als pdf-Reader die App GoodReader 5. Sie ist sehr komfortabel.

[Eventmanager]

Ich hol mir dann schon ein etwas neures pad, auf jeden Fall mit Retina und Catalina kompatibel, wobei die wohl nicht so robust sein sollen, aber ich will ja damit auch nicht Federball spielen;-)

Hab deine obige Clock mal nachgebaut und wahrscheinlich siehtst du auch an den roten CX "Bussen" Was ich hier testweise bezwecke und dabei scheiter.
Kann man so UNIVERSELLE Busse schaffen, die auch in anderen Cells... dann abgegriffen werden können? Laut Handbuch ja: "Scoped Buses allow invisible connections across several Structure layers." aber irgendwas mach ich grundlegend falsch???

Ohne Titel.jpg

Wär natürlich klasse, wenn man sich so GLOBAL ein paar verschiedenen Taktungen vorbereitet und dann bequem bei Bedarf das enstprechende wählt. Sen/Distribution Bus = Scopebus, oder????)