warum keine "audio" Resonance in prim?

[herw]

...ich kann einfach nicht begreifen, warum die prim-filter nicht die option: RES wird als audio behandelt anbieten.

das ladder prim/core klingt (unmoduliert) so gut wie identisch. nur in sehr hohen RES bereichen, klingt das core teil vielleicht ne gespührte nuance besser, ansonsten aber nahezu deckungsgleich. was die beiden aber tatsächlich unterscheidet ist die cpu-last. das prim modul frist nur n drittel. trotzdem seh ich mich zähneknirschend gezwungen zum core-aquivalent zu greifen. warum?
nur das core teil bietet die möglcihkeit die RES in audiogeschwindet abzuarbeiten, das prim-teil leider nicht. und hierdurch ist tatsächlich ne extreme klangverbesserung zu hören. moduliertes RES im prim knackst ziemlich häufig/stark (materialabhängig), ebenso wie in core. ABER in core kann man nen 1pol vorschalten und das kacken wird eliminiert. in der prim version musste nen sogenannten smoother nehmen. das teil macht zwar alles knackfrei aber dafür zirpt es. ausserdem verlangsamt es (bei "brauchbaren" verzögerungen) das signal/die mod hochgradig mehr als das 1pol und ist somit schon kaum als mod zu gebrauchen.

fazit: das core-ladder klingt nicht besser. bei hoher RES etwas anders, manchmal besser, manchmal nicht. core frisst 3 mal soviel cpu. das core "kann" aber audiospeed-RES, das prim nicht. audiospeed-RES klingt (moduliert) UM WELTEN besser und kostet nur bruchteil als der komplett-"ersatz".

resümee: ich möchte einfach nur n prim-filter mit audio-RES.

das war doch Dein Einstieg!
Dann habe ich den Vorschlag gemacht, dass Du statt mit Samplerate das AudioCore-Macro doch auch mit einem niedriger getakteten Eventsignal füttern kannst, also quasi durch einen Eventeingang in das AudioCoreMakro eine andere Samplerate hineinschleust.
Wenn Du nun den Resonanzeingang als Eventeingang deklarierst und diesen durch ein niedriger getaktetes Eventsignal fütterst, müsste der CPU-Verbrauch eigentlich sinken:

Ich habe das unten geladene Ensemble mal zusammengestellt.
Überblick:



Das Dioden-Ladder Filter (gelber Rahmen) erhält die Audio-Signale von einem MultiWave-Oszillator. Die Resonanz wird zyklisch durch einen LFO verändert (links).
Die veränderte SampleRate erzeugt der Clock-Oszillator (roter Rahmen), Geralds EventCore-Ausgang mit Adapter (grüner Rahmen) ist vor den Resonanz-Eingang geschaltet.

Ich habe das Core Ladder Filter verändert, indem ich die Eingänge P, PM FM und Res alle auf event-Eingänge geschaltet habe, um den Effekt deutlicher zu zeigen.
Ich konzentriere mich nun nur auf den Resonanzeingang.
Die Umschaltung der Audio-Eingänge auf Eventeingänge bedeuten noch nicht, dass die Informationen, die dort hineinkommen nun nur mit Control-Rate hineingelangen. Der einzige Unterschied besteht darin, dass alle ankommenden Events direkt ohne SampleRate-Taktung verarbeitet werden.
Die neue SampleRate liefert der Clockgenerator (roter Rahmen): man kann ihn einstellen für 0 ... 40000 Hz in 1000Hz-Schritten.
Wir stellen ihn z.B. auf 2000Hz.
Das Audiosignal des LFOs wird mit Hilfe von Gerald EventCore-Adapter in ein Eventsignal umgewandelt, das das Audiosignal mit 2000Hz taktet, also wesentlich seltener als die SampleRateClock des Systems, aber auch schon schneller als die ControlRate (in der Regel 400Hz). Ich habe dazu Geralds Adapter so verändert, dass er die ankommenden Audiosignale nicht mit 44100Hz taktet, sondern mit der niedrigeren Samplerate. (krümelmonster möge mir nach seinem wohl verdienten Urlaub widersprechen, wenn ich es falsch umgesetzt habe).
Der Adapter wandelt das Audiosignal des LFOs also in ein mit 2000Hz getaktetes Eventsignal um. Damit wird der Eingang der Audio-CoreCell wesentlich weniger belastet als der ursprüngliche Audioeingang (auch unbeschaltene Audioeingänge belasten die CoreCell!).

Wir schauen auf die CPU-Belastung: ich habe es an einem betagten Powerbook mit 877MHz getestet; daher die relativ hohen CPU-Belastungen.



Clock-Generator, Adapter und Filter schlagen mit insgesamt 4,3% zu Buche; nun der Vergleich mit dem Audio-Eingang: 8,2% - das ist deutlich!



Als letzten Versuch ändern wir mal die Frequenz des Clockgenerators auf höhere Frequenzen:

10000Hz : 1,2%
20000Hz : 4,4%
40000Hz : der Eventausgang des Adapters hat schwer zu arbeiten 10,1%.

Interessanterweise (besser logischerweise) bleiben alle anderen Belastungen gleich, da es sich ja um Event-Eingänge handelt!

Als beste Möglichkeit ist in der Tat das (optimierte) AtoE perm-Modul, wenn man es mit den entsprechenden Frequenzen laufen lässt (hier bei 2000Hz):



