Initialisierung rausfiltern

[Eventmanager]

Ich stehe immer wieder vor dem ungewollten Init-Event-Problem. Meistens bekomme ich das mit ner Armada an Order-, Stepfilter-, Value-,Router-.... Modulen IRGENDWIE in den Griff, aber es ist stets ne nervige Frickelei.
Gibts irgendwo Core-Primary-Nachbauten die ziemlich adäquat zu den Vorbildern agieren, aber eben den Init(switch)-Extra-Trigger schon von sich aus rausfiltern?

[herw]

in core sehr einfach:

init_filter.jpg

ciao herw

[Eventmanager]

Danke.
Nur was ist das "ES" ? Und reicht es, wenn ich die Cell hinter das Prim-Objekt klemme, quasi wie ein switch oder muss das gesamte Modul in Core nachgebildet werden?

EDIT:
habs gefunden, es ist das ES CTl. Jo funzt soweit als "Hinterklemmer" zumindest werden Konstanten rausgefiltert.
Bei einem Hold vorneweg wird zwar die 1 gefiltert, allerdings noch ne Null ausgegeben.
Bin mir nicht sicher, irgendwie erscheint mir das aber logisch, denn das Hold gibt schliesslich beim Init 2 Events raus: 1 und 0.
Hm, muss ich dem Problem doch noch anders beikommen, aber gut zu wissen son Ding im Köcher zu haben.

Gibts irgendwo ne Cell-Biblio mit solchen kleinen Helferlein?

Seid nochmals bedankt Meister!

Hab wahrscheinlich die nächsten Tage kein Netz, Antwort kann also delayen.

[herw]

... dann musst du die EventCoreCell vor dem Hold-Modul einsetzen!

bild.jpg

Teste immer mit dem ACEW!
ciao herw

[Eventmanager]

Vor dem Hold ist ja langweilig;)

Aber was gibt das unverdrahtete ES eigentlich aus (ist ja son grünes Kabel, wo man nichts "sieht")?
Ich vermute mal, es stellt sicher das der Router während dem "ersten Teil" der Initialisierung "gemutetd" bleibt und erst dann auf Durchzug gestellt wird, also das das ES später als der Eingang initialisiert wird?????

[herw]

Vor dem Hold ist ja langweilig;)

Aber was gibt das unverdrahtete ES eigentlich aus (ist ja son grünes Kabel, wo man nichts "sieht")?
Ich vermute mal, es stellt sicher das der Router während dem "ersten Teil" der Initialisierung "gemutet" bleibt und erst dann auf Durchzug gestellt wird, also das das ES später als der Eingang initialisiert wird?????

ES gibt den booleschen Wert „wahr” aus, wenn an seinem Eingang ein event erscheint und nur dann, ansonsten den Wert „falsch”; allerdings ist dies kein Event, sondern schaltet nur einen nachfolgenden Router (gelbes (!) Kabel). Der Router selbst gibt dadurch noch keinen Event aus. Das ES-Modul reagiert also nur, wenn an seinem Eingang ein event anliegt. Da es hier unbeschaltet ist, reagiert es lediglich bei der Intialisierung. D.h der Router ist im folgenden immer auf „falsch” geschaltet. Durch die Nichtbeschaltung des „wahr”-Zweiges wird also zuverlässig ein Intialisierungsevent herausgefiltert.
ciao herw

[Eventmanager]

Abgesehen von deiner Farbenblindheit süpi Erklärung, danke.
Müsste dann nicht auch ein unverkabeltes Merge oder ein Order mit freigelassenem 1-Port den gleichen Zweck erfüllen, oder werden doch alle Ports abgearbeitet?

[herw]

Abgesehen von deiner Farbenblindheit süpi Erklärung, danke.
Müsste dann nicht auch ein unverkabeltes Merge oder ein Order mit freigelassenem 1-Port den gleichen Zweck erfüllen, oder werden doch alle Ports abgearbeitet?

ein unverkabeltes merge sendet dazu im Gegensatz beim Initialisieren einen Event aus! Order gibt es in Core (leider) nicht.

gelb: deaktivierte Booleverbindung, grün: aktivierte Booleverbindung

ciao herw

[Eventmanager]

Ein dreifach hoch auf Fielmannundco!
Warum nicht gleich steingrau und aschgrau? Oder navi und olive? Petrol und Dunkelmarin wären auch schöne Gegensatzpaare....
Gut zu wissen, das NI ihren GUI_Humor weiter pflegt.
---------

Jup, Merge ist insbesondere beim Init eines der obskursten Elemente - wollte nur wissen, ob du auch zuhörst;)
Aber die Idee mit dem Order? J/N?
Falls J, würde ich dem Order den Vorzug geben - ich glaub hier von dir mal irgendwo den Satz gelesen zu haben: Soviel Core wie möglich und so wenig Prim wie nötig??? Leuchtet mir als Parole nicht ein. Und da ich ein "hartnäckiger-warum-Typ" diskutieren wir das vielleicht besser nicht hier;)
Wenn allerdings sonst niemand zuhört ---- why not?

BTW-PS: Wieso benutzt du das Bewertungs-Adverb "leider"? Wenn in Core alles "gleichzeitig" geschieht, ist das Reihenfolge-Konzept ein überholtes Relikt, das aber bei Bedarf mittels Latch, z1 & Co wiedererweckt werden kann????

...Also ein genereller Core Pro/Contra Fred wäre vielleicht nicht uninteressant. Ganz entspannt und entdogmatisiert. Ich will nix unterstellen, aber sone klitzekleine (eigentlich mikros- ach quatsch: nanoskopische) Idee kreuzfahrer steckt aber schon in dir, oder mein lieber Richard Löwenherz?

[herw]

