Seite 1 von 1

is die NI engine ineffizent programmiert?

Verfasst: 14. August 2006, 12:40
von helmsklamm
hat man jemand von euch mal mit reason rumgespielt? jaja, ganz recht, vergleichbare sachen klingen in reason schon etwas dünner als in reaktor, aber mit 20 fx dahinter kriegst du selbst mit reason nen oberamtlichen klang - und die cpu bewegt sich dabei kein millimeter weiter.

was ich sagen will: es is so unglaublich effizient programiert, (also ich schätze mal faktor 100) das das an magie grenzt. also wenns das 1-3fache wäre, könnte man bei NI schlampigkeit vermuten, aber sowas? die müssen doch irgendwas grundlegend anders machen um diese unglaubliche effizienz zu bekommen. aber was?

definieren die "denormal" schon viel eher?
also ich hab mal nen numeric hinter ner hüllkurve gehängt und bei dcy/relase 80 war nach 15 minuten klangloslassen (und ca. 14eindreiviertel minuten, nachdem definitiv NIX mehr zu hören war) das numeric noch am zappeln, also wurde da immer noch (sinnloserweise?) gerechnet.

Verfasst: 14. August 2006, 18:43
von KlangRaum
eine funktion wie zb -> X (n) = X (n-1) / Y oder -> X (n) = ( X (n-1) + X (n-2) +X (n-3) ..... ) / Y geht uU. bis zum st. nimmerleinstag und kommt nie auf null

sind die hüllkurven evtl so ausgelegt, das es zunächst keine definierte *endbedingung* gibt? ist der umgang mit denormal überhaupt schon in früheren versionen umgesetzt oder ist das jetzt neu?
ich nehme mal an das hier auch aus kompatibilitätsgründen diverse altlasten mitgeschleppt werden. dh. da werden mit sicherheit etliche subroutinen bei jedem clock angesprungen und laufen ohne prüfung stur durch, egal ob sie benötigt werden oder nicht (könnte man ja mit CORE anders lösen)
mir fallen jetzt auf anhieb auch keine sachen ein, bei denen die cpulast zum pauschal *ende_des_tastendruck* nachlässt wie bei absynth, mal abgesehen von einigen wenigen komplexen schaltungen

ich denke aber auch, das man reaktor nicht unbedingt mit reason vergleichen kann - eben wg dem modularen prinzip nicht.... evtl eher mit synthmaker, dafür hab ich jedoch keine vergleichswerte

mal nebenbei: das ganze ist aber imho auch wieder ein argument dafür, gewisse sachen als linearen vorgang mit integer zu berechnen und dann nach float zu wandeln btw per kennlinienfunktion anzupassen... integer kennt keine rundungsfehler

Verfasst: 14. August 2006, 18:59
von helmsklamm
also das argument "modular" scheints nich zu sein, battery oder kontakt sind auch enorme schluckspechte, und ich glaube das fusst alles auf dergleichen engine.

also ich warte wirklich schon mit hochsapnnung auf deine ersten corecells.

(lass dir aber ruhig zeit und mach das leiber hochoptimiert, anstelle schnell, schnell).

Verfasst: 14. August 2006, 19:06
von helmsklamm
achso, zu integer vs float hat ich nochwas im mathe-fred, schau da bitte nochmal.

Verfasst: 14. August 2006, 19:58
von KlangRaum
helmsklamm hat geschrieben: (lass dir aber ruhig zeit und mach das leiber hochoptimiert, anstelle schnell, schnell).
mein reaktor glüht schon und mein kopf raucht.... ;)
ich bastel ja an dieser FM-opl geschichte rum, und da sollen auch angepasste RAMP-ENV's rein....

Verfasst: 14. August 2006, 20:01
von herw
KlangRaum hat geschrieben:
helmsklamm hat geschrieben: (lass dir aber ruhig zeit und mach das leiber hochoptimiert, anstelle schnell, schnell).
mein reaktor glüht schon und mein kopf raucht.... ;)
ich bastel ja an dieser FM-opl geschichte rum, und da sollen auch angepasste RAMP-ENV's rein....
vielleicht kannst Du damit was anfangen:
PROGRAMMABLE ENVELOPE v1.1

ciao herw

PS: Mucke machen nicht vergessen ::key::

