erstes simpel macro (gescheitert)

[Eventmanager]

Was soll das Teil leisten?
Im Prinzip soll es simple Signale clippen, die Besonderheit: sobald der Treshold unterschritten ist, soll es auf 0 springen.
Aber irgendwas begreife ich grundsätzlich nicht, bspw. ist es dem Compair-Ausgang verboten sich direkt "zu outen" resp. wird er intern gelb verdrahtet????
Beim Router gehe ich mal davon aus, das er analog zu Prim arbeitet, also bei 0 am Relais 0 ausgibt und bei WAHR den (einzigen!!!) Eingang durchschleift.

[herw]

Was soll das Teil leisten?
Im Prinzip soll es simple Signale clippen, die Besonderheit: sobald der Treshold unterschritten ist, soll es auf 0 springen.
Aber irgendwas begreife ich grundsätzlich nicht, bspw. ist es dem Compair-Ausgang verboten sich direkt "zu outen" resp. wird er intern gelb verdrahtet????
Beim Router gehe ich mal davon aus, das er analog zu Prim arbeitet, also bei 0 am Relais 0 ausgibt und bei WAHR den (einzigen!!!) Eingang durchschleift.

Die gelbe Verbindung ist ein Logik-Signal und dient nur zur Steuerung von Routern. Das Signal selbst ist nicht wirklich sichtbar (ein Wunsch für zukünftige REAKTOR-Versionen) und bewirkt im Gegensatz zur primary-Ebene keinen Event, das heißt es schaltet einfach nur; das erscheint auch viel sinnvoller!
Das clip-Makro macht übrigens schon alles, was du wünschst:

Bild 1.jpg

Bild 2.jpg

ciao herw

[Eventmanager]

Die gelbe Verbindung ist ein Logik-Signal und dient nur zur Steuerung von Routern. Das Signal selbst ist nicht wirklich sichtbar (ein Wunsch für zukünftige REAKTOR-Versionen) und bewirkt im Gegensatz zur primary-Ebene keinen Event, das heißt es schaltet einfach nur; das erscheint auch viel sinnvoller!
Das clip-Makro macht übrigens schon alles, was du wünschst:

Ich hab mich wohl missverständlich ausgedrückt: Es soll bei unterschreitens jedes beliebigem Tresholdes auf Null springen. Das macht der Clipper per se nicht. Er bleibt am TS-Wert stehen.
In Prim erledigt Schalte im Bild das zuverlässig - nur bin ich an dieser simplen Core_umsetzung eben schon gescheitert;-)

[herw]

Die gelbe Verbindung ist ein Logik-Signal und dient nur zur Steuerung von Routern. Das Signal selbst ist nicht wirklich sichtbar (ein Wunsch für zukünftige REAKTOR-Versionen) und bewirkt im Gegensatz zur primary-Ebene keinen Event, das heißt es schaltet einfach nur; das erscheint auch viel sinnvoller!
Das clip-Makro macht übrigens schon alles, was du wünschst:

Ich hab mich wohl missverständlich ausgedrückt: Es soll bei unterschreitens jedes beliebigem Tresholdes auf Null springen. Das macht der Clipper per se nicht. Er bleibt am TS-Wert stehen.
In Prim erledigt Schalte im Bild das zuverlässig - nur bin ich an dieser simplen Core_umsetzung eben schon gescheitert;-)

Was verbirgt sich im angezeigten screenshot in der corecell? Vielleicht lädst du besser das ensemble hier hoch (eventuell musst du es zippen). Ich bin sicher, dass sich deine Idee sehr einfach realisieren lässt. Mit einem hochgeladenen Beispiel ersparen wir uns viele unnötige Nachfragen; zum Beispiel: soll die Änderung des Tresholds auch eine Eventausgabe bewirken oder soll diese erst erfolgen, wenn ein Event am „Haupteingang” erscheint; hier reagieren nämlich primary und core-Router völlig verschieden. Core ist dort viel flexibler.

ciao herw

[Eventmanager]

IN der Corecell ist lediglich der Clipper aus den Screenies von oben, nix weiter.
Nein, eine TS-Änderung soll KEIN Event erzeugen.
Aber lass mich erstmal selbst probieren, gibt mir bitte nur mal nen Tip, wo ich falsch . Wieso funzt meine Core_schalte nicht, ist doch das gleiche wie in Prim. Ist beim Relais noch irgendwas zu beachten?
Andere Frage: wieso ist es beim Compair sinnvoller, das es kein Event ausgibt? Wenn ich nur den Wahr/Unwahr-Wert brauche, ist es doch ökonomischer das es das Teil auch gleich sendet, statt noch ein extra Modul zu bemühen?

