Deutsches Reaktor Forum

also, ich poste das mal hier, obwohl es wohl eher in pc/mac gehört, da aber höchstwahrscheinlich plattformübergreifend nun hier.

kennt ihr das auch: ihr habt nen ens mit jede menge sich bewegender grafik (seqeunza, sampler, displays, etc.) euer reaktor-meter zeigt bspw. was um die 30% an, euer window (mac) meter ocsilliert aber zwischen 40 und 60%. erst wenn ihr die ins-fenster auf "minus" stellt gleichen sich die werte etwas an. wenn ihr jetz noch die (statischen!!!!) struktur und toolfenster schliesst sind die werte nur noch minmal different.

ok, wahrscheinlich musss n bissl der grafikberechnung über die cpu laufen, aber alles? wozu is eigentlich die graka da? nur zum daddeln???

frage1:
ich hab ne shared-graka, vielleicht liegts ja auch daran, wie stehts mit "richtiger" graka?

frage2:
is das bei mac ebenso? oder delegiert da das OS dergleichen an die graka anstelle der cpu?

helmsklamm hat geschrieben: frage1:
ich hab ne shared-graka, vielleicht liegts ja auch daran, wie stehts mit "richtiger" graka?

... diese frage habe ich ja bereits beantwortet: ja, shared grafik wirkt sich auf die audio performance negativ aus.
nebenbei: laut aussage von NI wird bei dem CPU meter von R5 auch die grafikleistung mit eingerechnet.
vergessen darf man nicht, dass auch das audio-an-soundkarte leistung benötigt.
standard winXP-tipps:
- power management aus; auch für USB
- leistung für hintergrunddienste (nicht für programme) optimieren.
- allen unnötigen zappel/blink/transparenz firlefanz ausschalten.
kleine anekdote am rande: bei meinem alten notebook hat das (unnötige) animierte icon des touchpads in der toolbar die soundverarbeitung nachdrücklich gestört.

im auge behalten sollte man bei reaktor unbedingt die XY-module, die im "scope" modus sind (d.h. audio anzeigen). je nach system fressen die schon einiges an leistung.

magneton hat geschrieben: nebenbei: laut aussage von NI wird bei dem CPU meter von R5 auch die grafikleistung mit eingerechnet.

also, das kann ich irgendwie nich ganz glauben, im rektor/windows-meter vergleich gibts da signifikante unterschiede, wie is das bei dir?

die standard-optimierungen hab ich natürlich alle gesetzt - da hilft wohl doch nur neue hw

der punkt is aber dieser seltsame über 30%-last-sprung: sobald ein ens um die 30% saft verbrät, kommt es irgendwann unweigerlich (leider nie auf knopfdruck reproduzierbar, aber irgendwann passiert es immer) zu einem cpu-sprung, der je nach vorriger last um die 10-20% (total), oder um 20-40% (relativ) plötzlicher mehrlast bedeutet. es wirkt so, als verblieben irgendwelche berechnungen (die längst abgeschlossen sein müssten) in ner schleife - erst das halbminütige deaktivieren des audio-buttons in der toolbar normalisiert das wieder. ich hab einige kleine - und eigentlich nur event-cores inside, vielleicht liegts ja daran? - aber das kann ich mir eigentlich nich vorstellen.
ich glaube, das ganze passiert wenn mal kurzfristig die 100% cpu erreicht werden (bspw. bei A/B umschalten oder schnellen snap-wexel, die ja auch ständig nen neuen grafikaufbau erzwingen, bzw. einige module an/aus-switchen), reaktor aber dem audiostrom priorität zuordnet und die anderen berechnungen auf "halde" legt und dann erst abarbeitet - aber das is reine spekulation.
ich hatte das ja schon mal in nen anderen fred geäussert und du auch daruf geantwortet, aber dieses verhalten macht mich echt wahnsinnig - jedesmal wenn es auftritt (manchmal erst nach ner halben stunde) beginne ich mit ursachenforschung, die aber leider ergebnisslos bleibt.

helmsklamm hat geschrieben: wie is das bei dir?

da muss ich jetzt doch mal meine formulierungen erklären:
mein satz "nebenbei: laut aussage von NI (...)" ist inhaltlich gleichbedeutend mit Deinem satz "also, das kann ich irgendwie nich ganz glauben"

