kurios

[helmsklamm]

ich hab mal wieder ne seltsamkeit zu vermelden, diesmal eine, von der ich mir nicht schlüssig bin ob gut oder schlecht. (obwohl ich mich grad über den fund freue, muss diese "positive" seltsamkeit trootzdem n bug sein).

also mir viel auf, das meine "finale" version fast n mb größer als eine der letzten betas war, obwohl ich in der jetztigen entschieden weniger module als davor hatte.
ich hab also testweise n paar dicke macros hin und herkopiert und irgendwie schien es, das ein und dasselbe macro in verschiedenen versionen unterschiedlich groß ist. also hab ich mal das komplette macroarsenal in ne neue datei eingefügt, (zum glück wurden alle drahtlos-verbindungen korrekt mitkopiert) und plötzlich war das ensemble fast 2 mb kleiner als zuvor. die snapanzahl ist übrigens, da ich n internes snapshot moduel verwende identisch.
nun gut, 2 mb klingt irgednwie angesichts ca. 200 mb samples lächerlich, aber plötzlich startet das teil ca. doppelt so schnell, und bei meiner lahmen "not"book-pladde sind das ca. 20 sekunden weniger

ich will da keinen generellen tipp draus ableiten, aber probiert das mal mit euern teilen aus, vielleicht gibts da auch postive überraschungen. (nich das instrument als ganzes, sondern nur die einzelnen macros als gesamtverbund.)

[KlangRaum]

den effekt kenne ich seit längerem..... ist nicht immer dabei, eher mal abundzu. ich hab aber noch nie drauf geachtet, woran es konkret liegt.
offenbar wird irgendwelcher speicher nicht korrekt freigegeben, wenn man viel hin&her kopiert und löscht.... hin&her kopiert und löscht.... hin&her kopiert und löscht.... etcetc

was braucht alles speicher ?
tables, delay, sample.....

ich schau immer, das ich eine kopierfähige macrostruktur hab.... auch wegen meiner eigenen library

[helmsklamm]

kann es sein,das die falsche speicher"freigabe" auch für seltsame cpu-ausreisser verantwortlich ist?

also, vielleicht kennst du das problem: nimm irgend nen >25% cpu ensemble und duplizire es. danach hast du keine erwartete "skalierung" sondern nen deutlich höheren saftbedarf - woran liegt das????

