Vielen Dank fürs Ansehen!
Die Audiosignale die ich bisher habe sind die von den beiden LFOs und ENVs. Die werden mit der Methode die ich am Anfang des Threads beschrieben (erster upload) aus der Audiozelle geführt und in der Displayeventzelle zur Darstellung aufbereitet. Dort habe ich nun im Gegensatz zu meiner ganz alten Version eine Struktur gebaut die viel effizienter ist was zur Folge hat, dass sich ungeachtet der Anzahl darzustellender Animationen (Modulationssignale) die Architektur nicht ändert. Das läuft über eine Art des "Oversamplings" allerdings nicht von der Audioclock, sondern der Displayclock.
Das lässt mich natürlich auch über das "richtige" Oversampling nachdenken. Da mein system Automatisch erkennt wieviele LFOs, ENVs usw. "angemeldet" werden würde es der Struktur der großen Audiozelle guttun wenn diese Modulationsquellen nur einmal vorhanden sind dafür aber mehrere Male pro Audioclock berechnet werden.
Da muss ich jetzt ne folgenschwere Entscheidung treffen, weil ich jetzt dabei bin die Architektur der Audiozelle festzulegen.
Dazu hab ich mal ein Beispielensemble gemacht in dem es 2 Audiocorezellen gibt.
Die erste "oversampled" enthält einen LFO der 20mal pro Audioclock berechnet wird.
Die zweite "normal" enthält 20 LFOs die 1mal pro Audioclock berechnet werden.
overS.jpg
betrachtet man nun den CPU-load des Ensembles sieht man, dass die Corezelle "normal" (rechts unten untere Abbildung) mehr CPU verbraucht als die "oversampled"
das Problem steckt natürlich in dem A to E perm welches den Iterator triggert.
overSstruc.jpg
Wenn man nun das Oversampling in diesem Ensemble ausschaltet (Löschen der Eventleitungen die in die obere Audiozelle führen) sieht man, dass die Normalversion viel weniger CPU verbraucht.
Nun ist das aber nicht der Weisheit letzter Schluss, denn:
1. Werden in meinem "Endprodukt" niemals so viele Audiosignale herausgeführt da alles innerhalb der Audiocelle passiert.
2. Die Anzahl der Events pro Audioclock muss lediglich der maximalen Anzahl gleichförmiger Strukturen entsprechen und ist daher niemals 20. Wenn ich also 6 LFOs, 3 Sequenzer und 5 Envelopes habe brauche ich 6 Events pro Audioclock
Die Anzahl der Events pro Audioclock (und damit der CPU-load des "A to E perm") vergrößert sich also nicht wenn ich im Bau der großen Audiozelle fortschreite. Es könnte also sein, dass beim Erreichen eines gewissen Umfanges der Struktur der "Nachteil" des "A to E perm" verschwindet.
Meinungen und Erfahrungen dazu würden mich brennend interessieren.
oversmpLFO.zip
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.