Deutsches Reaktor Forum

Ein und dieselbe Function - Ein Umschalter switcht hunderte von Parametern. Kein Problem.

Passiert dieses Umschalten aber via (jede Art) Clock, also das umschalten passiert "quantiziert", gibt es einen deutlichen CPU-peak.

Hintendran passiert schon jede Menge, diverse switches, neue table-daten.... etc. Aber wie gesagt, per Hand gibt es diesen Peak nicht, nur wenn via clock und value, oder router oder wie auch immer INDIREKT gesynced getriggert wird.

Mysteriös!

Es läßt sich aus deiner Beschreibung leider nicht 100%ig ableiten, wie und wann die CPU Peaks bei dir auftreten (Beispiel, Screenshots, Modulnamen...? ), aber vielleicht habe ich eine Erklärung für dich:
Die Maus triggert Events im GUI-THREAD. Damit sind auch alle Kinder dieses Trigger-Event GUI-threaded.
GUI-threaded events werden nicht in der CPU-Auslastungsanzeige "mitgezählt".

Alle Clocks, ausser DClk, triggern im AUDIO-THREAD und werden somit von der CPU Anzeige erfasst.

Passt das?

Quietschboy hat geschrieben:Alle Clocks, ausser DClk, triggern im AUDIO-THREAD und werden somit von der CPU Anzeige erfasst.

Passt das?

Danke, jein!

Es ist eindeutig nicht nur einen Unterschlagung im Rektor-CPU-Meter.
In Bitwigs CPU-Verlauf ist es sehr schön zu sehen: Ein Umschalten via clock erzeugt einen „singel-Peak“ Sehr kurz, vielleicht nur paaar samples lang, aber ein deutlicher Ausschlag, je höher, je geringer die Latenz.

