core-SVA

[helmsklamm]

leider hat das prim-SVA einen nachteil: es lässt sich zwischen den gespeicherten werten nicht überblenden.

mit core kann man mW prinzipiell wohl n SVA basteln. auch eines das obiges manko behebt? bzw. gibts das schon, weiß wer rat??

achja, wenn wir schonmal dabei sind: kann man dann gleich das teil 0-basiert machen (das ständige plus1/minus1 nervt)???

[herw]

SVA = snap value array ?

mir ist nicht klar, warum du das in core erledigen möchtest.

[helmsklamm]

richtig enkryptet.

ja, warum core? nun, wenn R6 doch noch länger brauch, brauch ich was zum zeitvertreib;)
nee, im ernst: wie oben geschrieben kann das prim-SVA NICHT blenden, sondern nur zwischen den gespeicherten werten jumpen. ich wünsch mir aber die option auch zwischen den werten morphen zu können. mit dem eventtable geht das zwar prinzipiell, allerdings is das speichern etwas umständlich/gewöhnungsbedürftig. darum.

ne monophone event-version (sowohl idx als auch die INs) mit 4 arrays würde mir reichen.
das wär son teil, das mich als reverse-core-workshop (wir legen unsre module tiefer) voll zecken würde.
das gäbe auch stoff für fragen: 4 arrays dürften (sofern ich das verstanden hab) nich mehr als 4x4 bytes veranschlagen (pro stimme schreibt das handbuch - allerdings verschweigt es, ob global oder pro snap??? - doch selbst bei vermuteteen letzteren dürfte es bei 100 snaps = 100x4x4byte nich mehr als 1,6 Kb sein. ein, wie ich glaube völlig illusorischer wert... )

das teil is natürlich kein selbstzweck, zum dank würd ich auch den rest beisteuern - falls ihr bei den stichwörten event/4 noch nicht wisst, was ich meine, dürft ihr gerne rätselraten .

[herw]

richtig enkryptet.

ja, warum core? nun, wenn R6 doch noch länger brauch, brauch ich was zum zeitvertreib;)
nee, im ernst: wie oben geschrieben kann das prim-SVA NICHT blenden, sondern nur zwischen den gespeicherten werten jumpen.

aber du kannst doch die Jumpgeschwindigkeit fürs Morphen einstellen

ich wünsch mir aber die option auch zwischen den werten morphen zu können. mit dem eventtable geht das zwar prinzipiell, allerdings is das speichern etwas umständlich/gewöhnungsbedürftig. darum.

ne monophone event-version (sowohl idx als auch die INs) mit 4 arrays würde mir reichen.

leider bist Du hier mit Deinen Beschreibungen so allgemein, dass ich Dir gedanklich nicht mehr folgen kann. Was hast Du genau vor? Welche Werte kommen woher, sollen wohin gespeichert bzw. ausgelesen werden?

das wär son teil, das mich als reverse-core-workshop (wir legen unsre module tiefer) voll zecken würde.
das gäbe auch stoff für fragen: 4 arrays dürften (sofern ich das verstanden hab) nich mehr als 4x4 bytes veranschlagen (pro stimme schreibt das handbuch - allerdings verschweigt es, ob global oder pro snap??? - doch selbst bei vermuteteen letzteren dürfte es bei 100 snaps = 100x4x4byte nich mehr als 1,6 Kb sein. ein, wie ich glaube völlig illusorischer wert... )

ich glaube da hast Du etwas missverstanden. Du kannst Dir doch Deine Arrays so groß machen wie Du willst; 1600 bytes wären da lächerlich.

...

[helmsklamm]

nochmal: was möchte ich?

im prinzip das gleiche, wie das prim-SVA: über idx wird das array gewählt und mit R und W gelesen bzw. geschrieben. der einzige unterschied: liegt bei idx eine float an, werden die werte zweier arrays ausgelesen und entsprechend der größe der nachkommastelle zwischen beiden korrekt interpoliert. und wie beim prim-modul sollte W einstweilen temporär sein, und erst nach "zusnappen" fest eingeschrieben werden (was bei den tables eben nich der fall ist).

