panel-hierachie

[helmsklamm]

das wird gleich aller vorraussicht nach n bissl wirr, sorry:

also - ihr kennt das ja vielleicht, das knobs in unterscheildichen macros "übereinanderlegen" kann und je nach dem welhces macro zuletzt "gepanelt" wurde, wird der korrespondierende knob in den vordergrund geholt und kann "gemaust" werden, ohne das "hinterliegende" davon beeinträchtigt wird.

mit deisem prinzip sind ganz nette schweinereien möglich (stichwort: unsichtbare "mausareas" - hat nix mit dem gleichnamigen modul zu tun), ohne das man ständig n stacked macro bemühen müsste, etc.

was mir absolut nicht klar wird, ist die hierachie, nach der A die module und B ihre "anordnung" innerhalb der macros behandelt werden:

idR wird ein panelelement (X), das in der struktur "oberhalb" eines macros leigt, mit höherer panel-priorität als die elemente in dem macro (Y) behandelt. aber was passiert, wenn dieses macro auch in nem anderem macro steckt und dieses nochmal verpackt ist. und unser X in einem anderen macro steckt, aber nur einmal "verpackt" ist? dann müsstest es theoretisch doch noch immer ne höhere priorität als Y haben, da Y 2 mal verpackt ist. meine erfahrung widerspricht dem aber (leider ist alles dermassen verschachtelt, das ich nich mit sicherheit sagen kann, was mehr oder weniger "tiefer" steckt.)

der kurze sinn: kennt jemand die regeln nach der die panels "gewichtet" werden? ok, mausarea hat wohl den höcheten wert, knob und fader unterscheiden sich nicht, aber was ist mit lamps, MP, etc.? und wie sind die "verschactelungs" gesetze?

[herw]

...der kurze sinn: kennt jemand die regeln nach der die panels "gewichtet" werden? ok, mausarea hat wohl den höcheten wert, knob und fader unterscheiden sich nicht, aber was ist mit lamps, MP, etc.? und wie sind die "verschactelungs" gesetze?

guckst Du hier für ein geordnetes Übereinander ohne stacked Makros.
Die Aktivierungsreihenfolge ohne eine solche erzwungene Ordnung hängt davon ab, in welcher Reihenfolge eingefügt wurde und wie abgespeichert wurde etc., wie du schon richtig erkanntest, nicht ganz vorhersehbar.
Die (richtigen) Mouseareas haben allerdings gegenüber allen anderen Panelelementen den Vorteil, dass sie immer Vorrang in ihrem Makro haben, das heißt vor allen Elementen, die in demselben Makro liegen. Ist aber ein anderes Panelelement aus einem anderen Makro daruntergelagert, und aktiviert dieses in der Struktur, dann ist das Makro aktiviert.
In dem download-file wird dies systematisch ausgenutzt, indem ich jeweils ein Panelelement (in diesem Fall einen Button) aus jedem Makro direkt zugreifbar anordne. Sobald ich den Button aktiviere, sind auch alle anderen Panelelemente des Makros aktivierbar. Man darf dies aber nicht übertreiben, irgendwann wird es doch unübersichtlich.
Entscheidend ist auch manchmal, dass nach dem Start ein ganz bestimmtes Panelelement in jedem Fall aktivierbar ist.
Das download-file entstand übrigens noch mit den Mitteln von Reaktor 4, als es noch keine MouseAreas gab.
Auch die Virtual-Keys nutzen diesen Trick aus - ein unsichtbares Multipicture überlagert andere Multipictures.

ciao herw

[KlangRaum]

OT

Auch die Virtual-Keys nutzen diesen Trick aus - ein unsichtbares Multipicture überlagert andere Multipictures.

danke für den link - das hab ich gesucht und nimmer gefunden....

[herw]

OT

Auch die Virtual-Keys nutzen diesen Trick aus - ein unsichtbares Multipicture überlagert andere Multipictures.

danke für den link - das hab ich gesucht und nimmer gefunden....

OT

Das hättest Du auch aus dem MM2 stehlen können . Dort benutze ich statt des transparenten Multipictures eine MouseArea.

[helmsklamm]

danke. du meinst, später eingefügte teile haben ne andere priorität als frühere?
was is, wenn ich n teil auschniede/einfüge? gilt das dann als "neuer" hinzugefügt?

da brauch ich mich ja nich wundern, das das alle sehr "zufällig" ist.

[toxonic]

ja, so ist es.... auf diese art und weise kannst du das dann aber auch nachträglich vornehmen, und eine hierarchie erstellen! also erst bauen, und dann in der entsprechenden reihenfolge die entsprechneden elemente ausschneiden und wieder einfügen!

[helmsklamm]

das dumme an der sache is natürlich das panelelemente beim strg+x/v
sämtliche master/slave zuweisungen verlieren.
sssss - da komm ich wohl um einige "meditative" nachmittage nich drumrum.


oder gleich anschlussfrage:

wenn sich master/slave innerhalb eines (auch verschatelten) macros befindet, und dat janze strgX/V wird, behalten die master/slaves ihre zuwesiungen, dont they?
echte arbeit ensteht nur, wenn das "master" macro nicht mitkopiert wird, oder?

ich blick da nich ganz durch - ich bin der meinung, das den ganzen IC sachen ihere zuweisungen fest angepappt werden, hier kann ich gefahrlos hinkopieren, wo ich möchte.
wohingegen bei "echten" panelelementen die zuwesiung gewissermassen "flüchtig" ist, also ich muss zwingend M und S duplizieren, bzw. die slaves jedesmal neu "anmelden", richtig?.
und das gleichet auch bei panels, die von nem IC empfangen - oder?

also ich blick da momentan nich ganz durch, könnte vielleicht mal jemand das listen?


(das ist auch wieder son schönes beipsiel, für die ganze INHARMONIE in raektor: macnhce so, manche so ... einige bracuhen ne 1 um witerzuschalten, anderen reicht n wert > 0, wieder andere reagieren auf > 0.5, manche nehmen jeden trigger an, andere nur wenn => 1, etctt. --- was soll das alles? ne verbindliche grundregel kann doch wohl nich so schwer sein - mein lieblingsobjekt is hja diesbezüglich das sva und sein "1- basiertheit" das ja an sich schon völlig irrwitzig ist (es sei denn man findet gefallen daran, jedesmal ne +1 vorne und ne -1 hinten ranzuklemmen) und eigentlich nur noch durch sein weiterschlaten bei jeder nächsten n,5 getoppt wird.
yo, da haben sich die entwickler bestimmt was bei gedacht. es mag ja sein, das ich einmal in trilliarden gelegenheiten n auto brauche wo die räder oben sind.
die meisten fälle brauch ich aber die räder unten - ergo definier ich doch nicht "räder oben" als default.
sorry, ich bin vom thema ab, das is auch mehr die R6 frage, aber man kommt eben hinwieder vom hundersten ins tausende - und bei unserer "spielzeug" logik sowieso.

also nochmal:
send/recive lässt sich ohne zuweisungs-verleirungs-gefahr hin und her coppien und n recieve-duplicat erbt auch automatisch die send-zuweisung, richtig?
master slave hingegen vererbt weder die zuweisung noch wird beim copy/paste diese "mitgenommen", es sei denn M und S werden gleichzeitig aber nur, wenn sowohl master UND slave "gleichzeitig" und "doppelt" dupliziert/verschoben?

tschuldier, für die ganzen suggestiv-fragen . ich such schon n weilchen nach ner möglichkeit, wie man ne angenohmende RICHTIGKEIT nachfragend veriziert bekommen kann, OHNE in der frage die "thesen" als "wahr" hinzustellen.
falls in dieser hinsicht auch jemand n vorschlag hätte: bittebittebitte.

[toxonic]

ja, das in der tat ein bisschen blöd, das master/slave zuweisungen zwischen panel-elementen duch cut/paste verlorengehen, bzw. nicht übertragen werden auf ihre duplikate! bei send/receive ist das zwar nicht so, da du aber auch ic send/ic receive module erwähntest - da verhält es sich so wie unter panelel-ementen, die zuweisungen gehen ebenso verloren durch cut/paste... das ist jedenfalls meine erfahrung!
ausnahme, wie du schon sagtest: wenn master und slave gleichzeitig ausgeschnitten werden und wieder eingefügt!

tschuldier, für die ganzen suggestiv-fragen . ich such schon n weilchen nach ner möglichkeit, wie man ne angenohmende RICHTIGKEIT nachfragend veriziert bekommen kann, OHNE in der frage die "thesen" als "wahr" hinzustellen.
falls in dieser hinsicht auch jemand n vorschlag hätte: bittebittebitte.

mensch, du hast ja probleme.....

[helmsklamm]

bin nicht sicher, ich möchte meinen ein recieve behält die zuweisung, ohne das das send mitkopiert werden müsste. nur andersrum gehts verloren.
aber der fall, das recieves dupliziert werden, dürfte wohl entschieden häufiger als andersrum anzutreffen sein. ausserdem entspricht das auch mehr der erwartungshaltung - wohingegen das automatische setzen auf unterschiedliche sends mitunter zu verwirrungen führen könnte.
am besten wär ne rechtslick-option: cut/copy with "indirect" wire.

keine unnötige arbeit, keine verwirrung.

[herw]

bin nicht sicher, ich möchte meinen ein recieve behält die zuweisung, ohne das das send mitkopiert werden müsste. nur andersrum gehts verloren.
aber der fall, das recieves dupliziert werden, dürfte wohl entschieden häufiger als andersrum anzutreffen sein. ausserdem entspricht das auch mehr der erwartungshaltung - wohingegen das automatische setzen auf unterschiedliche sends mitunter zu verwirrungen führen könnte.
am besten wär ne rechtslick-option: cut/copy with "indirect" wire.
...

da eintragen: ->,
wird sicherlich auch von NI gelesen