So lieber helmsklamm, jetzt hast Du genügend Material, um das ganze für Deine Zwecke auszuprobieren. Bitte lasse diesen langen Beitrag nicht ins Leere laufen und probiere es wenigstens aus
Zu guter Letzt wirst Du sicherlich noch die Frage aufwerfen, warum dann Gerald diesen Event-Ausgang erfunden hat, wo doch das AtoE perm Modul viel effektiver arbeitet.
Gerald Adapter ist sehr raffiniert, da er aus der AudioCoreCell wirklich nur einen Impuls ableitet, d.h. kommt vorne ein Event hinein und wird in der AudioCoreCell zu einem Event verarbeitet, dann gelangt auch wirklich nur dieser eine verarbeitete Event hinten heraus. Dies ist ein Hilfskonstrukt, solange NI nicht selbst diese Möglichkeit erfindet.
Meine Anwendung in diesem Beispiel ist eigentlich eine Zweckentfremdung, erläutert aber den Zusammenhang zwischen Audio- und Eventsignalen und der CPU-Belastung deutlich.

ciao herw

PS: ich habe mal probeweise hinter den LFO ein AtoE-Modul und statt des Core-Filter ein entsprechendes primary-Filter gewählt: die Belastung war 3,6%.
Eine andere Idee ist natürlich auch noch, dass du das primary-Filter-Modul ebenfalls mit Geralds Adapter und der veränderten Taktung ansteuerst. Dann gibt's aber keinen Vorteil zur CoreCell. Du hättest dann aber bei hoher Taktfrequenz 44100Hz dem primary-Modul einen Audioeingang verpasst - dies ist eher theoretisch interessant.

[helmsklamm]

vilen dank für deine ausführliche antwort.

ich habs 2 mal komplett und teilweise mehrmals durchgeackert - ich glaube wir reden von verschiedenen sachen.

kurze fred-zusammenfassung:

mein ausgangspunkt war, das ich bemängelte das die prim-filter keine audio-res-abtastung erlauben und das die core-pendants deutlich hungriger sind. auch, wenn ich in diesen testweise res auf event schalte und den zusatz-schnicksack entferne und diese also ziemlich 1:1 vergleichbar sind, benötigen diese deutlich mehr saft. soweit der ausgangspunkt.

dann schlug tymes das AEperm vor. damit lässt sich tatsächlich ein eventeingang auf audio "zwingen". allerdiings ist (bei entsprechend schneller FQ, sagen wir 11 000hz) dann die belastung durch ebenjenes modul DEUTLICH höher, als wenn es sich von vornerein um einen audioeingang gehandelt hätte. das AEperm ist also eine krücke, bei nem gebrochenen bein ganz hilfreich, trotzdem ist man mit 2 gesunden beinen entschieden schneller und verbraucht weniger kraft. hier kam nochmal mein bedauern, das es leider nicht vornerein die option gibt, einen eventeingang bei bedarf auf audio umzuoptionen.

da war aber nicht schluss, sondern ich schlug zudem vor diese "options-audio" eingänge mit ner anderen (geringeren) FQ als die globe SR zu takten, was theoretisch perform-vorteile gegenüber der audiotaktung mit globaler SR bieten sollte. (vielleicht bin ich da blauäugig).
ein weiterer gedanke (tauchte bislang noch nicht im fred auf) wäre auch die "invertierung" obigen gedankens, nämlich kritische "sowieso-audioports" auch mit ner höheren SR als der globalen anzufahren. man lässt bspw. NUR sein filter mit höchster SR abtasten, alles andere wird weiterhin mit globaler berechnet. das dürfte klanglich was bringen - und zwar um einige faktoren günstiger als die SR global hochzuschrauben.
ich fass hier nochmal die idee zusammen:
es sollte mehrere SR geben, die bedarf aktiviert werden können. bspw. könnte man dann seine ozzies (stichwort: nyquist) mit 88 000, seine Res aber nur mit 6000 fahren, während alles andere weiterhin mit "globalen", sagen wir 44 kHz berechnet wird.
wahrscjheinlich übersehe ich da jede menge, denn berchnungen finden ja nicht isoliert statt, sondern fussen auf anderen und die ergebnisse sind ihrerseits faktoren für folgeberechnungen, etc.. trotzdem könnnte ich mir vorstellen, das das n ordentlichen schub geben könnte.
hierzu benötigt man EINMAL, an globaler stelle mehrere "clocks", die die unterschiedlichen SR ausgeben müssen und die option in den modulen/ports das zu aktivieren. diese clocks könnten ja sowas wie das AEperm oder n ozzie sein, nur mit dem entscheidenen unterschied, das sie nur einmal vonnöten sind (ergo nur einmal "berchnenet" werden müssen) und für jeden port zugänglich sind. derzeit muss vor jedem, in frage kömmenden port son ding vorgeschaltet werden, was deutlich frisst.
(oder siehst du nen weg, son teil MEHREREN signalen zugänglich zu machen?)

das wäre mein wunsch. ich halte den für sinnvoll und ich sehe leider keine möglichkeit das per struktur zu lösen.
das AE ist in der jetzt-form (bzw. seine multiclient-zugänglichmachung) ne krücke, die mehr kostet als ein von-vornerein-audio-port, das krümelmodul ist für diese zwecke auch nicht geeignet. und schlussendlich ist das "gegenteil", ne bedarfsweise zuschaltbare höhere SR schlichtweg überhaupt nicht machbar. (ausser man denkt völlig um, setzt die globale SR auf höchste, verzichtet komplett auf prim-module und optimiert seine core-cells entsprechend - da diese aber leider viel hungriger sind, dürfte der gewinn ne verlustrechnung sein).

[herw]

ja - mehr weiß ich auch nicht

ich könnte höchstens einen Wunschlisten-Thread eröffnen und weiterleiten.

- obwohl ich denke, dass auch ab und zu einmal einige NI-ler hier hineinschauen, aber so könnte man die Wünsche direkt und gezielt weiterleiten.