nochmal in aller deutlichkeit: ich wünsch mir ein SVA mit 4 indexies (arrays). es sollte bis auf kleinere modifikationen exakt so arbeiten, wie das glecihnamige prim-modul:
auf der eingansseite gibt es einen idx und einen VAL - IN.
!!!! da R-Read immer nach idx abgefragt werden soll, können wir uns diesen port zur aussenwelt und das obligate order-modul (draussen) sparen. der idx-port reicht, denn intern wird sichergestellt, das erst das array gewählt wird und erst danach lese/schreibzugriffe erfolgen.
auf der ausgangseite reicht eigentlich der VAL-out.

wie beim prim-modul soll nun jede werteänderung am VAL erstmal direkt nach draussen weitergeben werden. ausserdem sollen diese werte im korrespondierenden arry gepuffert werden. nehmen wir an, ich habe die werte 1,2 / 3,4 / 16 und 0,3 ZWISCHENgespeichert, dann werden diese werte auch bei idx-jump direkt ausgegeben. bei idx=3 wird hinten also die 16 ausgegeben. ändrere ich nun den value knob auf bspw. 8 wird dieser erneutete wert auf array #3 aktualisiert (und natürlich vorher jeder zwischenschritt hinten am VAL ausgegeben). klar soweit? genauso arbeitet jedenfalls das prim-SVA.
(speicher ich das ganze als snap, werden alle array-Zwischenspeicher "festgeschrieben", falls nicht sind sie "flüchtig", dH ohne explizite snap-speicherung gelten sie nur solange, wie der snap bestand hat - bei erneutem aufrufen des snaps werden die "alten" werte für jedes einzelne array geladen).

nun zum eigentlichen:
da das array, resp. die write/read module ihre korrespondierenden werte permanent "auf tasche" haben MÜSSEN, MUSS!!! es doch möglich sein, diese werte auch PERMANENT abgreifen und zwischen ihnen blenden, zu können. (völlig unabhängig vom array-idx hält jedes write/read modul, mit ausnahme, des zZ "aktuellen" seinen "gespeciherten" wert fest. folglich muss es möglich sein, über eine "nachgeschaltete" crossfader/selector oder ähnliche core-verbindung diese werte zu "bekommen" und zwischen ihnen zu blenden. der blendknob liegt draussen und impliziert einenen neuen eingangsport. (zwar ist array #0 gewählt, wir hören aber hinten den wert, den uns array-wahl-knob plus add-knob (der nur zum crossfader gelangt, das seineszeichens zwischen ALLEN arrays blendet) vermittelt.
defacto hören wir also bspw. bei idx=0, add = 2,4 ne mischung aus 60% array 2 und 40% array 3. und bei bewegen des add-reglers auf bspw. 0,7 würden wir (neben den zwischenschritten bis hierhin schlussendlich) 30% von array#0 und 70% von array#1 hören.

is sowas umzusetzen? ich glaube ja.
dauert sowas lange? ich glaube nien.*

*vorrausgesetzt man wieß begriffe wie boool, latch, obc, precission.... halbwegs zuzuordnen.

[helmsklamm]

ähm, wurde das jetzt verstanden?

[herw]

ähm, wurde das jetzt verstanden?

ja, beim letzten Abschnitt nach sehr langen um die Ecke-Denken, da ich mich erst einmal erinnern musste, dass Dein Lieblingsmodul der crossfader ist.
Ja das dürfte machbar sein. Ich würde es erst mal eindimensional ausprobieren, um die genaue Befehlsabfolge zu strukturieren. Das dan auf ein Feld zu übertragen ist ja nur ein kleiner Schritt.

ciao herw

[herw]

Beim dritten Lesen habe ich es jetzt wohl verstanden: es handelt sich mathematisch gesehen um eine stückweise lineare Funktion mit vier Stützpunkten bzw. drei Abschnitten, wobei man schreibenden Zugriff auf jeden Stützpunkt hat und den Graphen der Funktionen beliebig durchfahren kann (wie beim crossfader).

korrekt?

[helmsklamm]

Beim dritten Lesen habe ich es jetzt wohl verstanden: es handelt sich mathematisch gesehen um eine stückweise lineare Funktion mit vier Stützpunkten bzw. drei Abschnitten, wobei man schreibenden Zugriff auf jeden Stützpunkt hat und den Graphen der Funktionen beliebig durchfahren kann (wie beim crossfader).

korrekt?

korrekt, wenn die anderen sachen nicht ausser acht gelasen werden: pro snap sollen von einem! fader 4 unterschiedliche values in die einzelnen indexies "gepuffert" werden. gepuffert bedeutet wie beim SVA erstmal temporäres zwiscchenspeichern und wird erst beim expliziten snap-write definitiv für alle arrays "festgeschrieben". im gegensatz zu den tables, wo man pro "idx" selber den write betätigen muss, bzw. es automatisch erledigen lässt, mit dem schöhnheitsfehler das jede änderung OHNE snap-speicher-trigger unumkehrlich festgeschriebn wird.
soweit nix anderes als die normale funktionsweise des prim-SVA. prinzipiell dürfte es bis hierhin intern ähnlich aufgebaut sein, wie das gewünschte core-"modul": eine array-bank und die zugehörigen write/read stellen sicher, das sowohl geschriebn als auch gelesen werden kann - und zwar für jedes "einzelne array" individuell. das aray gibt es nur einmal und es tut eigentlich nichts wieter ausser speicher zur verfügung zu stellen und diesen in segmente aufzuteilen, und je nach nach idx-wahl neue werte an das korrespondierendw write zu übermitteln - is das richtig?

die nachgeschaltete write/read kombi (W/R) reagiert nur auf werteänderungen, wenn das array-idx mit ihrem übereinstimmt. folglich sind alle W/R, mit ausnahme des aktuell über idx spezifierten "blind" für neue werteänderungen. trotzdem muss ja an allen W/R der zuletzt empfangende wert (als sie aktives idx-personal waren, bzw. falls nicht, zumindest ein defaultwert) anliegen. diese (im bsp. "modul" sind es 4) werte greifen wir hinten mit der entsprechung meines lieblingsmodul in core (es ist der selektor) ab. wir haben alos jederzeit alle 4 idx-values "griffbereit" und können mittels nachgeschalteten selktor;-) simple blenden.


schön wäre auch ne art internen tunings: das prim-SVA nötigt einem "draussen" ne menge zusatzmodule ab - in unserm fall soll write/read IMMER erst nach IDX befehl erfolgen, weshalb wir uns draussen das order modul und intern den port sparen können. ferner sollte idx 0-basiert sein - die obligate plus1 vorne und minus1 hinten beim prim_SVA nerven einfach nur. achja, das es kein "universelles" modul ist, reicht hinten auch einfach der VAL out (und natürlich muss auch intern der restliche schmuss nich sinnlos extra berechnet werden;)).