Ein Umschalten via Maus (wie gesagt, exalkt das gleiche an „switches“, etc. erzeugt diesen Peak nicht, resp. deutlich moderater!

Wie sieht es denn aus, wenn du nicht per Maus sondern per MIDI (echtes MIDI IN, keine Computertastatur) umschaltest?

Oder du die DClk verwendest?

Tatsächlich, per Display-clock gibt es diesen exorbitanten Peak nicht!

Selbst wenn ich meine ursprüngliche Clock nutze (kA wie ich Dclk, das UNGEFÄHR 25hz taktet, jemals synchron kriegen soll!)
Also einfach meine alte Clock, dann ganz simpel ein Value mit Dclk "trigger" dahinter setzten und schon funzt es, obwohl ja eigentlich sogar ein paar "Berechnungen" mehr erfolgen...

Erstmal ganz dickes danke.

Irgendwie ulkig das reines Event-Handling dann doch scheinbar irgendwo in SR stattfindet und ein Dclk dahinter das "rausfiltert". Ich habe keine andere Erklärung für dieses Mysterium: Im gesamten Test-ENsemble habe ich keinen einzigen "schwarzen" Port!

Da drängt sich natürlich gleich ne Frage auf, macht es vielleicht Sinn, wenn ich bspw. fette FX Switche (via IC send) ebenso "trigger", also vor das IC send > Switch ein Dclk-Value hänge?
Oder gleich ein standard-Macro (mit DLCK-Value, wahlweise mit init und step filter das bei "potenziell kritischen" Outs/ INs ohne große Überlegung erstmal einfach dazwischen gehängt wird. Defacto sind es zwar mehr Strippen und Module, aber uU ist mehr gleich effizienter, weil die Berechnungen davor zwar irgendwie stattfinden, aber aber gleichzeitig irgendwie "weg-geswitchet werden, also anders als bei simplen Step-filter dahinter???)

Und vor allem: Ist es effizienter in jedem Macro eine eigne Sys-Info zu haben, oder ist es effizienter EINE Globale SYS-Info per Strippe/Sends zu nutzen? Per Sends bestimmt nicht, aber per Strippe?

Gibts sonst noch was zu beachten bei der DCLK? Wann

@eventmanager

Quietschboy hat geschrieben:[...]
Die Maus triggert Events im GUI-THREAD. Damit sind auch alle Kinder dieses Trigger-Event GUI-threaded.
GUI-threaded events werden nicht in der CPU-Auslastungsanzeige "mitgezählt".
Alle Clocks, ausser DClk, triggern im AUDIO-THREAD und werden somit von der CPU Anzeige erfasst.[...]

Die CPU Belastung ist natürlich trotzdem da, wird nur eben nicht in der Anzeige erfasst.

@ Herwig
Hi Herwig

@Eventmanager
Ui ui ui, ....Holzpfad.....
Also, das ist so: wie Herwig eben schon gesagt hat, ist die CPU Belastung, auch wenn die Berechnung im GUI Thread stattfindet, auf deiner CPU vorhanden.
REAKTOR teilt sich in einige Threads auf deiner CPU auf, wobei aber für uns nur der GUI Thread und der AUDIO Thread wichtig sind. Diese Threads können, gesteuert durch das OS, denke ich, auch auf verschiedenen CPU-Cores deines Rechners laufen.
Anscheinend wird in der CPU Anzeige deiner DAW der GUI Thread (auch) nicht berücksichtigt.

Reaktor Audio-Verbindungen werden IMMMER im Audio Thread berechnet.
CR.C, LFOs, SR.C laufen im Audio Thread (also immer auch deren Child-events).

Reaktor Events können im GUI oder im Audio Thread auftreten. Das hängt von ihrem Ursprung ab. Das wird an anderen Stellen oft genug erklärt.
Ursprünglich war die Idee von Stephan Schmitt wohl diese, dass die Timing-kritischen Berechnungen in einem eigenen Thread, also dem Audio Thread berechnet werden sollen und alle nicht kritischen Berechnungen (also die GUI-Ausgabe) in einem anderen, eigenen Thread. Das Ganze hinkt nun allerdings etwas, da Eingangsevents abhängig von ihrem Ursprung gethreaded werden. Beispiel: Note-In per Computertastatur -> GUI, Note-In per Midi -> Audio. Gleiches gilt auch für Controllereingaben: Maus -> GUI, MIDID IN -> Audio. Die Child-Events davon können nun allerdings wichtig für die Audioberechnung oder eben auch, oder nur, für GUI sein.

GUI-only relevante, heftige Iterationen (z.B. über Tables) sollten von dir aktiv über den GUI Thread getriggert werden (Verschiebung in GUI Thread per Display Clock + Smart Value / 25Hz max). Zu diesem Thema hat NI ja auch neulich (R6.1?) die GUI Core Cell eingeführt. Das hat aber eigentlich einen ganz anderen Hintergrund.

Problematisch mit diesen zwei Threads wird es, wenn diese auf Reaktorverkabelungen gemischt werden. Im Partial Framework von Max Zagler gibt es dazu ein sehr gutes PDF was sich mit dieser Problematik beschäftigt. Ich häng das mal an und kann es dir als Basis Lektüre über die Threads nur ans Herz legen.

Ich denke nicht, dass es nötig ist, nur um unvollständige CPU-Anzeigen zu entlasten, deine Berechnungen zwangsweise in den GUI Thread zu verlegen. Wenn es sich um GUI-only relevante Daten handelt, dann, ja, ab in den GUI Thread damit.

Was war noch?
ach ja:
"Irgendwie ulkig das reines Event-Handling dann doch scheinbar irgendwo in SR stattfindet und ein Dclk dahinter das "rausfiltert". Ich habe keine andere Erklärung für dieses Mysterium: Im gesamten Test-ENsemble habe ich keinen einzigen "schwarzen" Port!"

Aaalso:
Primary Events sind NIE synchron oder simultan zu irgendetwas anderem!
D.h. Primary Events sind immer asynchron zur Sample Clock und non-simultan zueinander! Du kannst sie per Definition nicht synchronisieren (zu was auch immer).
Ausnahme davon ist die Initialisierung, wo tatsächlich alle Event-Linien immer simultan arbeiten, bzw alle Event Sources simultan feuern. Das muss man im Hinterkopf behalten..

Audio Linien sind immer synchron zur Clock (klaro) und simultan zueinander (was aber eigentlich gar keine praktische Rolle spielt).

Ey Herwig, irgendwas funktioniert hier nicht mit Dateianhängen (PDF).
Hängt einfach nicht an...
@ EM
Partial Frameworks aus der UL runterladen. Das PDF heißt "thread_problems.pdf"

Eventmanager hat geschrieben: Und vor allem: Ist es effizienter in jedem Macro eine eigne Sys-Info zu haben, oder ist es effizienter EINE Globale SYS-Info per Strippe/Sends zu nutzen? Per Sends bestimmt nicht, aber per Strippe?

Das kommt drauf an. Überleg mal. Die Sys-Info ist auch nur eine Konstante die einmal, also EINMAL, während der Laufzeit deines Ens abgerufen wird. Sprich bei Initialisierung. Hast du 20 unterschiedliche Berechnung zu dieser Konstante (an verschiedenen Stellen), so würde ich das Sys-Info Modul 20-mal platzieren. Hast du nur eine Berechnung mit dieser Konstante, die 20 verschiedenen Zielen zugewiesen werden soll, bräuchtest du diese Berechnung nur einmal ausführen und per wire oder Send den Zielen zuführen. Dabei hättest du etwas Initialisierungszeit gespart, was bei Re-Init evtl. von Vorteil sein könnte (ein Müh weniger Knackser-Gefahr).
Letztendlich ist der Performance-Gewinn bei Initialisierung nur marginal (wenn überhaupt) bemerkbar.
Während das Ens läuft ist es einfach sch....-egal.
Insofern, schaue einfach daß es für dich und deine Übersicht über dein Ensemble Sinn ergibt. Mach dir über alles andere keinen Kopp.

Viel wichtiger ist es, Audio-Berechnungungen, die mit Sample Rate ständig ausgeführt werden, zu optimieren und schwere Iterationen im Blick zu behalten. Iterationen für die GUI-Anzeige, wie gesagt, in den GUI Thread verschieben.

Quietschboy hat geschrieben:Ey Herwig, irgendwas funktioniert hier nicht mit Dateianhängen (PDF).
Hängt einfach nicht an...
@ EM
Partial Frameworks aus der UL runterladen. Das PDF heißt "thread_problems.pdf"

Du meintest reaktor_threads.pdf? Findest du bei den add ons.
Ich hatte den Dateityp PDF falsch zugewiesen. sorry

Quietschboy hat geschrieben:

Eventmanager hat geschrieben: Während das Ens läuft ist es einfach sch....-egal.
Insofern, schaue einfach daß es für dich und deine Übersicht über dein Ensemble Sinn ergibt. Mach dir über alles andere keinen Kopp.

Dacht ich mir schon, wollt´s wahrscheinlich nur noch mal bestätigt bekommen;-)
Ich bin jedesmal aufs neue fasziniert, wieviele neue Module, verschachtelte Makros, strippen, ports..... eigentlich so in ein ENS "hineinpassen", ohne das die CPU davon auch nur im geringsten beeindruckt wird. Zumindest bei reinen Event-Strömen.
Arbeitszeit sparen und Übersicht behalten, ist wohl deutlich wichtiger als "Effizienzsteigerung" jenseits der Mess-Toleranz.
Auf jeden Fall interessant zu hören, was so ganz tief unter Haube passiert.
Danke.

gerngeschehen

das pdf oben ist das, welches ich meinte. Danke dafür.

BTW lieber QB,

hast du vielleicht ne IDee wie man die display-rate generell drosseln kann?
Das Reaktor-Meter und die DAW- meter zeigen immer nur audio-berechnungen an, richteg CPU kosten aber GUI-gimmicks wie laufende Positionsanzeiger und dergleichen.
Vergleich mal den DAW-Verbrauch in deinen Taskmanger / Aktiv-Monitor einmal mit und einmal ohne Plug-in Fenster.
Selbst wenn nur wenig optische Gimmicks involviert sind, ist der Unterschied ziemlich deutlich!!!!!!

Achja, ganz vergessen: Danke für die PDF, sehr aufschlussreich.

Eventmanager hat geschrieben: hast du vielleicht ne IDee wie man die display-rate generell drosseln kann?

Für Teile deiner Struktur kannst du natürlich einen Clock Divider verwenden.

Ähm, du meinst nen clock divider HINTER der Dsply-clock????? Wirds dann nicht wieder ein "audio-thread"?????
(Ich muss die PDF nochmal studieren, irgendwo hab ich wohl nen verstädniss-fehler).

Aber wie auch immer, ich denke das Prob liegt dann doch woanders: Bei der DAW / resp. deren display-refresh.

In standalone macht es "kaum" nen Unterschied ob ich das Reaktor-Fenster offen oder "versteckt" habe, um die 5% (ein kern).
In Live schon etwas mehr, in Bitwig 1 wirds aber richtig deutlich bis zu 20-30% mehr!
Und ich rede hier von Durchschnittswerten, exorbitante singel-peaks zeigt mir mein activ-monitor leider nicht.

Das Prob lässt sich wohl leider nicht allein mit Reaktor allein lösen (ausser man verzichtet auf alle GUI-feature).