man darf ja nicht vergessen: zum schluss kommen 16bit integer in unsere ohren ....evtl. mit etwas analogem verstärkerrauschen gemischt.
okay.... ist vielleicht nicht so ein ganz passender vergleich
aber jede noch so schöne fließkommageschichte ist im untersten stockwerk schnödes binärzeugs, nur merken wir user da oben an der gui nicht viel davon.....
aja, so kann mans verstehen, insbesondere die tabelle war sehr hilfreich - danke.
trotzdem bleiben natürlich restfragen: was meinst du damit, das reaktor generell in float rechnet, oder ginge sowas prinzipiell anders? - ne hüllkurve fällt ja nunmal von 1-0 und arbeitet dann übern langen zeitraum mit tiefen floats - und es würde ja keinen sinn machen, die auf erst auf 100000 - 1 zu skalieren und dann hinten entsprechend zu dividieren, weil dann ja wieder floats rauskämen, oder?
es macht also auch keinen sinn, seine knobs hart auf integer zu stepsizen, weil sie ja idR mit float-werten rechnen, also is ja die ganze operation float. oder gibts nen unterschied, ob 2 werte in float vorliegen und einer in integer?
und abschliessend: hat man jemand von euch 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?
(und jetz nich sagen: richtges modularsystem frisst immer mehr, oder so: die ganze NI palette sind schon ziemliche ressourcen-sauger und ich vermute da is auch überall die gleiche engine drin.)
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
Das Urteil darüber, ob eine Verarbeitung von ganzen Zahlen und abschließender Normierung effizienter ist als das sofortige Rechnen mit Fliesskommazahlen ist durch die Rechnerstruktur, den Programmiercode und das speziell vorliegende Problem bestimmt.
Du kannst nicht ohne tiefe Einblicke in die speziellen Rechnungen generelle Aussagen darüber machen, was denn "natürlich" effizienter ist. Papierrechnungen und Computerrechnungen sind grundsätzlich verschiedene Arbeitsprozesse (ich meine damit nicht das Medium, sondern die Strukturierung des Problems und dessen Lösung).
Ich benutze zum Beispiel für alle meine Bedienelemente nur ganze Zahlen (meist handelt es sich ja sowieso um Maus-Areas) und normiere erst am Ende bei der numerischen Anzeige. Viele Fallunterscheidungen und Anzeigen von Multipicture- und Multitext-Elementen gestalten sich dann viel einfacher.
zu REASON und CPU-Verbrauch: bitte neuen Thread eröffnen oder in einen anderen Thread gehen (CPU-Verbrauch oder so ähnlich)
....evtl. mit etwas analogem verstärkerrauschen gemischt.