oder anders gefragt: mein ens verbrät bei neustart ca. 20-25%. nach mehrenen snapwexeln, oder midi-aktionen "peakt" die cpu kurzeeitig!!!! auf 99 oder mehr (normal: mehrere switch on/off), fängt sich aber idR.
manchmal jkedoch (dh bei genügend snapwexeln eigentlich immer) fängt reaktor an zu cpu-"skalieren": dh n snap, der normalerweise nur 25% verbrät, brauch plötzlich 34%..
undwenn ich jetzt wietermodulier/snapwechsel springt es irgendwann nochmal ne dekade + 5 höher - und ich glaube, wen ich das oft genug tuen würde, bekäme ich irgendwnn den overload-screen.
(derzeit dauern meine sessions ca. ne halbe stunde - und wenn ich dann vom 1-snap, durch mehreren stationen/switches/midibefehlen wieder auf ihn zurückkomme brauch einundderselbe snap plögtzlich mehr als doppelt soviel saft als beim neustrat. sowohl im reaktor- als auch im window-meter.
wie an sowas sein? speicher??

[herw]

kann es sein,das die falsche speicher"freigabe" auch für seltsame cpu-ausreisser verantwortlich ist?

also, vielleicht kennst du das problem: nimm irgend nen >25% cpu ensemble und duplizire es. danach hast du keine erwartete "skalierung" sondern nen deutlich höheren saftbedarf - woran liegt das????

oder anders gefragt: mein ens verbrät bei neustart ca. 20-25%. nach mehrenen snapwexeln, oder midi-aktionen "peakt" die cpu kurzeeitig!!!! auf 99 oder mehr (normal: mehrere switch on/off), fängt sich aber idR.
manchmal jkedoch (dh bei genügend snapwexeln eigentlich immer) fängt reaktor an zu cpu-"skalieren": dh n snap, der normalerweise nur 25% verbrät, brauch plötzlich 34%..
undwenn ich jetzt wietermodulier/snapwechsel springt es irgendwann nochmal ne dekade + 5 höher - und ich glaube, wen ich das oft genug tuen würde, bekäme ich irgendwnn den overload-screen.
(derzeit dauern meine sessions ca. ne halbe stunde - und wenn ich dann vom 1-snap, durch mehreren stationen/switches/midibefehlen wieder auf ihn zurückkomme brauch einundderselbe snap plögtzlich mehr als doppelt soviel saft als beim neustrat. sowohl im reaktor- als auch im window-meter.
wie an sowas sein? speicher??

Zwei Dinge sind hier anzumerken:
1. Dass ein File plötzlich kleiner ist als vorher, liegt meistens daran, dass beim Kopieren und Löschen von Makros natürlich noch einiges im Speicher nicht freigegeben ist. Eine wirklich gültige Angabe kann man erst machen, wenn man das ensemble abspeichert, dann R5 verlässt, wieder aufruft, das neue Ensemble lädt und nochmals abspeichert, dann dürfte alles überflüssige beseitigt sein (z.B. doppelt angelegte Bilder).

2. Der plötzlich ansteigende CPU-Verbrauch lässt sich nur durch das speziell vorliegende Ensemble erklären. Die Ursache ist sicherlich nicht eindeutig. Ich vermute mal irgendwelche loops und nicht Beachten des Auftretens denormaler Zahlen. Dann bauscht sich der CPU-Verbrauch auf.

ciao herw

[helmsklamm]

zu 1:

das file war schon gespeichert, reaktor beendet, etc.
erst beim kompletten neueinfügen in leeres ensemble wurde es kleiner - also tatsächlich unnötiger speicher, oder was immer freigegeben.


zu 2:

also es passiert mir grundsätzlich mit jedem ensmble (gut, ich hab nich alle getetset ), die ertsmal die cpu-"erfordernisse" erfüllen. also auch ganz alte, definitiv ohne core. und in den prim-modulen wird NI ja wohl penibel auf die vermeidudung denormaler geachtet haben.

was meinst du mit loops? eventloops hab ich keine mehr (glaub ich) aber jede menge delays und so - vielleicht deswegen?

[herw]

zu 1:
...zu 2:

also es passiert mir grundsätzlich mit jedem ensmble (gut, ich hab nich alle getetset ), die ertsmal die cpu-"erfordernisse" erfüllen. also auch ganz alte, definitiv ohne core. und in den prim-modulen wird NI ja wohl penibel auf die vermeidudung denormaler geachtet haben.

was meinst du mit loops? eventloops hab ich keine mehr (glaub ich) aber jede menge delays und so - vielleicht deswegen?

keine Ahnung, da ich dein ensemble nicht kenne, muss du selbst erforschen. Manchmal dauert es einige Zeit, bis man durch systematisches Aussparen von Makros (Überbrücken) dahinter kommt, wo der Hase im Pfeffer liegt.

[helmsklamm]

ums nochmal klarzustellen: dieser effekt tritt bei mir mit JEDEM ensemble auf. zumindest bei allen mit seqeunzer und die grundlegend schonmal mindestens 25% (reaktor-cpu) brauchen. selbst das r3-newsscool (definitiv kein core) verhält sich bei "ausreichender" SR genauso: n paar snapwechsel, n paar midi befehle, n paar knobdreherein und schwupps peakt das teil um30- 40% relativ zum ausgangswert hoch und bleibt dort, bis zum halbminütigen deaktivieren der audioengine. dann wieder normal - bis zum nächstenmal.

[helmsklamm]

also, ich hab das jetzt mal mit herws moog 223 probiert - und auch hier tritt der effekt auf: snap 1 "breath" verbrät bei mir ziemlich exakt 20% nach öffnen und genauso viel nach ca. 30 schnellen snapwechseln, nach ca. 50 snapwechseln (innerhalb einer minute, oder anderthalb) waren es 28%, was in etwas 40% relativ dem ausgangswert entspricht. erst nach deaktiviern der audioengine normalisierte sich der wert wieder.

also: eventloops sind nicht der verursacher, die sind dort disabled. core ist mE auch nicht der schuldige - ich hatte das prob eigentlich auch schon mit meiner "demo" 4er-version, eindeutig ohne core.
ich halte switches für einen indirekten mitverursacher, weil hier die cpu zwar nur sehr kurzzeitig, aber doch ziemlich gestresst wird. sie alleinig sind aber niocht der grund: ich hab mal bei mir alle switches, bzw. die macros gemutetd - es dauert dann zwar länger, aber irgendwwann tritt der effekt trotzdem ein. ich vermute ja eher, das die envelops oder ähnliche sachen, die, wenn man sie lässt, in reaktor bis zum jüngsten tag laufen, sich irgendwie in die quere kommen, und irgendwann "stimmt" die konstellation: zuviele switch-ons, zuviele redraw-befehle, die cpu is ne nanosekunde über 100 - der/die hüllkurven kommen ins schlingern und bleiben in ner schleife hängen. kann das sein?

vielleicht its es auch meine kiste, aber was? die shared-graka? mein dürftiger 128k-L2 cache?? --- die mindestanforderungen sind trotzdem erfüllt.

[herw]

also, ich hab das jetzt mal mit herws moog 223 probiert - und auch hier tritt der effekt auf: snap 1 "breath" verbrät bei mir ziemlich exakt 20% nach öffnen und genauso viel nach ca. 30 schnellen snapwechseln, nach ca. 50 snapwechseln (innerhalb einer minute, oder anderthalb) waren es 28%, was in etwas 40% relativ dem ausgangswert entspricht. erst nach deaktiviern der audioengine normalisierte sich der wert wieder.
...

ey - erstens heißt meine Maschine MODULAR MINI 2 und zweitens kann ich soviel snap-Wechsel machen wie ich will, die Perfomance bleibt bei 15,3%.
Also liegt es an den Dosen. Reaktor reagiert wohl auf verschiedenen Plattformen unterschiedlich. Bei den Macianern gibt es auch so einige Krücken-Ensembles, die nicht gut laufen.
Ich habe den Eindruck, dass auf PCs Grafik-intensive Ensemble Schwierigkeiten machen.
Vielleicht liegt es an der Verwaltung des Speichers. Wie viel Speicher hast Du denn auf deiner Maschine? Bei mir sind es 4GB.

ciao herw

[helmsklamm]

ich prüf das die tage mal auf ner andern kiste, mit echter graka und mehr L2/ram.