Deutsches Reaktor Forum

Bau doch mal einen Clock Divider in Primary selbst. Dann sollte deine Frage eigentlich beantwortet sein.

Was die CPU Werte mit Reaktor VST Fenstern angeht:
Das hört sich ziemlich krass an. Wo liest du denn die Werte ab? Nicht dass du hier Äpfel mit Birnen vergleichst?

Das Problem läßt sich tatsächlich nicht mit Reaktor lösen, denke ich.
Ziehe mal folgenden Umkehrschluss:
Wenn die Last mit geschlossenenm Reaktor Fenster sinkt, wird dann irgendwas (z.B. GUI Thread) in Reaktor etwa nicht berechnet?
Das darf nicht sein! Denn GUI beinhaltet ja grundsätzlich auch für Audio relevante Berechnungen.
Selbst wenn, angenommenerweise, nur die letzten Berechnungen zu den GUI Elementen und diese selbst gestoppt würden, dann müsste es ja beim Öffnen des PlugIn Fensters in Reaktor einen Refresh oder quasi eine Re-Initialisierung geben, damit die GUI Elemente auch das richtige anzeigen.

Ähm, ich hab da was nicht bedacht, bezüglich deiner Frage mit dem SysInfo-Modul (ob es besser ist das zentral abzulegen und zu verteilen, oder viele dieser Module verstreut abzulegen).
Es ist ja nur der SR Port, der eine Konstante darstellt. Die anderen Ports senden regelmäßig geclockte Events.
So gesehen kannst du das Modul natürlich ruhigen Gewissens auch überall dort wo eine dieser Clocks gebraucht wird ablegen.
Sehe es als Zugriff auf einen Standard-Bus. Wie SR.C in Core.

Quietschboy hat geschrieben:Wenn die Last mit geschlossenenm Reaktor Fenster sinkt, wird dann irgendwas (z.B. GUI Thread) in Reaktor etwa nicht berechnet?

Ich nehme nicht an, das irgendwas nicht berechnet wird. Nur sind diese "Berechnungen" dann unsichtbar und das ist mE der Knackpunkt.
Alles 2-D wird von der CPU erledigt, während die Graka Däumchen dreht.

Lass doch mal in deiner DAW den Fensterinhalt permanent mitscrollen oder nur seitenweise umschalten und beobachte dann deinen Taskmanager/Activity monitor.
Das ist eklatant. Bei Live ca. 10-15 % mehr znd bei bitwig sogar 30-40% (jeweils ein kern nehme ich an, die gesmatlast erhöht sich nur um faktor 0.25.

Ich messe mit dem activity monitor, was sicher nicht besonders präzise ist (Nur jede sekunde ein refresh (ich nehme an ein mittelwert), keine dezidierte anzeige nach kernen...)
#######

Zum Rest: Ich muss wohl die PDF nochmal genauer studieren. Nur heute bin ich zu verkatert;-)

vielen dank für all die erklärungen!

wenn ich das richtig verstanden habe, habe ich also hier unwissend meine multi displays im audio thread laufen? geclocked wird das ganze von herwigs SongPos 96a, welche im core mit modulos in ein 480er raster pro takt gedrückt wird.
richtig?

und wenn ich die momentane clock dann durch die Dclk latchen lassen würde, würde ich es in den gui thread schieben?

edit: bin zu dumm zum bilder posten...
hier der link:
https://picload.org/view/drlloppi/audiothread.png.html

das führt mich zu 1000 neuen fragen...

-gibt es unterschiede für das multidisplay wenn man es im gui thread oder audio thread laufen hat?
-wo ist die reaktionsgrenze für ein multidisplay (man kann sie anscheinend mit mehr als 25hz befeuern?)
-gilt der gui thread auch für ein x/y scope wenn ich diese mit Dclk clocke?
-kann man die Dclk tunen? (mehr hertz!) also das gegenteil von clock dividing. bzw was ist die schnellste Gui clock? oder wie modifiziere (schiebe) ich eine schnelle clock in den GUI thread.

Würd sagen: ja und ja. (zu vorletzter Post)
Und du würdest zudem noch einigen unsinnigen Overhead sparen (wegen Sample Rate als Trigger / Berechnungsfrequenz).