Ein integrierter Stepfilter wäre noch schön.

[herw]

IN der Corecell ist lediglich der Clipper aus den Screenies von oben, nix weiter.
Nein, eine TS-Änderung soll KEIN Event erzeugen.
Aber lass mich erstmal selbst probieren, gibt mir bitte nur mal nen Tip, wo ich falsch . Wieso funzt meine Core_schalte nicht, ist doch das gleiche wie in Prim. Ist beim Relais noch irgendwas zu beachten?
Andere Frage: wieso ist es beim Compair sinnvoller, das es kein Event ausgibt? Wenn ich nur den Wahr/Unwahr-Wert brauche, ist es doch ökonomischer das es das Teil auch gleich sendet, statt noch ein extra Modul zu bemühen?

Ein integrierter Stepfilter wäre noch schön.

warum es sinnvoller ist, dass kein event gesendet wird, da müsste ich jetzt passende Beispiele heraussuchen, aber ich stelle mal die provokante Gegenfrage warum ein routing automatisch einen event senden sollte? Ich denke mal das ist das normale Verhalten. Man darf nicht in den Fehler verfallen, die Einschränkungen, die primary hat als Maßstab nehmen zu wollen.

Für deine Lösung: ich habe eine fertige Schaltung (sogar zwei Lösungen). Aber da du ja selbst forschen willst hier der Tipp:
Nimm anstelle des compare Moduls (das keinen Event sendet) das Logikmakro GT (greater than):

GT.jpg

es sendet tatsächlich einen event (0/1). Mit einer weiteren Grundrechenart hast du das entsprechende Problem gelöst. In dieser Version sendet es auch, wenn TS geändert wird. Du kannst es aber relativ leicht ändern, wenn du dich mal mit dem Inneren des GT-Makros beschäftigst. Dort wirst du die core-event-logic verstehen.
Ein stepfilter ist das makro dup flt (event processing)

Viel Spaß

herw

[Eventmanager]

Aja! Dank deiner Schützenhilfe war es tatsächlich simpel. Merci.
Mit TS-Änderung ist übrigens auch interessant: ein Ein-Wert-Seperator! Kann ich auch gebrauchen:)

Missverständnissvorbeugend befinden sich im Screenie noch 2 weitere Module, nur damit wir (eher wohl ich;) nicht Rubens mit Rembrandt verwechseln.
Hier meine Beobachtungen und Vermutungen:
Das (>) Compair ist also anders als sein Pseudo-Pendant in Prim. Das GT entspricht dem Prim-Compare.
Das GT lässt sich nicht mit dem Router-Schalter verbinden, das "compare" hingegen schon (aha, es gibt kleine gelbe Dreiecke als Indikatoren, löblich).
Ich schlussfolger mal, das die Gelben sich nur core-intern bestöpseln lassen und Non-Trigger-"Events" darstellen, die den Schaltzustand VOR der
eigentlichen Werteänderung sicherstellen sollen, richtig?
Ja, mir fallen einige Szenarien, wo das tatsächlich sinnig ist.

Ins GT rein? Ick weeß nich! Ich denke ich bleib erstmal auf der "Instrumenten"-Ebene. In Prim hab ich mich auch so sukzessive vorgewagt, entspricht wohl eher meinem Lernstil.
Ich denke als erstes werd ich die Event- und Logic-Macros VON AUSSEN abklappern. Gute Idee, oder sollte ich vorzugsweise mit was anderem beginnen?

[herw]

Aja! Dank deiner Schützenhilfe war es tatsächlich simpel. Merci.
Mit TS-Änderung ist übrigens auch interessant: ein Ein-Wert-Seperator! Kann ich auch gebrauchen:)

Missverständnissvorbeugend befinden sich im Screenie noch 2 weitere Module, nur damit wir (eher wohl ich;) nicht Rubens mit Rembrandt verwechseln.
Hier meine Beobachtungen und Vermutungen:
Das (>) Compair ist also anders als sein Pseudo-Pendant in Prim. Das GT entspricht dem Prim-Compare.
Das GT lässt sich nicht mit dem Router-Schalter verbinden, das "compare" hingegen schon (aha, es gibt kleine gelbe Dreiecke als Indikatoren, löblich).
Ich schlussfolger mal, das die Gelben sich nur core-intern bestöpseln lassen

richtig

und Non-Trigger-"Events" darstellen, die den Schaltzustand VOR

