Deutsches Reaktor Forum

also in manchen (event) konstellationen brauch man schon unendlich viele module, für ne vglw. simpleste anforderung:
bspw: is das modul "value" null konfigurierbar, sodas man in der praxis oft nicht ohne die zusatzmodule order, seperator, compair, router, merge, etc. auskommt.

ein modul das ich schmerzlich vermisse ist ne art "value-gate". also ein value-modul das den übermittelten wert solange ausgibt (und danach hält) wie die gate-bedingung erfüllt ist, und erst neue werte erneut ausgibt, wenn die gate-bedingung abermals erfüllt ist. bspw: g = (exakt)1 = wahr. solange 1 bei g anliegt, gilt die bedingung erfüllt und werte am unteren value-port werden simpel durchgeschleift, als wäre nix dazwischen. aber wenn g ungleich 1, wird der port "geschlossen" und letzte wert einfach gehalten. erst ein erneutes öffnen des tores und eine werteänderung DANACH bewirkt einen neuen wert am out.
auf prim brauche ich für diese funktion neben dem value-modul ein compair/eqaul (nur 1 darf öfffnen, ), einen seperator (das compair/equal sendet auch bei rückschalten auf 0 ein event, das das value als trigger interpretiert) einen multiplizierer (damit der triggervorgang auch tatsächlich bei jeder werteänderung stattfindet UND ausgegeben wird) ) und noch mindestens ein order und selbst dann funzt das nur im positiven bereich (oder ich muss umständlich umverdrahten). und das alles für einen ganz simplen "low-level" wunsch.

