seltsames cpu-phänomen

[helmsklamm]

ich weiß nich genau wie, aber manchmal passiert es, das reaktor die cpu-auslastung "skaliert":
Bsp: flatblaster2 nimmt bei mir "standalone" ca. 10%.
wenn ich aber exakt dieses .ins hinter nen andres hänge, das ca. 30% verbrät, dann is die summe nich 40, sondern um die 60%. und falls ich jetzt noch in beiden .ins snaps wechsle, wächst das ganze nochmals um 20%.
selbst wenn ich jetzt flatblaster delete verbleibt die auslastung bei 50% - erst n kompletter neustart des ursprünglichen .ens normalisiert die werte wieder.

flatblaster is übrigens nur n bsp, das gleiche passiert auch mit anderen ins, oder macros. vielliecht kennt ja jemand diseses phänomen, oder noch besser - hat ne erklärung/lösung?

[magneton]

ich kann nur auch feststellen, dass man den CPU verbrauch nicht einfach addieren kann; es hängt, wie so oft, alles mit allem zusammen. je nach dem, wie die signalverarbeitungskette angelegt ist, verbrauchen manche module/instrumente unterschiedlich viel leistung. die angezeigten werte in reaktor sind auf jeden fall nicht als *absolute* werte zu sehen, eher als ungefähre hilfestellung.
das thema wurde auch mal kurz im NI forum behandelt.
jedenfalls kann es in R5 unter umständen passiern, dass der CPU verbrauch in einem ensemble ohne reproduzierbaren grund sehr stark ansteigt (bis zum overload) und nach einem neustart bei identischen einstellungen nichts dergleichen passiert.

was anderes ist es bei den snapshot wechseln. je nach aufbau des instrumentes kann ein anderer snap erheblich mehr leistung verbrauchen, das liegt in der sache an sich. so wirkt sich z.b. beim "grain cloud" modul die grainlänge und die deltatime direkt auf die benötigte leistung aus und kann u.u. jedes system zum overload bringen.

[helmsklamm]

ich pflichte dir bei, das unterschiedliche snaps unterschiedlich saft benötigen und das das reaktor-meter eher ne lupe denn ein nanosscope ist;)

aber ich rede hier nich von messungenauigkeiten oder einem mehr/minder "vernachlässigbaren" aufpeppen der last.
was ich meine, ist ein dermassen gravierender cpu-last anstieg, das ich mir das mit nichts erklären kann, ausser ner bug-vermutung.

ok, ich MUSS in meinem ens eventloops zulassen, vielleicht hängt das ja damit kausal, stichwort: speicherüberlauf? - obwohl, wenn das seperate .ins sind?????

diese beobachtung hatte ich übrigens schon in v4 - aber damals war das ganze proggi für mich total neu und ausserdem n crack;)
mein jetziges is artig registert und ausserdem glaub ich nach nem jahr intensiv-kur zumindest etwas zu verstehen - und trotzdem.

gut, das man das vielleicht nich einfach addieren kann ok, aber ein so signifikanter anstieg (teils das doppelte der "standalone"-ins)???

aber danke für die antwort.


athlon xp-lap/ windoof sp1

[magneton]

unterschiede standalone/plugin sind bisweilen auf unterschiedliche einstellungen bei der "control rate" zurückzuführen.
bei meinem setup (reaktor als VSTi in energyXT) verbraucht die plugin version ca. 3% weniger CPU (referenz: 2.6 GHz P4 mobile), warum auch immer.

eventloops sind bei mir immer an (sonst würden 95% meiner eigenen .ens nicht laufen); sind die event loops "schalmpig programmiert" führt das schon zu überläufen, meistens aber nicht; die warnung im handbuch halte ich für übertrieben.

ich mache derzeit ein paar versuche um die CPU-last zu reduzieren. dabei habe ich festgestellt dass ein reverb als seperates instrument (1 stereo in) 3.5 bis 5.1% verbraucht; als macro in ein instrument eingebaut (nach dem "audio voice combiner") dagegen konstant um die 2.6%.
weitere merkwürdigkeiten:
ich habe ein live setup mit sechs instrumenten, die verbrauchen durchschnittlich 77%. ein instrument in seperatem ensemble verbraucht 11%. wenn ich die beiden kombiniere, komme ich nicht auf 88%, sondern auf ca. 82%, obwohl noch ein zusätzlicher mixerkanal hinzukommt.

[magneton]

ergänzung:
in R5 wurden ja auch die eventverarbeitenden module in die CPU-anzeige mit aufgenommen. manchmal verbraucht ein LFO (mit nachgeschaltetem stepfilter, aber auch ohne) unproportional viel leistung, obwohl er mit contol rate 100 Hz läuft.

[herw]