Verfasst: 14. August 2006, 22:01
von helmsklamm
KlangRaum hat geschrieben:
mein reaktor glüht schon und mein kopf raucht.... ;)
solange BEIDES in der spezifizietn range bleibt, wieter so!
ich warte gespannt, aber nich ungeduldig!

Verfasst: 14. August 2006, 22:21
von KlangRaum
helmsklamm hat geschrieben: ich warte gespannt, aber nich ungeduldig!
wartma.... is gleich ferdisch :!:
corecell.gif
soooooo.... greift zu, leut......

Verfasst: 15. August 2006, 00:06
von helmsklamm
ich präferier ja eher bitter und scharf :wink:

nee, im ernst: ich habs noch nich gedwnt/testet, deshalb: kannstu kurz mache erklärung hier: wieso, weshalb,warum?


trotzdem schonmal vorab-danke.

Verfasst: 15. August 2006, 11:38
von helmsklamm
ich schnall den joke nich :?

Verfasst: 15. August 2006, 19:39
von sternenkrieger
na jetzt siehste mal wie es uns immer geht ;)

Verfasst: 25. August 2006, 01:19
von helmsklamm
das "modul" hinten is das core-merge "modul". oder?

haha!
ok, rück zum thema:

ich spiel ja nu mittlerweile immer öfter mit synthmaker rum, und tatsächlich, nach meheren stunden rumprobieren, is slebst dat teil (welches entrschieden "modularer" - wenn man mal core aussen vor lässt, als reaktor is; abwer mit eigenem echten code wohl noch tiefer geht) signifikant cpu-freundlicher als reaktor.

(ok, dat teil kämpft derzeit noch mit nem heftigen grafik-bug, der die cpu bei simplen knobdrhen oder jeder belibigen oberflächen-neuzeichnung schonmal zum kochen bringt - mehrere "oberfächen" sequenzer sind bis zum fix erstmal nich zu machen, doch davon abgesehen->)

die reine engine is entschieden effizienter als die NI engine: nen 3-osci synth, mit filter und delay brauch ungefähr 2-3% bei ca. 16 stimmen*. und, sobald keine taste geschlagen und das delay ausgespielt hat, sinkt alles auf 0,4 -permaneter, automatischer "bypass".
(bin nich sicher, das filter "schliesst" nich komplett, villeicht 6 oder 12db -egal, es klingt aber entschiden besser, "analoger" als sämtliche NI-filter - bei mdulationen is dat ding n echter kämpfer, es "zwitschert" oder "wärmt" das es einfach spass macht, ohne tausendfaches nach-"modulen".)

zum vergleich: nen absolut leeres reaktor-ins verbrauct bei mir mit 1 stimme 0.5 und mit 4 stimmen 0.9%. da is wie gesagt noch nix drin!!!!

bestücke ich es wie im synthmaker-bsp. komme ich schon bei mono/einer stimme auf ca. 3-4 prozent (permanent, "relativ" unabhängig von geschlagnen tasten) bei höhrer voices steigt das alles unausprechlich (jedes +4 verdoppelt ca. die last).

fazit: da es andere sher gut hinkriegen, ne modualre soft viel effizienter zu programmieren, (und auch OHNE klangeibußen) sollte NI sich hier echt mal zeit nehmen ihre engine zu überarbeiten - und das sind keine "messungenaugkeiten" von denne wir hier reden, sondern welten-unterschiede (teilweise faktor 10 und entschieden höher!!!).


*synthmaker scheint die anzahl "voices" relativ egal zu sein und in der tat, klingt reaktor mit mehr voices erstmal besser. allerdings gibts in synthmaker son pitch/detune modul, das man hintendran einfach in die hauptausgänge stöpslet und schon klingt auch hier alles viel, viel fetter - jedoch bleibt die cpu davon relativ unberührt (höchtens im cent- bis dezimalbereich).

Verfasst: 14. September 2006, 13:50
von PrinzThomas
Dass Reason Module wie Subtractor oder Malström quasi nix an CPU Last erheben bleibt für mich auch ein ewiges Rätsel!
Scheinbar hat es Propellerheads doch geschafft ein Wunder zu programmieren.
Ich bin mir sicher, dass die Engine von Reason eine andere sein MUSS als die von NI.
Das würde sich sonst widersprechen!

Verfasst: 29. September 2006, 22:02
von helmsklamm
aber nich nur propeller -auch abelton weiß irgendwie besser zu coden. (und imn vergleich zu propeller dürften die ableton effekte/instrumente, etc. klanglich voll in der gleiche klasse sitzen).