Thala hat geschrieben:das führt mich zu 1000 neuen fragen...

-gibt es unterschiede für das multidisplay wenn man es im gui thread oder audio thread laufen hat?
--> bei hoher Audiothread Auslastung könnte das Display im GUI Threead ins stocken geraten.

-wo ist die reaktionsgrenze für ein multidisplay (man kann sie anscheinend mit mehr als 25hz befeuern?)
--> das MD, wie alle anderen GUI Elemente, updatet nur mit DClk-Rate (etwa 25Hz / Frequenz variiert). Eingänge können natürlich schneller (Event Rate / Index mit SR) bespielt werden, bringt aber nix, was die Updaterate angeht

-gilt der gui thread auch für ein x/y scope wenn ich diese mit Dclk clocke?
--> Alles was von einem GUI-Thread Trigger getriggert wird, findet im GUI THread statt. Triggerquellen sind DClk, Maus, Tastatur des PC

-kann man die Dclk tunen? (mehr hertz!) also das gegenteil von clock dividing. bzw was ist die schnellste Gui clock? oder wie modifiziere (schiebe) ich eine schnelle clock in den GUI thread.
--> Nein, geht nicht, und wofür auch?

Schau doch mal zum Thema GUI-Core Cell in Kapitel 3.3.4 von "Reaktor 6 What´s new" rein.
Dürfte für dich interessant sein.

Quietschboy hat geschrieben:Würd sagen: ja und ja. (zu vorletzter Post)
Und du würdest zudem noch einigen unsinnigen Overhead sparen (wegen Sample Rate als Trigger / Berechnungsfrequenz).

reclock 96a.JPG

die display clock ist in meinem fall zu langsam und zu statisch.
ich fuehre die dclk in den core. dort wird es mit 5 multipliziert und in ein modulo + dup filter gefuehrt um ein raster von 480 clocks pro takt zu haben. bei 120 bpm sind das 240fps.
auch 960 funktionierte gestern bei einer linewidth von 0,5.
das sind dann 480fps.
bei 480 pixel display breite 960 linien gezeichnet.
die dclk wuerde nur alles erschweren und verkomplizieren. schnurrt wie kaetzchen im moment.

Ah OK, du zeichnest also linear zur Zeit für jeden Tick (480tel Note) immer eine Linie dazu bis ein Takt voll ist?
Hört sich irgendwie nach einem Vollkreis an.

Wenn du bei der Sache, außer der SongPosition, auch noch andere Parameter hast, die sich über die Zeit ändern und für die Berechnung der MD-Parameter benötigt werden, macht eine Stückelung in DClk-Chunks wohl wenig Sinn.
D.h., das ginge evtl. schon, wenn die eintreffenden Parameter zwischengespeichert und per DClk-Trigger wieder aus dem Array "heraus-iteriert" würden...

Aber wenn nur der Parameter SongPosition sich mit der Zeit ändert, könntest du recht easy in den GUI Thread verschieben.
Der Audioauslastung zu Gute.
Wobei - die 200-400 Linien pro Sekunde...sind nicht soo fett.

"die display clock ist in meinem fall zu langsam und zu statisch."
Nicht langsamer oder statischer als die Bildwiederholrate des Multi Display und aller anderen GUI Elemente. Eher exakt gleich!
Ich glaube hier liegt ein Mißverständnis vor.

ich denke die probleme die du mit der dclk ansprichst bekomme ich, falls ich mal goldcap auf multidisplay umarbeite.
im moment zieht das ensemble 2% cpu. da es ein block ist ... egal.
25fps sind schon ok, hauptsache es werden dann mehrere linien gezeichnet pro bild.

Quietschboy hat geschrieben:Schau doch mal zum Thema GUI-Core Cell in Kapitel 3.3.4 von "Reaktor 6 What´s new" rein.
Dürfte für dich interessant sein.

aehm. es gibt das kapitel in der 6er doku nicht.
oder wurde die doku mit 6.2 neu geschrieben?

ich hatte mir wohl zu anfang gleich die doku ausgedruckt. da war noch nichtmal das kapitel 6.0 in der whats new drin^^
habs gefunden und danke für die info.