@herw:

aus deiner obigen bemerkung, das das machbar sei, unterstelle ich mal, das du das auch tatsächlich machst;-)
ich hoffe, das mich die "berechenbarkeit" der forums-"module" mich hier nich völlig im stich lässt: son teil wär schon echt knülli.

ps. schade das wir das hier alleine diskustieren.

[herw]

...@herw:

aus deiner obigen bemerkung, das das machbar sei, unterstelle ich mal, das du das auch tatsächlich machst;-)

das sollte eher eine Aufforderung an Dich sein, mal konkret zu werden

ich hoffe, das mich die "berechenbarkeit" der forums-"module" mich hier nich völlig im stich lässt: son teil wär schon echt knülli.

ps. schade das wir das hier alleine diskustieren.

Ich habe natürlich darüber nachgedacht, aber nach einiger Zeit (halbe Stunde) gemerkt, dass ein völliges Funktionieren auch von Deinen Vorstelllungen abhängt. Somit ist mehr Zeit zu investieren; ich arbeite aber, wie du weißt, an meinem Projekt und bin dort im Moment sehr gebunden (habe im Moment eine sehr kreative Phase), so dass ich mich vorrangig darum kümmern werde. Aber ich könnte Dir ein unfertiges Makro als Einstieg zur Verfügung stellen, quasi als Anfangsidee oder Motivationsschub, so dass Du daran weiter arbeiten und hier diskutieren kannst.
Es ist sicherlich für andere abschreckend, wenn Du die gesamte Arbeit auf einen Einzelnen überträgst.
Du kannst auch mit einer Skizze anfangen (Ablaufdiagramm oder auch ein Pseudo-Panel (nicht funktionierende Oberfläche)), um neben Deinen langen Ausführungen einfach mal eine konkrete Vorstellung zu bekommen. An unserer, jetzt schon längeren, Diskussion merkst Du sicherlich, wie groß häufig der Unterschied zwischen unseren Vorstellungen ist.

ciao herw

[helmsklamm]

