init bang?

[toxonic]

is vielleicht ne blöde frage, aber ich habe in einer struktur ein polydisplay verwendet welches die werte aus 2 eventtables darstellen soll. wenn ich nun das ensemble neu starte, wird erstmal nix auf dem display angezeigt, obwohl werte in den tables enthalten sind. ich brauche also so eine art "initial bang" um die ausgelesenen werte im display darzustellen, oder? wie kann ich das hinkriegen?

[toxonic]

keiner ne idee?

[herw]

keiner ne idee?

Hast Du die Darstellung des polydisplays abgespeichert.
Damit ein Display abgespeichert wird, musst Du ein SnapArray vorweg schalten und dann mit einem Snap abspeichern. Genaueres kann man nur sagen, wenn Du ein Beispiel hier hochlädst (möglichst einfach und nur prinzipiell).

ciao herw

[toxonic]

hallo herw!
nee, ich wollte das ohne snaparray machen, weil das in der struktur keinen sinn macht, snaps zu erstellen, da die tables sich die werte ja ohnehin "merken"!
aber ich habe ein bisschen gesucht und eine lösung gefunden.... und zwar hat mir (glaube ich) kid sputnik mal im zusammenhang mit einem thread den ich im offiziellen forum gepostet hatte ein macro geschickt in dem wiederum ein "init bang" macro einthalten war... is sehr simple, besteht in erster linie aus ner konstante und nem iteration modul!
ich werde das gleich mal unter "minilösungen" posten! damit kann man sich den snapkrams sparen, wenn er nicht unbedingt notwendig ist!

[herw]

...im offiziellen forum ...

wie was heißt das denn? HIER ist das offizielle REAKTOR Forum

[helmsklamm]

ich hatte neulich auch wieder son unglaubliches init-problem, das ich erst nach x nerven und y grauen haaren "gelöst" bekam.

ich muss vorwegschicken, das es schon n äusserts spezielles makro, mit vilen wenn/aber/falls/dann doch bedingungen ist und in der praxis wohl so, oder so ähnlich nicht oft gebraucht wird. ungeachtet dessen - reaktor ist ja eigentlich genau darauf ausgelegt, sollte es zumindest.

wie auch immer: um die spezielle funktionsweise unter sämtlichen wunschbedingungen immer korrekt zu erreichen, war eine penible order-einbindung unvermeidlich. ich hatte also 3-oder module (und nen sack anderer) die sich mehr/minder gegenseitig bedingten und natürlich nur nach zeitlich korrektem abbarbeiten genau wie gewollt liefen. nach mehreren try/errors funzte auch alles unbuggy. erstmal. bis ich zufällig das teil mal in einer selten gebrauchten (haupt) einstellung beendete. beim erneuten start klang alles total anders. snapwechsel, zurück - alles plötzlich wie gewünscht/erwartet. nach einigen versuchen (switch an/aus, power an/aus) war die sache klar - irgend nen seltsames init-dings ist dafür verantwortlich. nach einigen an/aus war die sache bis aufs vorletzte order-modul eingegernezt. aber dann: eventwachtcher ran und tatsächlich übermittelte der erste order-out noch korrekt, der zweite aber nicht mehr, sondern "re-init-te" erneut. (darauf muss man erstmal kommen: die order-ausgänge KÖNNEN unterschiedliche werte haben!) ist die tragweite klar? der laie denkt: ein order empfängt am IN ein event und schickt dieses erst an seinnen ersten OUT, dann den zweiten, usw. ein "falscher" oder "richtiger" wert liegt folglich IMMER an allen 3 ausgängen gleichzeitig an. pustekuchen. mit nahezu 100% ist das zwar der fall, hier aber nicht. . scheinbar muss tatsächlich zur "unzeit" (während zwar der erste OUT "abgearbeitet" war, der zweite jedoch noch nicht) ein erneutes event hinten eintreffen und nur den zweiten und dritten OUT neu beschicken.

ich hab dann n bissl probiert (in dem makro) und von die "vorher" orders nochmal anders gedrahtet, irgendwann liefs völlig bugfrei.

natürlich war meine struktur vorher nicht wirklich korrekt und ich könnte es dabei belassen. andrerseits find ich dieses order-verhalten schon reichlich merkwürdig und erwähnenswert.
meine lehren daraus:
1.
bei "heiklen" sachen immer für jede funktionalität auch den power an/aus testen.
2.
auch unmöglich erscheinendes kann möglich sein.

[herw]

... nach einigen an/aus war die sache bis aufs vorletzte order-modul eingegernezt. aber dann: eventwachtcher ran und tatsächlich übermittelte der erste order-out noch korrekt, der zweite aber nicht mehr, sondern "re-init-te" erneut. (darauf muss man erstmal kommen: die order-ausgänge KÖNNEN unterschiedliche werte haben!) ist die tragweite klar? der laie denkt: ein order empfängt am IN ein event und schickt dieses erst an seinnen ersten OUT, dann den zweiten, usw. ein "falscher" oder "richtiger" wert liegt folglich IMMER an allen 3 ausgängen gleichzeitig an. pustekuchen. mit nahezu 100% ist das zwar der fall, hier aber nicht. . scheinbar muss tatsächlich zur "unzeit" (während zwar der erste OUT "abgearbeitet" war, der zweite jedoch noch nicht) ein erneutes event hinten eintreffen und nur den zweiten und dritten OUT neu beschicken. ...

Da Du Deine Post unter "init bang" eingeordnet hast, nehme ich an, dass Du das seltsame Verhalten des Order-Moduls beim Einschalten bemerktest.
Es könnte daran liegen, dass beim General Reset, der beim Einschalten geschieht, laut Initialisierungsbeschreibung (siehe deutsche Übersetzung von Tymes in der User library) nur der erste Ausgang initialisiert, während die anderen Ausgänge keinen Wert schicken. Wenn Du dann überprüfst, liegen vielleicht verschiedene Werte an?

[helmsklamm]

jo, richtig nur beim init. also komplett einschalten, aber auch bei audio-switch, wo höchstwahrscheinlich das gleiche stattfindet.

ach, das ding ist jetzt übesetzt? süpi, danke an alle.

[herw]

jo, richtig nur beim init. also komplett einschalten, aber auch bei audio-switch, wo höchstwahrscheinlich das gleiche stattfindet.

ach, das ding ist jetzt übesetzt? süpi, danke an alle.

der Dank gilt allein TYMES!