helmsklamm hat geschrieben:(...)kommt es irgendwann unweigerlich (leider nie auf knopfdruck reproduzierbar, aber irgendwann passiert es immer) zu einem cpu-sprung, der je nach vorriger last um die 10-20% (total), oder um 20-40% (relativ) plötzlicher mehrlast bedeutet. (...)

mir sind solche phänomene leider auch nicht ganz unbekannt.
ich meine, es passiert bei R5 öfters als bei R4; kann es aber nicht belegen. die ursachen sind sicherlich vielfältig und die hardware scheint auch unterschiedlich anfällig dafür zu sein. den möglichen verursacher zu finden ist nicht immer möglich. ich habe mal ein ensemble den ganzen nachmittag laufen lassen (mit vielen zufalls events), und nach vier stunden ist es dann übergelaufen und ich konnte gerade noch meine monitorboxen retten. die ursache war, dass ein diffuser delay durch irgeneine ursache die falschen zahlen bekommen hat. das dumme war nur: das war keinesfalls vorherzusehen. bei snap wechseln kann es auch passieren, dass zu schnell irgendeine operation abläuft, die nur in dem jeweiligen kontext zu problemen führt, weswegen es so schwer ist, da ein prinzip dahinter, geschweige denn einen bug zu finden/definieren.
sehen wir es optimistisch und freuen uns über die "gefährlichkeit" von reaktor...

noch eine kleine anmerkung:
für mich bleiben ein paar fälle bei denen ich sagen muss dass ich da keine erklärung dafür habe. auf der anderen seite habe ich etliches über signalverarbeitung allgemein und die arbeitsweise von reaktor eben durch solche probleme gelernt. also manche probleme konnte ich beheben.
als beispiel möchte ich nennen dass wenn man mit der maus über ein kabel geht vielleicht konstant ein wert angezeigt wird, es aber einen unterschied macht ob der wert nur einmal gesendet wird (also z.b. nur beim ensemble start "0.234" ausgegeben wurde) oder kontinuierlich gesendet wird (das wäre dann bei control rate 400 pro sekunde 400 mal "0.234").
(ich schreibe das als tipp für die vielen anderen die hier auch mitlesen).

he magneton, jetz hab ich echt die fährte delay verfolgt, aber das isses (wahrscheinlich) auch nicht, dafür aber n weg zur "reproduktion" gefunden - nimm zB newscool (v5). gleich der erste snap frisst bei mein alten lap ca. 40%. wenn ich nun 2,3,4 minuten wild an den reglern rumdrehe gibts plötzlich diesen ausreisser und die cpu steigt auf 55% (meistens wenn ich nach ca. 100 anderen reglern den decay behrühre - zufall?).


ich hab mal probehalber den pitchshift (inclusive 4 singel-delays) "rausgedrahtet" und, um in etwa die gleiche grundbelastung zu haben, die engine 4mal dupliziert und neuverdrahtet - aber auch dann passiert es (ich weiß jetz nich, ob im gesamten ens vielleicht noch weitere delays stecken - bei schneller durchsicht hab ich keine gefunden).

1 frage, 1 bitte:
hast du ne idee, wie man schnell nen ens baut, das viel saft verbraucht aber 100% delay-frei is.

würdest du mal newscool (oder bei schnellerer hw vielleicht was vergleichbares) ebenso maltrtätieren, um zu schauen ob das bei dir auch passiert? - denn hätte man zumindest mal ne "spur", und vielleicht bekommt man es ja noch "reproduzierbarer" hín, dann bräcute NI eigentlich nur in die log-file schauen und fixen.

das delay war nur ein beispiel; es kann alles mögliche sein.
audio-feedbackschleifen können zulaufen, das ist auch eine möglichkeit.

CPU fressen? stimmenzahl erhöhen.
alternativ: graincloud sampler. grainlänge möglicht hoch (langes sample verwenden); deltazeit möglichst kurz.

bei newskool konnte ich nichts feststellen; versuche mal den oberen teil mit der grafik auszublenden.

wieviel frisst den newscool bei dir?

ok, ich probiers mal mit ausgebelnedetn sq - vielleicht liegts ja wirklich nur an der graka, obwohl mir das mit den feedbackschleifen irgendwie mehr sinn zu machen scheint - mal schauen.

stimmenanzahl erhöhen - daruf hätt ich auch selber kommen können