ich denk mir in core wär das n paar nummern effizienter: ein write/read paar und ein (über aussenkonstante konfiguribares) compair sollten es lösen: es wird erst geschrieben/permanent ausgelesen, NACHDEM und SOLANGE die bedingung erfüllt wurde/ist, ist sie nicht mehr erfüllt wird der letzte wert gehalten. (vielleicht noch simpler über ein multiplizier-modul (solange bedingung erfüllt = multiplikation mit 1 = simples durchlassen. sobald nicht erfüllt, kein rücksprung auf 0, sondern einfach nur halten des wertes). (findet bei multiplikation mit 1 oder 0 tatsächlich ne "berechnung" statt oder wird der offensichtliche wert tatsächlich simple durchgeschleift? was ist cpu-technisch günstiger?? read/write oder pseudo-multiplikation???).

achso, was war eigentlich die frage? krieg ich das wie oben angedacht (read/write/compair) so easy in core hin oder liegen da kriegsentscheidende minenfelder?

ich versuch grad mich da einzudenken_ und siehe da, alles wird nur noch komplizierter:

(das read brauch man, weil write ohne read hochgradig samengestaut wäre aber prinzipiell ohne verbindung nix rausrücken kann, oder?)

die trennung read/write exiztiert, weil der zeitpunkt des einen oder anderen eminent wichtig ist.

beide greifen auf gemeinsamen speicher zu ("dargestellt" über das eigentliche array-"modul"), dessen ausgabewert write bestimmt, deren ausgabezeitpunkt aber von read kontrolliert wird, oder?

"speicher" meint in diesem zusammenhang aber auch nix anderes als bspw. jedes panel-element, oder jedes andere modul, das "einweg" variablen verarbeiten kann (anzahl arrys = 0, arraysize=1) also einen wert pro snap (sofern nicht anders spezifiziert).

wenn das alles richtig, muss ich doch nur sicherstellen das write zum richtigen zeit"punkt" werte empfängt (read empfängt gleichzeitig die lesewerte von write und wird ebenso gleichzeitig über die ausgabewerte von write "getriggert" - ergo: wenn write sihc nicht ändert, read = status quo).

wenn bis hierhin richtig, muss ich also lediglich sicherstellen, das write nur ändereungen empfängt wenn meine gestellte bedingung erfüllt wurde.

hier beginnt die schwirigkeit: das handbuch sagt zum lowlevel write ungefähr folgendes:
ein am OBEREN eingang anliegener wert wird in den speicher geshreiben, sobald ein wert am OBEREN eingang anliegt! ja, aber das gilt es doch gerade zu vermeiden, bzw. nur zuzulassen wenn noch eine weitere bedingung erfüllt ist. (analog gesprochen: nur wenn die tür offen ist, dürfen (können) neue gäste eintreten) --- (für alle anderen auch core-einsteiger: der untere port dient für core-spezifische, sogenannte OBCverbindungen, also reihenfolgen, speicherteilung, etc.)
ja was denn nun? wieviel lowleveler muss ich denn noch gehen? (mit core gehts jedenfalls nicht tiefer und die tatsche das man gäste nur bei offener tür empfangen möchte, (und nur ich habe den schlüssel, der ist in diesem fall exakt 1) muss in core genauuso umständlich wie in prim gelöst wrerden.

also, wenn nichmal diese simple funktion in core umsetzbar ist, bzw. genausoviel kostet wie in prim, ja, wozu der ganze schmuus???

http://www.cycling74.com






ne, aber mal im ernst. es gibt wirklich schon sachen, die eigentlich ganz einfach zu lösen sind, aber nur über tausend umwege zu haben sind. schon sehr ärgerlich

helmsklamm hat geschrieben:???...???

Lieber helmsklamm, auf eine solch lange Anfrage kann keiner antworten; könntest Du noch mal eine Trennung Deiner Fragen (-Gebiete) vornehmen? Deine Anfrage ist etwas wuselig.

der langen rede kurzer sinn:

kann man in core ein "gate-value" modul bauen, das folgend funzt:

solange am oberen port (nennen wir ihn gate) ein bestimmter (mit ner aussenkonstante spezifizierter) wert anliegt, gilt das "tor" als geöffnet und werte am unteren port werden ganz simpel nach hinten durchgeschleift. ändert sich der gate-wert, gilt das tor als geschlossen, folglich werden keine neuen werte mehr durchgelassen.
erst NACH erneutem öffnen des tores und NACH erneutem änderen des unteren wertes werden wieder neue werte durchgelassen.

nicht mehr, aber falls möglich mit deutlich weniger modulen als im prim.

ich sehen leider weder mit router noch mit read/write noch mit latch (das ja im prinzip dasgleiche wie das prim value-modul ist) und nen notwendigen compair-algo ne simple möglichkeit, das zu verwirklichen. (aber core ist sehr neu für mich, weshalb es wahrscheinlich ne ganz einfache lösung dafür gibt, nur sehe ich sie nicht.)

ich glaube, dieses kleine Core-Modul müsste Deine Wünsche erfüllen:
- erklärt sich eigentlich selbst. Ein kleines Beispiel-Ensemble habe ich beigefügt:

Ein Midi-Gate-Event öffnet und schließt das Tor; du kannst auch die Compi-Tastatur benutzen.

ciao herw

PS: im primary-level geht das aber genauso einfach

helmsklamm hat geschrieben:...achso, was war eigentlich die frage? krieg ich das wie oben angedacht (read/write/compair) so easy in core hin oder liegen da kriegsentscheidende minenfelder?

ich versuch grad mich da einzudenken_ und siehe da, alles wird nur noch komplizierter:

(das read brauch man, weil write ohne read hochgradig samengestaut wäre aber prinzipiell ohne verbindung nix rausrücken kann, oder?)

die trennung read/write exiztiert, weil der zeitpunkt des einen oder anderen eminent wichtig ist.

beide greifen auf gemeinsamen speicher zu ("dargestellt" über das eigentliche array-"modul"), dessen ausgabewert write bestimmt, deren ausgabezeitpunkt aber von read kontrolliert wird, oder?

Wenn es nur um einen Wert geht, dann benötigst Du kein array-Modul. Die gemeinesame OBC-Verbindung zwischen read- und write-Modul ist schon der Speicher.

... wozu der ganze schmuus???

ich bin jetzt mal böse: vielleicht änderst Du mal Deine Signatur um : core Handbuch lesen!

Du solltest viel einfacher denken!

glaub mir herw, ich hatte exakt diese lösung in prim probiert, mit dem router 1>M. sie funzte nicht. (und der distributer scheidet aus, weil er sofort bei umschalten den anliegenden wert übernimmt, was ja in diesem falle unerwünscht ist) (hab ich ein modul übersehen, das ebenfalls in frage käme?).

wegen deiner behauptung, es ginge doch, hab ich also nochmal experimentiert und tatsächlich: du hast recht, es geht. ALLERDINGS muss der router1M dann über 2 ausgänge verfügen (hatte ich auch gesetzt) UND der 2te muss tatsächlich verdrahtet sein. erst dann arbeitet er wie gewünscht (das hatte ich nicht "berücksichtigt" - aber ehrlich, wie kann man da ne dummy-verdrahtung als zwingend notwendig erahnen?).

aus diesem grunde dachte ich der core-router funzt ebenfalls genauso (doch hier muss der 2te out nicht verdrahtet sein). also, ich hab das core buch zumindest überflogen, das kannste mir also nich vorwerfen;)

abgesehen davon hoff ich mal das dieses core-cell das ganze etwas verschlankt (dürfte zwar kaum ins gewicht fallen, aber es sieht zumindest eleganter aus).
danke.

helmsklamm hat geschrieben:glaub mir herw, ich hatte exakt diese lösung in prim probiert, mit dem router 1>M. ....

eine zu Core äquivalente Lösung wäre mit dem router M > 1 mit zwei Eingängen zu machen, wobei der obere Eingang leer bleibt.

stimmt nicht - und das is ja das verrückte: wenn ich nur einen, bzw. einen unverdrahteten 2ten eingang nutze, scheint POS keien wirkung zu haben. (egal welcher eingang mit pso gewählt wird - es wird immer der obere durchgeschleift, und bspw. nicht die "gedachte" null-konstante am unteren eingang. nutze ich hingegen ne echte null-konstante, arbeitet pos wie erwartet - probier es aus.) erst wenn ich den 2ten eingang mit irgendwas verbinde, reagiert POS. und das absolut erstaunliche: wenn ich nun den 2ten eingang entdrahte bleibt es dabei, das POS ne wirkung hat.

das einzige modul das von vornherein so agiert ist der router1,2 , welcher laut handbuch nur wegen der abwärtskompatibilität noch an bord ist, was ich aber falsch versztanden hab und ihn deshalb nie benutzt habe, fataler fehler: denn dieses modul zeitigt einzig das gewüscnhte verhalten "ab werk".

EDIT: ich sehe grad, du sprichts vom oberen eingang FREI lassen - das kann natürlich idT dann stimmen, muss ich glaich mal überprüfen. jedenfalls machts der Router1,2 auch und zwar mit nur EINEM eingang.