...eventloops sind bei mir immer an (sonst würden 95% meiner eigenen .ens nicht laufen); sind die event loops "schalmpig programmiert" führt das schon zu überläufen, meistens aber nicht; die warnung im handbuch halte ich für übertrieben.
...

arrgh, event loop sollte man verbieten. Ich schalte sie grundsätzlich aus und alle Ensembles, die diese benutzen, schaue ich nicht mehr an.
Meiner Ansicht nach gibt es keinen Grund, überhaupt solche zu benutzen. Man muss zwar ein wenig über die Vermeidung nachdenken, doch dann gibt es keine Crash-Probleme mehr.
Bisher habe ich alle eventloops umgehen können.
Aber vielleicht gibt es ja Beispiele, wo ein eventloop nicht zu vermeiden ist?
ciao herw

[helmsklamm]

@magneton: nun, in deinem falle sind die merkwürdigkeiten ja eher auf der haben-seite zu verbuchen;-) trotzdem seltsam, seltsam, das!
ich nutze EFOs (auf eventebene arbeitende modulatoren), keine LFOs.

@herw: ich nutze patterns pro snap, mit seperaten einstellungen der knobs, etc.. diese hängen an nem snaparray und n paar weitern modulen, am ende n IC send, um die aktuellen pattern-daten dem knob/etc. zu senden. ergo eine menge eventloops, die aber noch NIE randaliert haben. für eine bessere idee wäre ich trotzdem aufgeschlossen.

[herw]

...@herw: ich nutze patterns pro snap, mit seperaten einstellungen der knobs, etc.. diese hängen an nem snaparray und n paar weitern modulen, am ende n IC send, um die aktuellen pattern-daten dem knob/etc. zu senden. ergo eine menge eventloops, die aber noch NIE randaliert haben. für eine bessere idee wäre ich trotzdem aufgeschlossen.

Tut mir leid, unter "ich nutze patterns pro snap" kann ich mir nichts vorstellen. Kannst Du mal etwas deutlicher erklären - eventuell ein Beipiel angeben; nutzt du sequenzer?
Mir ist auch nicht klar, wieso man beim Senden von aktuellen Daten an Regler einen eventloop braucht.

ciao herw

[magneton]

Bisher habe ich alle eventloops umgehen können.
Aber vielleicht gibt es ja Beispiele, wo ein eventloop nicht zu vermeiden ist?
ciao herw

... ja, die gibt es...
ich denke schon, dass wir beide völlig unterschiedliche ensembles bauen...
nebenbei: der eventwatcher von chris list verursacht auch eventloop warnungen...

[helmsklamm]

@herw: jau, ich nutze seqenza, als basis diente mir L3 aus der NI-Lib (obwohl ich ihn als "klassichen" groovebox-sq ummodelte). Dieser sq bzw. die gesamte architektur bietet die möglichkeit für verschiednenste parameter "patterns" pro snap zu speichern. JWH nutzte mausareas als panel-controll, die ich aufgrund der midifizierbarkeit mit "echten" knobs ersetzt habe. die basis bleibt aber die gleiche: knob (oder mausarea) sowie ein pattern#-IN an einem merge. dieses führt in ein snapvaluearray. das SVA gibt nun, im falle des pattern# den aktuellen wert an das "abwärtsliegende" send, welches ebendiesen an den knob zurücksendet (eventloop), auf das dieser seine position entsprechend korrigiert.
wie gesagt, funzt anstandslos, trotzdem: ich bin immer für alternativen aufgeschlossen.
(sind noch andere module (order, compaire,etc) im spiel - ich mach vielleicht ma am besten nen screenshot - wie war das hier mit dem format und dem laden??)

[helmsklamm]

ich galub den grund für die plötzlichen cpu-ausreisser beim snap-wexel gefunden zu haben:
also, ich hab verhältnissmässig wenig ram (512), wovon die graka schon 64 klaut und das OS is auch nich zimperlich. mein ens nutzt viele samples (über 100mb). bei geladenen ens zeigt mir das windows-meter ca. 100 mb verbleibend an. wenn ich nun sehr schnell, sehr viele snaps wechsle, wird das ram immer weniger. wenn ich mir zeit lasse, tankt es sich wieder etwas auf, aber bei zu schnellem wechsel unterschreitet es wohl eine kritische schwelle, die bei mir bei ca. 95 mb liegt. dann kommt es zu dem signifikanten ansteig von plötzluich 20% cpu-mehrverbrauch. wenn ich nun die audioengine für ne minute "mute", is wieder alles normal.
aber ich beobachte weiter.

[magneton]

(...) mein ens nutzt viele samples (über 100mb). (...)