also ich glaub ich habs jetzt reproduzierbar: erhöh mal die sample-rate bei newscool so das du auf 50% (reaktor-meter) oder mehr kommst, lass mal das geblinke alles an und ne minute laufen. öffne mal das window-meter (bei mir so ca. 70%) mit dem reiter systemleistung. falls danach noch alles ok is, beweg mal die maus schnell kreuz und quer - also bei mir springt dann irgednwann das window-meter kurz auf 100% und das wars: ab jetzt gibts dann diesen kuriosen, bleibenen performance-sprung in reaktor (auch wenn er jetzt 10 minuten weiterläuft normalisiert es sich nicht, abhilfe erst nach halbminütigen deaktiviern des audio-buttons, aber bei weiderholung der prozedur stets das gleiche).
dasgleiche passiert auch bei ausgeblendeten geblinke, dann muss ich die sample-rate aber nochmal etwas erhöhen oder die maus noch schneller bewegen.


ok, du hast ne richtige graka, deshalb beobachte mal bitte ob bei dir diese schnelle mausbewegung auch derart im cpu-verlauf ansteigt, oder das ganze moderater ausfällt.
falls du es plus mausbewegung nich schaffen solltest auf kurzzeitig 100 zu kommen, erhöh mal bitte nochmal die sample-rate.

wichtig sind 2 sachen: ob bei dir nach kurzzeitigem 100-überschreiten dergleiche effekt auftritt und wie stark wilde mausbewegungen noch zusätzlich deine cpu belasten.

ich hoffe ich nerv nich.