die difference is zwar nich sooo spektakuär, aber durchaus fühl- und messbar. - vergleichbares zeux braucht dort höchstens n drittel des reaktor-saftes. (wenn man bedenkt, das dort prinzipiel alles in stereo ausgelegt ist, wahrscheinlich noch weniger).

bislang sprach ich von "gerade aktiven fx oder instrumten) - ableton hat aber zusätzlich noch nen extremen smart-algho, der weiß, ob n effekt gerade was zu rechnen hat oder nicht.
bei reaktor lwird völlig sinnlos jede ADSR bis ins übernächste millenium oder, bei kontinuierlicher stromzufuhr, noch länger berechnet. * live hingegen (ich mutmaße mal) sagt sich: hey, ab jetzt is definitiv NIX mehr zu hören, also berechnungs-stop. erst bei nächsten wert > -300db machen machen sich die teile an die arbeit. deswegen kann man dort wahrscheinlich mit diesem rack und überlappungsmodus theoretisch hunderttausend effekte gleichzeitig "an" lassen ohne das die cpu stöhnt.
zur berechnung werden immer nur die gerade selektierten hinzugezogen, alle anderen sind zwar wach, aber auf und einsatzwartend, solange aber der meister mit nem neuen auftrag nich die tür öffnet, bekommen sie auch nix zu fressen. da sie sich aber ohne meister-befehl nicht bewegen, verbrennen sie auch keine kalorieren und leben so wohlgenährt wie immer weiter.

anders gesprochen: wieso verbraucht reaktor (kontakt, battery....) bereits im wirklichen "standby", also bspw. nach nem neustart, ohne das eine note geschlagen wurde, bzw. der sq rattert schon saft?
was gibt es zu deisem zeitpunkt bereits zu berechenen? das anliegende signal ist zu diesem zeitpunkt immer kleiner -300 db, also slebst für trainierte hunde nicht höhrbar - warum wird da bereits rumgerechnet? das is macht soviel sinn, wie im strömenden regen seinen rasen zu gießen - kostet nur unnötig wasser und freizeit.

ich hab null ahnung vom coden - aber ich glaube hier liegt prinzipiell einfach nur n gedankenfehler vor: wenn ich etwas nicht höhre, dann brauche ich auch die funktion/berechnung nicht - ergo kann sie deaktiviert werden. so simpel ist das. erst bei schwellwertüberschreitung beginnt die recheneinheit erneut mit der arbeit, bei unterschreitung arbeitet sie alles ab und legt sich danach schlafen.
ich glaube genauso machens die abletions: technisch dürfte das nix anderes als n ditributer sein, und falls zum verdrahteteten Eeingang grad null ( bzw. -300) anliegt, übersetzt der effekt das als schlafbefehl und berechnet, im falle eines 5-sekunden verbs noch 5 sekunden das letzet signal und danach aus die maus - keine berechnung, kein saft.

bei reaktor wird aber, selbst bei kürzesten hihat events noch jahrhunderte die ADSR berechnet - völlig kränk: ausser überstundengeile cpus kann das niemand brauchen

das interesannte in live mit reaktor als vst ist: das reaktor dort als vst zwei grundsätzlich verschiedende cpu-freundlichkeitsstufen bietet:

1. reaktor ist mit seinem "nativen" fenster geöffnet:

hier ist es wurscht ob der host-sq rattert oder nicht, die auslastung beträgt immer die typische reaktor-last

2. reaktor wird nur in der ableton "referenz"-sicht gezeigt:

hier wirds spannend. stoppt der host werden noch n paar sekunden (oder auch weniger als eine sekunde, je nach effekten) abgearbeitet, danach "deaktiviert" sich reaktor (und alle nachfolgenden live-effekte) vollständig und die cpu tendiert gen null. wohlgemerkt reaktor ist weder off noch im bypass, bei host-sq-start is das teil auch SOFORT und vor allem ohne knacken (wie bei switches) zur stelle.

was sagt uns das alles?

* ds kann jeder schnell selbst ausprobieren: einfach nen numeric hinter ein ADSR (oder was auch immer), gut decay und release geben, ne taste schlagen und zuschauen - irgerndwann (10,20 minuten) zeigt zwar das numeric null an, aber bei maus über kabel siehst du wahrscheinlich noch wochen, jahre, jahrtausende später noch berechnungnungen - das ist einfach nur kränk.