Aber ich könnte Dir ein unfertiges Makro als Einstieg zur Verfügung stellen, quasi als Anfangsidee oder Motivationsschub, so dass Du daran weiter arbeiten und hier diskutieren kannst.

ciao herw

jo, süpi angebot das. ich lese zwar grad das core-buch, das auch wirklich gut geschreiben ist, aber so recht klar sind mir diverse sachen noch lange nicht, aber mit schützenhilfe von aussen findet der ochs vielleicht doch ins tor.

danke.

[herw]

...jo, süpi angebot das. ich lese zwar grad das core-buch, das auch wirklich gut geschreiben ist, aber so recht klar sind mir diverse sachen noch lange nicht, aber mit schützenhilfe von aussen findet der ochs vielleicht doch ins tor.

danke.

ja gleich ich muss nur ein wenig auf meinem laptop kramen (heilige Ordnung segensreiche!)

[herw]

hier isses:

Ich habe zunächst nur ein Array erzeugt. Mir ist nicht ganz klar, ob man ein weiteres zur Zwischenspeicherung benötigt. Im unteren Teil erkennt man, dass man über ein zweites Indexmodul auf dasselbe Feld gleichzeitig zugreifen kann. Hier muss man vorsichtig sein, man kann hier eventuell in "zeitkritische" Signalwege kommen, im Sinne von: eigentlich ist alles gleichzeitig, aber was wird zuerst ausgeführt?

Sorry für die Einsteiger, da muss man sorgfältigst zehnmal den Abschnitt 4.2 Object Bus Connections (OBC) S. 76-79 im Core-Handbuch lesen und ausprobieren.
Ich bin auch erst nach etwa einem Jahr-Core-Erfahrung tatsächlich auf solche Schaltungen, wie sie auf der Seite 79 beschrieben werden, gestoßen.

Meine Idee bis hierhin ist, dass man auf zwei Array-Indizes gleichzeitig zugreift.
Der Eingang mix überstreicht dabei den Bereich von 0 bis 4 als Floatingzahl. Beispiel mix=2,4. helmsklamms Vorgabe ist nun, dass man die beiden Feldfächer A[2] und A[3] miteinander vergleicht. Den Index 2 erhält man durch den integer-Eingang des Merge-Moduls. Ein Runden des Wertes 2,4 erfolgt damit automatisch. Der Index 3 wird mit demselben Trick mit Hilfe des Additionsmoduls erreicht (er muss für den Fall mix=4 geklippt werden; ich weiß nicht, ob REAKTOR bei einem ungültigen Index mit einer Fehlermeldung abbricht (ausprobieren!).
Was nun noch fehlt, ist der prozentuale Mix der beiden Werte bei A[2] und A[3]: das lässt sich leicht umsetzen:

M=A[2]·(1-[mix]+mix)+A[3]·([mix]-mix) ,

wobei [mix] die integer-Rundung des Eingangswertes mix ist.
In unserem Beispiel ist dann [mix]-mix=0,4=40%. Damit wird A[2] mit 60% und A[3] mit 40% multipliziert.
Für die Ausgabe des Wertes fehlt auch noch eine Trigger-Routine.

ciao herw

[helmsklamm]

knülli herw, vielen dank.

so, gleichmal den text kopieren und ins macro-prop einpasten, dann gehts an die weiterbildung

[helmsklamm]

lassen wir mal das mit den mix ertsmal aussen vor und konzentrieren uns einstweilen auf das reine SVA.
offensichtlich (absichtlich?) hast du bei deiner schalte n wichtiges kabel vergessen, am read in.

ich hab mal diese schalte probiert: jetzt tut es erstmal (scheinbar), was es soll: über IN kommt der wert an und wird auch sofort nach draussen weitergeleitet. über idx wird der wert in den einzelenen array-felder festgehalten und auch korrekt ausgegeben. das problem, sobald man den snap wechselt, ist alles weg, bzw. verwürfelt.
ich hab mal versuchsweise wegen der gleichzeitigkeit den IN und idx port in der reihenfolge vertauscht, aber das bringt auch nix. ich schätze mal es gibt irgendwo ne fehlinitalisierung, nur wo?



achso, da ich immer noch mit 511 rumgurke konnt ich dein file nicht laden, habs also selber nachgebaut und alles, ausser array größe auf standard gelassen.
arrysize =4 und wird mit ner list 0-3 getriggert. (ich hab auch die 1-4 variante exerciiert aber das wars es leider nicht).