Seite 3 von 3

Re: CPU-Last reduzieren: automatische Modul-Deaktivierung

Verfasst: 9. März 2018, 06:19
von herw
Quietschboy hat geschrieben:Das Timing des Switch hat mich ja nicht locker gelassen. Ich habe deinen Test, 128Bpm, etwas verändert und das Audiosignal mit dem Reaktor Recorder aufgezeichnet und in Soundforge (Wave-Editor) angeschaut.
[...]
Ist es jetzt eigentlich das Timing des Switches oder/ und des ICsends? Dazu müsste man nochmals mit einem gesteuerten Element überprüfen, dessen Reaktion schneller als die DCLK läuft.
Jetzt wäre natürlich noch schön, eine tabellarische Übersicht zu haben, was so Alles genau mit den verschiedenen Clocks läuft.

Nebenbei bemerkt: es ist schon schlimm, dass wir uns hier darüber den Kopf zerbrechen, wie REAKTOR vor 20 Jahren konzipiert wurde, statt über nicht vorhandene Neuerungen :( .

Re: CPU-Last reduzieren: automatische Modul-Deaktivierung

Verfasst: 9. März 2018, 11:50
von 128bpm
herw hat geschrieben:Nebenbei bemerkt: es ist schon schlimm, dass wir uns hier darüber den Kopf zerbrechen, wie REAKTOR vor 20 Jahren konzipiert wurde, statt über nicht vorhandene Neuerungen :( .
Neues gibt's für mich derzeit noch genug :mrgreen:

Re: CPU-Last reduzieren: automatische Modul-Deaktivierung

Verfasst: 9. März 2018, 15:23
von Quietschboy
herw hat geschrieben:Ist es jetzt eigentlich das Timing des Switches oder/ und des ICsends? Dazu müsste man nochmals mit einem gesteuerten Element überprüfen, dessen Reaktion schneller als die DCLK läuft.
Jetzt wäre natürlich noch schön, eine tabellarische Übersicht zu haben, was so Alles genau mit den verschiedenen Clocks läuft.

Nebenbei bemerkt: es ist schon schlimm, dass wir uns hier darüber den Kopf zerbrechen, wie REAKTOR vor 20 Jahren konzipiert wurde, statt über nicht vorhandene Neuerungen :( .
Die IC Verbindung passiert sofort, keine Synchronisierung zur DCLK oder sonstwas:
IC Verbindung keine Verzögerung.jpg

Re: CPU-Last reduzieren: automatische Modul-Deaktivierung

Verfasst: 22. Mai 2018, 14:12
von 128bpm
In einem Projekt habe ich ausgiebig mit Routern gearbeitet welche die Clock-Signale deaktivieren wenn sie nicht benötigt werden. Je mehr Clock-Router vorhanden waren und je komplexer die Struktur nach den Routern war, desto länger dauerte der Compilier-Vorgang. Ab einem gewissen Punkt war ein vernünftiges Arbeiten unmöglich. Das Kompilieren dauerte schnell mehrere Sekunden und dass nach jeder kleinen Änderung innerhalb von Core.

Mein Fazit lautet: Reaktor 6 ist nicht für dynamische CPU-Switches konzipiert, weder auf der Primary-Ebene noch auf der Core-Ebene.