[...]
Jup, Merge ist insbesondere beim Init eines der obskursten Elemente - wollte nur wissen, ob du auch zuhörst;)
Aber die Idee mit dem Order? J/N?
Falls J, würde ich dem Order den Vorzug geben - ich glaub hier von dir mal irgendwo den Satz gelesen zu haben: Soviel Core wie möglich und so wenig Prim wie nötig??? Leuchtet mir als Parole nicht ein. Und da ich ein "hartnäckiger-warum-Typ" diskutieren wir das vielleicht besser nicht hier;)
Wenn allerdings sonst niemand zuhört ---- why not?

BTW-PS: Wieso benutzt du das Bewertungs-Adverb "leider"? Wenn in Core alles "gleichzeitig" geschieht, ist das Reihenfolge-Konzept ein überholtes Relikt, das aber bei Bedarf mittels Latch, z1 & Co wiedererweckt werden kann????

ein Latch-Modul verzögert um einen sample-Tick. Das ist aber nicht immer erwünscht.

...Also ein genereller Core Pro/Contra Fred wäre vielleicht nicht uninteressant. Ganz entspannt und entdogmatisiert. Ich will nix unterstellen, aber sone klitzekleine (eigentlich mikros- ach quatsch: nanoskopische) Idee kreuzfahrer steckt aber schon in dir, oder mein lieber Richard Löwenherz?

ja, weil core seit fast zehn Jahren sträflich an der Seite steht. Ich arbeite hier nach dem Prizip „steter Tropfen hält den NI-Stein”. Ich hoffe, dass durch einen erhöhten Bedarf der NI-User, indirekt Einfluss auf NI genommen wird.
Direkt versuche ich durch unzählige Mails an NI zu nerven.
ciao herw

[Eventmanager]

Was hast du eigentlich für nen Status dort - nur Beta-tester oder doch etwas Mitspracherecht?
Was ich am meisten vermisse ist ein Sampler mit HD-Streaming, smarten Loop-Editor und der Dateizugriff bequem via Struktur konfigurierbar. Bei fetten Maps wird das Laden zum Geduldsspiel.
Mit den ganzen anderen Kleinigkeiten habe ich mich ausgesöhnt, aber die Sampler sind echte Stiefkinder.

[herw]

Was hast du eigentlich für nen Status dort - nur Beta-tester oder doch etwas Mitspracherecht?
[...]

alpha-Tester; bezogen auf REAKTOR macht das zu einem Betatester allerdings schon seit Jahren keinen erkennbaren Unterschied.
Die Tester bekommen in der Regel einige Wochen vor der Veröffentlichung neue REAKTOR-Versionen; in einem speziellem Forum werden dann verschiedene Umgebungen (standalone, LOGIC, CUBASE, LIVE etc.) getestet. Die Alpha/Betatester können dann Probleme posten und NI reagiert bei wichtigen Problemen sehr schnell (schon nach Stunden), bis dann schließlich die endgültige Version vorliegt. Mein Einfluss zur Version R5.5 (das sollte eigentlich R6 sein) war, dass ich schrecklich aussehende Knobs verhindert habe .
D.h. man wird erst sehr spät eingebunden.Für NI sind die verschiedenen Testumgebungen natürlich wichtig, insbesondere auch die wirkliche Praxistauglichkeit kann nur extern getestet werden.
Im selben Forum können Wünsche geäußert werden. Dies sind oft sehr detaillierte Wünsche. Um dir eine Größenordnung zu geben: es handelt sich um knapp 4000 gemeldete Probleme und Wünsche, allerdings über einen Zeitraum von mittlerweile mehr als zehn Jahren (seit es R5 gibt).
Die im NI-Forum geposteten Wünsche finden dort ebenfalls Beachtung. Auch Bugs, die von dem „normalen” User gemeldet werden, findet man dort wieder. Es geht also nichts verloren.
Manchmal habe ich auch persönliche Kontakte und kann sogar mit ganz speziellen Problemen zu meinen Ensembles kommen: zum Beispiel gab es bei den ersten Versionen von RUHR extreme Ladezeiten; Max Zagler und andere haben mir direkt Tipps gegeben, wie ich die Ladezeit extrem verkürzen konnte.
Anfragen zu künftigen Versionen werden allerdings nicht beantwortet, da die Mitarbeiter von NI der Schweigepflicht unterliegen. Also ich weiß auch nicht mehr. Ich darf natürlich solange ein Test einer neuen Version läuft und noch nichts veröffentlicht wurde, ebenfalls nichts verraten; ich habe extra einen entsprechenden Vertrag unterzeichnen müssen.
Bezahlt wird natürlich nichts, man hat eben nur die neueste Version einige Wochen vorher, was einem einen kleinen Vorteil bringt.
Es gibt hier auch im Forum Mitglieder, die bei NI arbeiten oder gearbeitet haben. D.h. ab und zu melden sich diese hier zu Wort.

[herw]

Das eigentlich Spannende als Tester sind die nachfolgenden Bugs nach der Veröffentlichung, die in den folgenden Wochen und auch Jahren erörtert und gelöst werden. Dort sind die Tester am wertvollsten und bei den wirklich wichtigen Bugs wird sehr schnell reagiert. D.h. NI arbeitet ständig mit einem relativ großen Team an REAKTOR. Des öfteren gibt es auch Querverbindungen zu anderen NI-Programmen und natürlich auch den anderen Softwarefirmen. An der Art der NI-intern gemeldeten Bugs kann man als aufmerksamer Tester auch erkennen, woran gerade gearbeitet wird. Die NI-Mitarbeiter stehen voll hinter dem, was sie entwickeln und sind nach wie vor begeistert. Die Atmosphäre, die in den Anwerbe-Spots vermittelt wird, scheint den Punkt zu treffen:
Live your Passion

ciao herw