welche sampler module sind das?
ich hatte in R4 keine probleme mit 300MB großen sample maps in "resynth" und "graincloud" - in R5 scheint irgend etwas anders zu sein bei samplermodulen, die die samples analysieren. ich habe alle samples im batchmode analysieren lassen, aber da scheint es probleme zu geben; bei schnellem samplewechsel scheint eine erneute analyse stattzufinden. das dürfte nicht passieren, da alles im RAM abgelegt sein sollte.
ich bin aber noch am problem eingrenzen.

[helmsklamm]

der beatloop-sampler.
ich hab heut mal testweise eine bank "gelöscht", so dass ich selbst bei schnellstem snap-wechseln immer mehr als 120mb verfügbaren ram behielt, und siehe da: das prob trat nicht auf.
aber fehler zu reproduzieren kann manchmal schwerer sein, als sie zu beheben - und meist kommen sie dann völlig unerwartet, deshalb bleib ich einstweilen noch auf meinem hochsitz;)

[helmsklamm]

leider war das ram doch nich der entscheinde punkt. -> das problem tritt zwar in letzter zeit "seltener" auf, aber es kommt so sicher, wie die armen in die kirche.
ich geh jetz mal etwas konkreter auf mein setup/das problem ein: also, ich hab ne groovebox, 32 stimmen für die seqeunzer, n haufen sampler (in mono), sowie diverse effekte, achja, es nutzt eventloops. alles in allem nimmt das teil (in sich geschlossen, also nur mein .ins) um die 30% auf meinem alten lappi. das variiert nartürlich pro snap, wenn alle filter aus sind, sinds 10% weniger. und bei stehendem seqeunzer nochmals minus mindestens 5%. der punkt ist, das die cpu-werte "in sich" völlig nachvollziehbar, bzw. vorhersagbar, bleiben. ich kann stundenlang rumjammen und wenn ich zu snap 7 wexel, verbraucht er die gleichen 27% wie ne halbe stunde vorher.
sobald ich aber ein anderes .ins einfüge beginnen die merkwürdigkeiten. in meinem aktuellen fall ist es das graindealy aus newscool V3 (btw: einer der besten effekte die ich je gehört habe). aber versteifen wir uns nicht darauf, das gleiche phänomen tritt auch mit anderen .ins auf, wie bspw. flatblaster oder anderen.
wenn ich jetzt das graindelay einfüge, steigt meine last um ca. 18% im ruhemodus. das ist die erste seltsamkeit: das original-ens benötigt insgesammt (mit 4 drum-synths und nem einigermassen reverb) nur 20% (=ca. 10% fürs graindealy) im standby. schalte ich im original newscool allerdings den seqeunzer ein, springt dieser wert schnell über 30% - in meinem .ens erhöht er sich nur um vglw. moderate ca. 5%. doch das nur am rande.

das hauptproblem ist folgendes: wenn ich ne zeitlang mit meinem teil plus graindelay rumjamme, explodiert förmlich die cpu: anstatt wie vorher (bei den hungrigsten snaps) 50% habe ich nun über 70%. nun kann ich das graindealy muten oder alles andere, oder snapwexel, oder was auch: es bleibt ein RELATIV erhöhter cpu-wert um ca. ein viertel. selbst ein ensemble-neustart hilft nichts, und selbst der komplette reaktor-neustart hilft, wenn zu schnell hintereinander ausgeführt, ebenfalls nichts. JEDOCH:reicht es reaktor für mindestens 20sekunden auf standby zu setzen (standalone- mittels des cpu-schalters). danach frisst das ens genausoviel wie vorher, bis... tja, bis nach 2 oder 41 minuten das spiel wieder erneut anfängt.

wie gesagt, ich kann mir einfach keinen reim drauf machen: läuft mein ins alleine, is alles supi, auch nach 4 stunden dauerbelastung. kommt nen anderes ins hinzu, tritt unweigerlich dieses prob auf. manchmal nach ner halben stunde, manchmal schon nach 3minuten.
sowohl mein .ins als auch graindealy nutzen eventloops, mein teil hat 32 stimmen, graindealy 7. achja, in meinem isn sind n paar core-macros (im uralt graindelay natürlich nicht), aber fast ausschliesslich aus der NI-lib (also sollten sie funzen, oder?), allerdings hab ich alle "optimiert" also unter umständen auch mal nen stepfilter oder so zu voreilig entfernt???? - doch wie gesagt, tritt dieses prob erst in verbinung mit andren .ins auf.

[magneton]

ähnliche erfahrungen: je nach konstellation unvorhersehbares verhalten, das es bei R4 nicht gab.
man muss aber immer die signalkette als ganzes betrachten; fügt man ein neues teil (instrument oder macro) ein, ändert man die kette an sich; hat einen ganz anderen fall. ich befürchte, dass man damit leben muss.

n.b. wie sind die graindelays denn eingestellt? ich meine buffergröße und interpolationsmethode.