hallo nervensäge,
also mit SR 176.400 steigt newskool aus; processor overload. nach dem heruntersetzen auf moderate werte läuft alles wieder rund; auch bei auslastung zwischen 88 und 97% (reaktor zeigt gelegentlich "over" an.
mausbewegungen haben keinen einfluss (logitec optical an notebook; alle mausspielereien aus).
schwierigkeiten gab es nur, wenn ich die stimmenzahl vom unteren instrument erhöhe, aber das kann man sich denken, da das auf acht fest zugeordnete stimmen (by design) angelegt ist. danach half nur noch die instrumente zu muten und wieder zu de-muten (was live einer katastrophe gleichkommen dürfte, zumindest bei mir).
ich habe übrigens immer ein konfabulator CPU-meter über allen anwendungen mitlaufen (konfabulator wurde von yahoo aufgekauft; ist eine widgets engine). der CPU verbrauch für anwendungen ist identisch mit dem bei reaktor angezeigten wert. hinzu kommt noch der system-verbrauch (meistens soundkarte). ich habe eine m-audio firewire 410, die sehr stabil läuft. zuvor hatte ich eine emagic EMI 6|2; die hat öfters probleme gemacht.
wenn Dein problem sich aus dem zusammenspiel von grafik- und soundkarte ergibt, wird es schwierig werden den wirklichen verursacher zu finden.

ich geh mal davon aus, das konfabulator ähnlich zum win-meter funzt. und wenn dein reaktor- und knofumeter gleiche werte anzeigen, dann schlussfolger ich mal, das bei dir tatsächlich der grafik-verbrauch im reaktormeter berücksichtigt wird.

nur nochmal zur sicherheit: du hast den ganzen grafik-klimbim ausgeklappt, oder? - und wenn newscool ca. 50-60% verbrät (bei ausgeklappten und blinkenden instrumenten), kannst du es dudeln lassen und mausmoven und alles is ok, ja?

dann muss es doch tatsächlich an meiner graka zu liegen. zur verifizierung nochmals eine bitte: bewegt mal deine maus, so schnell wie möglich auf ruhigem hintergrund (deinem nich-animierten explorer oder desktop-bildchen) und zB (wenn du gleich antwortest, im antwortfenster - am besten ozzilierst du schnell zwischen dem bereich wo defaultmässig "schriftfarbe" etc. steht und den smilys.

bei mir is das n graviernder unterschied: mausmove über unbewegte flächen haben spitzen-peaks von 2-4%, moves über animierte sachen rufen bei schneller, intensiver bewegung schonmal umdie 20% hervor.
sehr kurz zwar, aber im cpu-verlauf gibts ne ordentliche zickzacklinie.
und ich glaube diese (durch grafik verursachten) spitzen-peaks werden im reaktor-meter zwar völlig unterschlagen, trotzdem kommts im millisekundenbereich zum overkill und reaktor fängt sich dann aus welchen gründen auch immer, nimmer.

mausspielerein, etc. sind bei mir auch standardmässig deaktiv, aus gründen der präzission bleib ich auch bei kabelmaus über usb (also dürfte das alles flach fallen).

soundkarte, hm, also solang ich nich auftrete oder sample oder... nehm ich immer das onboard teil über asio4all. fehlt zwar deutlich "headroom" is also vglw. schhnell übersteuert, hat aber nich die angewohnheit bei programabsturz gleich alles mitzureissen wie das sch++ss tascam-teil. latenz is ja bei "boxis" sowieso eher schnuppig, jedenfalls knackst das teil nich oder benimmt sich sonstwie kränk. von daher schliess ich das als verursacher auch mal aus. aber ich werd trotzdem nochmal das tascam anklemmen, um ganz sicher zu gehen.

mach mal bitte nochmal den obigen maustest.

tut mir leid, is aber augenblicklich kein weiterer da zum nerven

ohne meister wirds hier echt n bissl ruhig grad - schade dass.

nur nochmal zur sicherheit: du hast den ganzen grafik-klimbim ausgeklappt, oder? -
ja.

und wenn newscool ca. 50-60% verbrät (bei ausgeklappten und blinkenden instrumenten), kannst du es dudeln lassen und mausmoven und alles is ok, ja?
ja.

bewegt mal deine maus, so schnell wie möglich auf ruhigem hintergrund
kein problem.

wenn du gleich antwortest, im antwortfenster
mein musikrechner hängt nicht am netz.

(...) trotzdem kommts im millisekundenbereich zum overkill und reaktor fängt sich dann (...) nimmer.
CPU peaks waren mal ein thema im englischen NI forum; sollte aber mit 5.1 behoben sein.
kann aber sicherlich, je nach system, immer wieder vorkommen.

mausspielerein, etc. sind bei mir auch standardmässig deaktiv, aus gründen der präzission bleib ich auch bei kabelmaus über usb (also dürfte das alles flach fallen).
USB power management?
mach' doch mal ein neues hardwareprofil und deaktiviere alles unnötige (für musik) nach und nach.

nehm ich immer das onboard teil über asio4all. fehlt zwar deutlich "headroom" is also vglw. schhnell übersteuert, hat aber nich die angewohnheit bei programabsturz gleich alles mitzureissen wie das sch++ss tascam-teil.
das kann aber auch eine ursache sein; ich vermeide onboard sound immer, falls möglich.
nutzt Du reaktor standalone oder als VST?
falls letzteres, in welchem host?
die FW410 kann man bei absturz ausschalten und wieder ein, dann ist sie wieder da.
asio4all kann unter umständen die entscheidende leistungsreserve aufbrauchen.
ich würde mir eher mal eine neues audiointerface leihen und schauen, ob die probleme immer noch bestehen.

also ich habs jetz mit dem tascam getestet, es bleibt dabei, bzw. wird es damit sogar noch schlimmer. ich hatte zwar den eindruck, das es länger dauert bis es passiert, aber wenns passiert sinds nich nur 15% (total) mehr, sondern gleich 30%.

also meine theorie is: wenn das gesamte system (bspw. reaktor + grafikneuberechnung) mehrmals in rascher folge die 100% erreichen, "verschluckt" sich reaktor kurz und behält fortan irgendwelche daten in ner berechnungsschleife und erhöt somit die last.
Ich teste das gleich nochmal indem ich zu reaktor irgendwelche anderen programme öffne.

nochmal zum thema graka: was zeigt dein konfu an, wenn du in newscool die ins schliesst und was, wenn geöffnet?

wenn du in reaktor audio ausstellst, was zeigt dann dein konfu an 0% oder "peakt" er "random"-periodisch?

was is mit usb-power-managment gemeint? wo find ich das?

ganz so simpel wie in meiner theorie isses doch nich. wenn ich einfach zwischen A/B hin und herswitche werden ständig 100% erreicht, der verlauf sieht aus wie n rechteck-lfo aber alles bleibt normal. das ganze passiert eben doch erst, wenn irgendwie audio mit im spiel is, am besten ultra schnelle snap-wexel und dann in A/B switch.
also ich geb´s erstmal glaub ich auf.