falsch; es gilt auch immer die Gleichzeitigkeit!

der
eigentlichen Werteänderung sicherstellen sollen, richtig?
Ja, mir fallen einige Szenarien, wo das tatsächlich sinnig ist.

Ins GT rein? Ick weeß nich! Ich denke ich bleib erstmal auf der "Instrumenten"-Ebene. In Prim hab ich mich auch so sukzessive vorgewagt, entspricht wohl eher meinem Lernstil.
Ich denke als erstes werd ich die Event- und Logic-Macros VON AUSSEN abklappern.

ganz falsch! diese Logik Makros sind fundamental einfach und erläutern sehr gut die core Denkweise

Gute Idee, oder sollte ich vorzugsweise mit was anderem beginnen?

gute Idee and RTFcoreM it's one of the best

Bild 1.jpg

[Eventmanager]

Gleichzeitigkeit ist ein theoretisches konstrukt, in der Praxis gibts das nicht mal auf der Quantenebene. Sofern mich nicht alles täuscht ist die Planck-Zeit das letzte Interval kontinuierlicher Zeit, darunter findet Zeit quantisiert, gewissermassen als kosmologische Samplerate statt, mit dem Ergebniss das 2 kohärente Ereignisse unterhalb der Planck-Einheit (nach heutigem Wissen) nie simultan, sondern stets sukzessive auftreten. Für die kontinuierliche Zeit gilt das ohnehin.

In der Praxis irrelevant, ich wollt nur mal auf die Kacke hauen;) Betrachten wir alles, innerhalb eines Sampletrate-Taktes Stattfindendes als "gleichzeitig", dann hab ich das so verstanden, das in einer Corecell, vom moment eines "Trigger-Events" alle darin befindlichen (non-Trigger) Events ihre "Sub-Event-Aktionen" durchführen, also quasi gleichzeitig, ein Ergebniss aber erst beim nächsten "Trigger" an die Aussenwelt geliefert wird. Ist das so ungefähr richtig?

-----------------
Ja, deine Lösung 3 ist natürlich viel effizienter - typischer Fall von Wald vor Bäumen;-)

_________________

Ich hab mir mal das Flipflop gefittichet und wollte es mit nem Reset versehen, der sicherstellt, das (falls) resetet hinten auf jeden Fall das Reset-Value anliegt (egal ob da nun gerade 0 oder 1 anlag).
in meinem kurzen Praxistext funzt es, aber wirf mal sicherheitshalber bitte ein Blick drauf.

BTW: Das türkise Draht zwischen dem read/write, ist doch ein bidirektionaler Strang, also HIn-und Rückverkabelung in einem, etwas das "gleichzeitig" stattfindet?

[herw]

Gleichzeitigkeit ist ein theoretisches konstrukt, in der Praxis gibts das nicht mal auf der Quantenebene. Sofern mich nicht alles täuscht ist die Planck-Zeit das letzte Interval kontinuierlicher Zeit, darunter findet Zeit quantisiert, gewissermassen als kosmologische Samplerate statt, mit dem Ergebniss das 2 kohärente Ereignisse unterhalb der Planck-Einheit (nach heutigem Wissen) nie simultan, sondern stets sukzessive auftreten.

es gibt dann noch die Quantenverschränkung

Für die kontinuierliche Zeit gilt das ohnehin.

In der Praxis irrelevant, ich wollt nur mal auf die Kacke hauen;) Betrachten wir alles, innerhalb eines Sampletrate-Taktes Stattfindendes als "gleichzeitig", dann hab ich das so verstanden, das in einer Corecell, vom moment eines "Trigger-Events" alle darin befindlichen (non-Trigger) Events ihre "Sub-Event-Aktionen" durchführen, also quasi gleichzeitig, ein Ergebniss aber erst beim nächsten "Trigger" an die Aussenwelt geliefert wird. Ist das so ungefähr richtig?

falsch, da zwischen zwei samplerate-Ticks noch jede Menge zusätzlicher Events stattfinden können und auch wirken. Dafür ist es wichtig, den Gleichzeitigkeitsgrundsatz zu kennen. Alles, was durch dieselbe Quelle erzeugt wurde, wird als logisch gleichzeitig angesehen, d.h. jeder berechnete Wert im Anschluss findet formal gleichzeitig statt. Beachte, dass Audiocorecells sowohl event- wie auch audio-Eingänge haben. Abgesehen davon, dass die event-Eingänge nur auf einzelne events reagiern, können die audioeingänge zusätzlich zu den audio-getakteten audio-events auch noch die normalen events verarbeiten. Lediglich der Ausgang einer audio-core-cell ist durch die sample-rate getaktet. Trotzdem kann man die zusätzlichen events herausfiltern. Gerald List hat ein solches Makro entwickelt und dann gibt's ja noch den ACEW (audiocoreeventwatcher), der auf Geralds Idee aufbaut.

