helmsklamm hat geschrieben:ein unbefriedigender denkanstoss zur EIN instrumenten lösung:
du baust dir deine 16 sound-macros und klemmst EIN gate/pitch/etc. jeweils an einen router.
nei... keine 16 soundmacros(instruments)... sondern nur eines. das ist ja grade der gag an der sache.
den akt mit 16macros und dem router kannste dir in diesem fall sparen... einfach 16mal das instrument laden, die kanäle einstellen und fertisch...
neeeee...... ich überlege eigentlich in folgendem ansatz: wenn ein instrument bei zb 4 stimmiger polyphonie 10% cpu benötigt, dann braucht es bei 8 stimmen idr keine 20%.... weil eben reaktor das ganze ressourcenschonend abwickeln kann. der ansatz ist dann einfach, das
ein klangerzeugender kern - also
ein macro/instrument unterschiedliche sounds ressourcenschonend erzeugt....anstatt mehrere unabhängige synths, die zusätzlichen cpu-overhead mitbringen. jeder bessere hw-synth
(hw = hardware) 
kriegt so ne dynamische verteilung hin.... warum auch nicht reaktor?
man muss mal diesen gedanken konsequent weiterdenken: die soundverwaltung auf dem üblichen weg via snaps&co dürfte dann so vermutlich nimmer so einfach laufen. vermutlich müsste man das bedienfeld als reinen dummy auslegen, bei dem dann alle elemente per CC an die klangerzeugung weitergegeben werden.
sagen wir mal, wir haben 16 kanäle und wollen pro kanal maximal 4 stimmen erzeugen... macht 64 voices.... bei 8 sinds 128 und bei 16 stimmen (dürfte als maximum ausreichen...) sinds 256. es müsste möglich sein, das in solchen schritten runterzufahren, um damit auch die cpu-last zu senken.
es gibt prinzipell 2 möglichkeiten zur stimmverwaltung:
vollkommen dynamische zuweisung: ...wobei ich jetzt schon etliche hürden speziell bei reaktor sehe, wenn es um die feststellung eines prozessende (zb release fertig) geht, damit die neuen soundparameter für einen anderen klang geladen werden können. das umzusetzen wäre vermutlich erstmal ziemlich buggy&nervtötend....
feste statische verteilung scheint mir derzeit einfacher: zb pro kanal 4 stimmig - dann wäre stimme 1-4 dem kanal 1 zugeordnet... 5-8 auf 2.... etcetcetc....
man müsste also nur noch durch entsprechendes routing die einzelnen ...nennen wirs mal SLOT(s)... ansprechen... was ja kein prob darstellt.
komplizierter wirds aber auch hier mit den bedienelementen btw der soundverwaltung
hier folgender ansatz: jeder knob/schalter sendet midiCC (was nebenbei noch einige vorteile bringt, das aber später), die für einzelne slots in einem array gepuffert werden und bei einer soundänderung in die slots geschrieben werden. das bedeutet aber auch, das maximal 128 (abzüglich reservierter sonderfunktionen) bedienelemente möglich sind. weiterhin bedeutet das, das die gesamte gui in einem gesonderten instrument untergebracht ist.
*mal nen strich drunter*
meine überlegungen sind noch lange nicht an einem umsetzungsfähigen punkt angelangt.... es ist einfach nur ne idee, die seit langem rum schwirrt. ich bin auch sicher, das da evtl noch viele wenn&aber auftauchen.
vielleicht ists auch derzeit noch garnicht umsetzbar, weil die durchschnittliche cpuleistung erst ausreicht, wenn jeder rechner 16 quad-cores
hat......