core-SVA

[helmsklamm]

ähm, ich hab mal deinen beitrag erneut gelesen - wahrscheinlich hast du read freigelassen, weil der trigger/mix vorgang nochb nicht endgültig geklärt ist, oder?

vielleicht isses sinnvoll erstmal die pflicht und dann die kür zu absolvieren: also erstmal das reine SVA und später die mix-version - ich glaube mit den ganzen OBC fallstricken tapp ich sonst völlig im dunkeln.

(achso ne seite vorher gibts noch nen beitrag von mir, nich das du den übersiehst.)

und noch was: was meinst du überhaupt mit integer-eingang des merge????

[helmsklamm]

hm, ich hab nochmal n bissl reumexperimentiert und so wies schaut ist das write leider garnicht als "festschreiber" vorgesehen sondern pures "RAM".
die in den arrays gespeicherten werte werden über alle snap-grenzen hinaus nur temporär gehalten und gehen nach beenden verloren.

ergo geht das von mir gewünschte wohl prinzipiell nicht, oder gibts irgendwo ne art write das nicht flüchtig arbeitet?

[herw]

...
offensichtlich (absichtlich?) hast du bei deiner schalte n wichtiges kabel vergessen, am read in.

ja und nein, ich habe einfach aufgehört an dieser Stelle weiterzuentwickeln, da der Zeitaufwand größer wird. Und ich denke, dass der Ansatz mit Erklärungen genügt um weiter zu machen.

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).

Das Ensemble bestand nur aus dem abgebildeten Modul; arraysize = 4 ist korrekt.

Ich kann jetzt leider deinen Gedanken nicht mehr überprüfen, da ich den ganzen Tag am MODULAR gearbeitet habe (und eine leckere Flasche Spätburgunder Rotwein trocken - im Barrique gereift - grenzt jetzt etwas meinen Gedankenspielraum ein ). Ich schaue es mir in den nächsten Tagen an (frühestens Mittwoch, da ich zwei Tage durcharbeiten muss).

ciao herw

[herw]

...und noch was: was meinst du überhaupt mit integer-eingang des merge????

wenn Du mal die beiden Merge-Module in meinem und deinem Bildausschnitt vergleichst, dann siehst Du am Eingang "meines" merge-Moduls jeweils ein "=". D.h. ich habe in den Properties das Modul auf integer- (Ganzzahl-) Werte umgestellt, was allerdings in dem Fall ohne Auswirkung ist, da das Indexmodul sowieso einen integer-Eingang besitzt.
Wird ein integer-Eingang mit Floating-Zahlen angesteuert, wird auf ganze Zahlen gerundet.

ciao herw

[herw]

hm, ich hab nochmal n bissl reumexperimentiert und so wies schaut ist das write leider garnicht als "festschreiber" vorgesehen sondern pures "RAM".
die in den arrays gespeicherten werte werden über alle snap-grenzen hinaus nur temporär gehalten und gehen nach beenden verloren.

ergo geht das von mir gewünschte wohl prinzipiell nicht, oder gibts irgendwo ne art write das nicht flüchtig arbeitet?

hmm, es scheint so, dass du Recht hast. Das ist ärgerlich, nicht das Recht-haben, sondern die Tatsache, dass der Speicher flüchtig ist. D.h. man muss dann doch wieder außen speichern in einer eventtable. Womit wir wieder beim Anfangsproblem wären.

ciao herw

[helmsklamm]

korrekterweise müsste das modul wahrscheinlich "hold" und nicht "write" heissen, denn ein echtes schrieben findet nie statt, lediglich ein festhalten bis zum beenden des programms. naja, vielleicht müsste das, was ich meine auch "save" heissen - aber n klärendes wort im handbuch wär schon nicht schlecht gewesen, wie es scheint bin ich ja nicht der einzige dem das nicht völlig klar ist.

draussen wüsst ich mir auch zu behelfen, nur wäre die core-lösung wahrscheinlich um einiges schlanker als die prim-alternative, zumal ich das teil einige dutzend male bräcuhte.

zum merge: ah klar, es gibt ja immer ne I und ne F version - an solche sachen muss man sich wohl ertsmal gewöhnen.

[herw]

Ich glaube, man muss zum jetzigen Zeitpunkt einfach anerkennen (besser akzeptieren), dass Core einzig und allein für den Rechenbereich gedacht ist (auf Audio und Eventebene) und alles was GUI und Datenspeicherung abgeht, im primary Bereich angesiedelt ist.

[helmsklamm]

is schon richtig und ich hab auch nich ernsthaft genörgelt. - man muss es nur eben wissen, was geht und was nicht.

ich hab das jetzt auch im prim gelöst, allerdings brauch ich nun einige module mehr:(

[herw]

is schon richtig und ich hab auch nich ernsthaft genörgelt. - man muss es nur eben wissen, was geht und was nicht.

ich hab das jetzt auch im prim gelöst, allerdings brauch ich nun einige module mehr:(

zeig doch mal!

[helmsklamm]

so:




leider gibts beim value-modul keine optionen, bspw. 0 auszufiltern oder generell nur einen konkreten wert als trigger zu akzeptieren, deshalb brauch man den schmuss da vorne weg. (vielleicht kriegt man ja das in core modul-effizienter hin?).
das realais versursacht natürlich erstmal nen sprung, man sollte hier eigentlich nen selector nehmen um das ganze über nen weiteren skalierselector per mix-regler weich steuern zu können, aber ich wollt erstmal das prinzip zeigen.
beim sva sollte self-iteration ausgeschaltet werden und der selectr natürlich bei curve nicht auf none belassen werden;).