-----------------
Ja, deine Lösung 3 ist natürlich viel effizienter - typischer Fall von Wald vor Bäumen;-)

_________________

Ich hab mir mal das Flipflop gefittichet und wollte es mit nem Reset versehen, der sicherstellt, das (falls) resetet hinten auf jeden Fall das Reset-Value anliegt (egal ob da nun gerade 0 oder 1 anlag).
in meinem kurzen Praxistext funzt es, aber wirf mal sicherheitshalber bitte ein Blick drauf.

hab ich jetzt gerade keine Lust zu, da ich Freitag und Samstag durchgearbeitet habe und eigentlich völlig platt bin.

BTW: Das türkise Draht zwischen dem read/write, ist doch ein bidirektionaler Strang, also HIn-und Rückverkabelung in einem, etwas das "gleichzeitig" stattfindet?|/quote] bidirektional ist nicht ganz richtig, da schon die Anordnung der write und read-Module wichtig ist. Du musst hierzu das Core Manual unbedingt lesen. Es kann hier durch ungünstige Verkabelungen auch zu Widersprüchen kommen. Da arbeitet NI dran; ist aber für sehr vertrackte Rückkoppelungen äußerst schwierig. Die meisten Benutzer bemerken dies aber gar nicht, da die Strukturen viele einfacher sind.

Zum Thema Nicht-Gleichzeitigkeit gibt einen immer wieder frischen Thread und mit leidenschaftlicher Diskussion zwischen meinem Freund Gerald List (Krümelmonster, cookiemonster) und mir. Ich weiß nicht wie viele Wochen wir darüber uns schon bei viel Kaffee und gutem Essen die Köpfe heiß geredet haben.

Manchmal glaubten wir die Geichzeitigkeit überlistet zu haben, doch dann war REAKTOR mal wieder bockig. Das, was hier angesprochen wird, ist aber völlig klar und unproblematisch.

ciao herw

[Eventmanager]

Ok, zwischen 2 Samplerate-Takten, passen noch ein paar CPU-Schleifen, da hast du natürlich Gott sei Dank Recht.
FORMAL gleichzeitig klingt sehr gut. Schön Gesprochen!

Andere Frage: Das Read/Write-Gespann - wenn ich das Value-Modul öffnen könnte, würde es doch genau lediglich aus diesen beiden Elementen bestehen, oder?
Jedenfalls hab ich es so gebaut und es hat (zumindest nach ersten Versuchen) genau die Value-Modul Funktionalität.

PS: Ja, ja, ich schreite ganz gemächlich vorran;)

[herw]

Ok, zwischen 2 Samplerate-Takten, passen noch ein paar CPU-Schleifen, da hast du natürlich Gott sei Dank Recht.
FORMAL gleichzeitig klingt sehr gut. Schön Gesprochen!

Andere Frage: Das Read/Write-Gespann - wenn ich das Value-Modul öffnen könnte, würde es doch genau lediglich aus diesen beiden Elementen bestehen, oder?
Jedenfalls hab ich es so gebaut und es hat (zumindest nach ersten Versuchen) genau die Value-Modul Funktionalität.

PS: Ja, ja, ich schreite ganz gemächlich vorran;)

es heißt nicht formal gleichzeitig, sondern logisch gleichzeitig D.h. die Schaltung wird, egal wie kompliziert sie ist, nur in Abhängigkeit des erzeugenden events berechnet.
Aber egal, hier noch zwei wichtige Zusätze:
- Die Speicher müssen von der gleichen Art (integer oder float) sein, damit man die OBC-Verbindung aufbauen kann.
- Möchtest du den Speicher initialisieren, dann baut man als erstes Glied noch ein write-Modul mit einer Konstanten ein, ansonsten wird der Speicher immer auf 0 initialisiert.

Initialisierung.jpg

ciao herw

[Eventmanager]

Danke. Jo, die Init-Funktion kann ich wohl demnächst gebrauchen, siehe hier: http://www.reaktor-forum.de/viewtopic.php?f=9&t=984
Das Integer schlecht "aufwärtskompatibel" ist leuchtet ein, aber Float nicht "abwärtskompatibel"?
Egal, guter Tip, ich werde sorgsam drauf achten.