Router aktualisiert nicht

[PrinzThomas]

Hallo,

da auf Primary-Ebene ein Router nur maximal 16 Ausgänge hat - ich aber viel mehr benötige - und das verketten von einzelnen Routern zu einen Spinnennetz führt - habe ich das mal als Anlass genommen, um mich näher mit Core zu beschäftigen.
Es sollte schließlich möglich sein in Core so viel Ausgänge wie man möchte routen zu lassen.
Aufgabe sollte sein ein Positionsschalter schaltet die Ausgänge durch.
Der Wert am In-Eingang wird also zu dem Ausgang geroutet auf dessen Wert im Pos-Eingang gezeigt wird - ein Router eben.
Ich muss mir ja schon seit Jahren anhören wie logisch Core aufgebaut ist - nur mit meiner Logik kommt wohl Reaktor nicht ganz klar.
Wenn sich am Pos-Eingang der Wert ändert passiert leider in Echtzeit überhaupt nix - erst wenn ich Reaktor deaktiviere und wieder aktiviere aktualisiert sich das Dingens.
So frage ich mich, was bei meiner Logik da wohl schief läuft und wieso sie nicht mit Core konform geht.
Versuche mit einem Latch / Read & Write Modulen brachten auch keine Änderung.
Im Grunde ist es doch einfach - das Compare vergleicht den Pos-Eingangswert mit einer Konstante und gibt bei Gleichheit TRUE an den Router, der das In-Signal nun zum jeweiligen Ausgang durchlässt.
Warum deckt sich diese Logik nicht mit Core?
Was habe ich falsch gemacht?

[herw]

REAKTOR 5.5 Core Reference Seite 187f Kapitel F17

Das Logiksignal (gelb) schaltet nur den Router um und sendet sinnvollerweise keinen Event.
Erst ein wirklich anliegender Event am Eventeingang in des Routers wird entsprechend geleitet. Das ist logisch.
Wenn Du bei einem Positions-Event mit einem anliegenden in-Wert auch einen Event senden möchtest, dann kannst du mit Hilfe eines Latchmoduls den in-Wert durch den Positions-Event über ein merge-Modul auf den Eventeingang des Routers legen.
Probiere es aus, ansonsten gibt's Hilfe
Solche einfachen Simulationsversuche sind ein guter Einstieg, um ein Gefühl für Core zu gewinnen. viel Spaß!

ciao herw

PS: Core-Cells- und Core-Makros sind ebenfalls in der Zahl der Ein- und Ausgänge beschränkt (maximal 40). Sonst wird es auch unübersichtlich. Abhilfe schafft hier aber der Eventbus , der eine beliebige Zahl von Ein- und Ausgängen ersetzt (zum Beispiel in RAZOR), also nie mehr eine Verharfung!

[PrinzThomas]

Dank dir für die Hilfe.
Ich bin ein kleines Stück weiter jedoch gibts immer noch Probleme.
Jetzt schaltet zumindest der in-Wert auf den jeweiligen Ausgang, aber natürlich muss ja beim wegschalten bzw. wenn das compare FALSE liefert der Ausgang wieder frei werden bzw. nullen.
Der letzte In-Wert bleibt leider am Ausgang weiterhin stehen - egal welchen wert der pos eingang hat.

[PrinzThomas]

Nachtrag:
Nach einer Weile Bastelei habe ich es auch gelöst, dass beim Wegschalten wieder null am Ausgang steht.
Mir kommt das aber reichlich viel Aufwand vor für so eine kleine Aufgabe.
Kann man das irgendwie noch optimieren oder ist da auch grundsätzlich was falsch?

Core-Cells- und Core-Makros sind ebenfalls in der Zahl der Ein- und Ausgänge beschränkt (maximal 40).

Ich bin schon bei knapp 50 Ausgängen.
Ist das vielleicht mit Version 5.6 erweitert wurden?

[herw]

Nachtrag:
Nach einer Weile Bastelei habe ich es auch gelöst, dass beim Wegschalten wieder null am Ausgang steht.
Mir kommt das aber reichlich viel Aufwand vor für so eine kleine Aufgabe.
Kann man das irgendwie noch optimieren oder ist da auch grundsätzlich was falsch?

Das ist für den Einstieg eine gute und konsequente Lösung.
Du hast die Idee der Eventverarbeitung schon gut verstanden (sorry, dass ich hier lehrerhaft eine Bewertung abgebe das macht der Beruf; aber es soll ein aufrichtiges Lob sein).
Eine Optimierung von solchen Router-Abfragen ist nach dem Grundsatz zu beurteilen: so viel Router wie nötig - so wenig Router wie möglich.
Routerabfragen kosten viel CPU, nicht in deinem Beispiel, das ist nichts; ich rede von hunderten oder gar tausenden von Routern im Audiotakt. Da ist es schon wichtig, ob man die Zahl der Routerabfragen vielleicht auf die Hälfte oder weniger reduzieren kann; vergleiche die neuen Module in R5.5 die bis zu 10000 (!) Obertöne verarbeiten müssen. Es ist eine gute Übung solche logischen Abfragen zu optimieren. Dazu sollte man sich mal Gedanken darüber machen, wie viele Abfragen pro event, hier zum Beispiel durch die Pos-Änderung, tatsächlich stattfinden. Du hast in deinem Beispiel jede Position einzeln abgefragt. Erweitere das Beispiel mal nur zur Übung auf 8, 16 oder 32 Abfragen und du wirst erkennen, dass eine duale Abfrage (pos >15, pos >7, pos >3, pos >1) zu wesentlich weniger Routern und logischen Vergleichen führt. Das ist Optimierung an der richtigen Stelle!
Eine Optimierung hängt auch stark von der wirklichen Anwendung ab, da geht es ans Eingemachte. Das ist zum Beispiel für mich der Reiz, den Core ausmacht. Es ist ein Kampf um die CPU-Last, der immer wieder fasziniert, vor allem, wenn die Ansprüche an die Anwendung steigen; keine Angst vor hohen Ansprüchen; hier liegt die Stärke von Core, nicht in der simplen Übertragung von primary in die Core-Ebene. Die Ansprüche muss man so hoch steigern, dass man zum Schluss kommt: primary kann das nicht; nichtsdestotrotz bin ich kein Apostel für Core allein. Ich erkenne durchaus an, dass primary optimale Strukturen und Lösungen aufweist, auf die man in Core leider keinen Zugriff hat. Im Moment ist die geschickte Kombination aus primary und core angesagt. Ich arbeite daran, dass Core immer mehr der hervorragenden Eigenschaften von primary übernimmt (Rufer in der einsamen Wüste).

Core-Cells- und Core-Makros sind ebenfalls in der Zahl der Ein- und Ausgänge beschränkt (maximal 40).

Ich bin schon bei knapp 50 Ausgängen.
Ist das vielleicht mit Version 5.6 erweitert wurden?

nein, hier muss man über ganz neue Datenstrukturen denken. Auf der reinen Event-Verarbeitung von GUI- (direkte Eventverarbeitung) oder Audio-getakteten Events (meistens 400Hz) bringt der Eventbus optimale Reduzierung, die nicht mehr zu verbessern ist. Vergleiche mal einen kleinen Beitrag zum Eventbus in einem anderen Thread. Die Ausführungen dort betrachten nur einen Ausschnitt von schätzungsweise 5% der Möglichkeiten. Was dort nur mit wenigen Ein- und Ausgängen möglich ist, ist fantastisch.
Im reinen Audio-Bereich (44100Hz) ist das schwieriger oder gar unmöglich. Die Beschränkung auf maximal 40 Ein- und Ausgänge (insgesamt) mag eine Beschränkung sein, wenn man vom primary-Bereich in die Core-Ebene wechseln will. Ich kenne deine Anwendung nicht, aber verarbeitest du wirklich 50 polyphone oder auch monophone Audioquellen? Wie schon oben erwähnt: reine Steuerungssignale lassen sich auf einen Eingang reduzieren.
Audiosignalverarbeitung lässt sich natürlich durch parallele Core-Makros auch mehr als 50 Stränge verarbeiten, solange du in Core bleibst und die 50 Signale nicht nach primary rückführen möchtest. Innerhalb Core, kannst du letztendlich alles irgendwie zusammenführen, so dass du bei Stereo oder (5-1) endest.

Ich hoffe, dass du „Blut geleckt” hast

zu deinem konkreten Lösungvorschlag: etwas ungewöhnlich ist jetzt, dass du eine Eventübertragung des Eingangs in nur erhältst, wenn die Position pos geändert wird. Ich weiß nicht, ob das deine Intention ist. Wenn Du auch bei Änderungen am in-Eingang übertragen möchtest, dann musst du hinter dem ersten Latch-Modul noch ein merge einfügen, dessen unterer Eingang den in-Eingang zuführt. Dann hast Du auch eine Eventübertragung, wenn keine Positionsveränderung stattfindet. Wenn Du Audio-Signale verarbeitest, dann ist dies kein Problem, da sowohl pos-Eingang, wie auch in-Eingang ohnehin SampleRate-getaktet sind und somit ständig abgefragt werden. Aber überlege genau, ob eine Positionsabfrage wirklich ständig im SampleRate-Takt notwendig ist. Das sind die „Probleme”, mit denen man sich in core wirklich auseinandersetzen muss. In primary kann man das gar nicht erst betrachten, da man so tief nicht in die Struktur eingreifen kann, sondern sich mit dem zufrieden geben muss, was angeboten wird.

ciao herw

[PrinzThomas]

Dank dir für deine deatailierten Ausführungen.
Ich habe bis eben eine Routermatrix von 3 x 36 ... also insgesamt 108 Routern gemacht.
Das dumme daran - es gibt doch noch einen Fehler. ^^
Jetzt kann ich alles noch einmal von vorn beginnen - vorallem die Scrolliste um an ein bestimmten Quickbus zu kommen ist echt nervig.
Da sollte NI etwas unternehmen - die Liste einfach ab einer bestimmten Anzahl in die Breite ziehen wäre bereits schon hilfreich.
So muss man ewig scrollen.
Der Fehler ist, dass zwar der pos-Eingang dynamisch ist, aber nicht der In-Eingang.
Der muss aber in Echtzeit übertragen, da darüber LFO-Daten usw. rennen.

Kurz zur Erklärung, was ich vorhabe und was ich über PRimary natürlich schon gelöst habe.
Ich möchte 3 mal eine verschiedene Modulationsquelle und Modulationsziel angeben.
Diese 3 Modstränge addieren sich automatisch wenn identische Quellen + Ziele angegeben werden.
Im Anhang ist meine Core-Lösung dazu - aber leider ist der In-Eingang nicht dynamisch und überträgt irgendeinen Quatsch. ^^
Die Addierungen der einzelnen Router habe ich aus Übersichtsgründen mit Quickbuse gelöst sonst würde man da nur noch weißes Gewirr sehen.
Meine Primary-Lösung ist auch als Vergleich mit dabei damit du weißt, was ich möchte, denn diese funktioniert einwandfrei.
Aber hat ein ganz ganz übles Spinnenetz!
Deshalb wollte ich es in Core umsetzen.
Die einzelnen mod-quellen kommen als Receiver an - den habe ich aber jetzt nicht mit ins Ensemble gepackt.
Vielleicht kannst du dir das mal anschauen.

[PrinzThomas]

Nachtrag:
Es gibt leider noch ein 2tes Problem:
Der In-Wert wird erscheint am Ausgang als gerundete Ganzzahl, was ich natürlich nicht möchte.
Es soll exakt der Wert raus kommen, der vorne reinkommt und dass dann auch noch in Echtzeit und nicht erst wenn man schaltet.
Mensch ist das kompliziert für ein bischen "mist". ^^

Nachtrag 2:
Diese - entschuldige die Ausdrucksweiße - dämlichen Merge Module stehen standardmäßig auf Int statt auf Float.
Hab also das 2te Problem gelöst.
Bleibt nur noch das erste, dass In-Werte ständig übertragen werden sollen und nicht erst wenn geschaltet wird.

[herw]

[...]
Bleibt nur noch das erste, dass In-Werte ständig übertragen werden und nicht erst wenn geschaltet wird.

ich schaue es mir später an; heute habe ich einen 12-Stunden-Arbeitstag und anschließend noch einen Konzertbesuch.
Ich kann mich also frühestens am Donnerstag Abend daran setzen.
Zur kontinuierlichen Weiterreichung des In-Wertes siehe meine Bemerkung mit dem Merge-Modul in der letzten Post.

ciao herw

[PrinzThomas]

Habs gerade eben hinbekommen.
Ja ich muss natürlich mit den Merge noch mal extra in den Eingang des Routers.
So sieht meine Lösung jetzt aus.
Was könnte man da noch optimieren?
Ich finde immer noch ein bischen viel Aufwand für so eine Standard-Aufgabe.

[herw]

kleine Verbesserungen kann man machen:

routing1.jpg (94.32 KiB) 4974-mal betrachtet

die vierfache latch-merge-Kombination kann man durch eine ersetzen und mit Quickbus verteilen (orange Kasten);
die Routerabfragen habe ich mal durch eine einzige ersetzt (gelber Kasten) und dann mit Hilfe von Bit-Logik-Makros (and) und (xor) die Eventwerte 0 bzw. 1 aus dem pos-Event erzeugt. Daduch brauche ich nur noch mit dem Wert val zu multiplizieren.
Ob das effektiver ist, muss man natürlich speziell ausprobieren. Ich wollte mal einfach eine andere Herangehensweise zeigen.
Hier bietet sich auch die Möglichkeit, selbst Spezialmakros zu erzeugen, um eventuell auch Verteiler für 8, 16 oder mehr Wege zu erzeugen.
Core lebt davon, dass man eine eigene Bibliothek erzeugt. In diesem Beispiel erkennt man unschwer gleichartige Teilstrukturen, die man der besseren Übersicht gut zu Makros zusammenfassen kann.
Es lohnt sich sicherlich auch, die hier verwendeten Spezialmakros mal genauer zu untersuchen.

ciao herw

[PrinzThomas]

Ja auf die Latch-Merge Reduktion hätte man auch kommen könne, wenn ich das jetzt so sehe
In meinem Kompensator-Thread hattee ich das ja auch schon so gemacht.
Allerdings finde ich die Reduktion des Routermoduls nicht unbedingt effektiver.
Aber die Idee mit dem mit dem Multiplikator am Ende ist trotzdem nett.
Rein nach Aufwand her wäre die optimalste Lösung dann einfach diese (siehe Bild)
18 Module zur Lösung dieser Aufgabe.
Schau mal in mein Ensemble oben - da sind allerdings noch die alten Fehler drin, was baer ja nichts zur Sache tut.
Es geht darum, dass ich da natürlich schon Macros erzeugt habe um damit den Router quasi zu vergrößern und trotzdem die Übersicht zu behalten.
Ich habe das in 4er Macros gestaffelt damit ich beim zusammenschalten der Macros Platz spare.

[herw]

[...]
Rein nach Aufwand her wäre die optimalste Lösung dann einfach diese (siehe Bild)
18 Module zur Lösung dieser Aufgabe.
[...]

Naja, beim Zählen hast Du natürlich ein wenig gefudelt, da du ja fünf latch-Makros benutzt, die wiederum zwei Module enthalten Den Aufwand bei der Konstruktion eigener Makros darf man nicht an der Anzahl der benutzten Module messen, sondern an der Sicherheit (insbesondere der Initialisierungssicherheit) und am CPU-Verbrauch. An letzteres Kriterium komme ich nur durch Selbststudium und, wenn ich Glück habe, durch seltene Kommentare von NI-Entwicklern, die manchmal in Handbüchern, Telefonaten und eMails generelle Aussagen machen, welche Modulanordnungen man möglichst vermeiden sollte oder in geringer Stückzahl benutzen sollte.
Will man ein ganzes Geflecht von Makros erstellen, kann es auch mal zweckdienlich sein, etwas ungünstigere Strukturen zu entwickeln, damit der gedankliche Aufwand nicht Überhand nimmt.
Ich habe über meine oben beschriebene Lösung lange nachgedacht, ob ich sie so präsentieren oder eine allgemeine Lösung vorstellen sollte.
Ich habe mich dann entschlossen, die kleine Lösung vorzustellen und dort insbesondere die eher „fremden” Module zu benutzen, da man sie leicht übersieht, damit die Gedanken auch mal in andere Richtungen gehen.
Wie du sicherlich schon bemerkst, liegt der Reiz in Core unter anderem auch darin, praktische speziell an deine Vorlieben angepasste Makros zu entwickeln.
Auch der Vergleich von Lösungen zum selben Problem, wie in diesem Fall, schafft ungemein viel Erfahrung.

ciao herw

[PrinzThomas]

Ich fudele halt gern mal hier und dort.

Es gibt einen Bereich, der mich tatsächlich sehr antreiben würde in Core tiefer einzusteigen - nämlich das Simulieren von elektronischen Bauelementen.
Glaubst du, dass es möglich wäre Widerstände, Transistoren und Kondensatoren in Core zu simulieren?
Dann könnte man nämlich auf den Gedanken kommen ganze Schematics nachzubauen um so eine echte Emulation zu erwirken.

Ziemlich grob umrissen könnte man sich erst einmal folgendes denken:
- Widerstand mit Hilfe eines Multiplikators
- Transistor mit Hilfe eines Routers + Multiplikator
- Kondenstator mit Hilfe eines Latches + S&H

Glaubst du das wäre machbar?

[herw]

Ich fudele halt gern mal hier und dort.

Es gibt einen Bereich, der mich tatsächlich sehr antreiben würde in Core tiefer einzusteigen - nämlich das Simulieren von elektronischen Bauelementen.
Glaubst du, dass es möglich wäre Widerstände, Transistoren und Kondensatoren in Core zu simulieren?
Dann könnte man nämlich auf den Gedanken kommen ganze Schematics nachzubauen um so eine echte Emulation zu erwirken.

Ziemlich grob umrissen könnte man sich erst einmal folgendes denken:
- Widerstand mit Hilfe eines Multiplikators
- Transistor mit Hilfe eines Routers + Multiplikator
- Kondenstator mit Hilfe eines Latches + S&H

Glaubst du das wäre machbar?

Das ist sehr vereinfacht gedacht. Allein schon die Anordnung eines RC-Giedes kann zu einem Differentiator oder Integrator führen. Diese „Bauteile” gibt es ja schon in primary - ansonsten habe ich dazu keinen Plan; die Zeiten des „Lötens” und Schraubens habe ich Gott sei Dank rechtzeitig vor über drei Jahrzehnten abgelegt. Das muss und will ich nicht auf den Computer übertragen. Ich bin froh, dass man mit digitalem Denken so viel weiterkommt.

[macrospank]

herw wrote:

....welche Modulanordnungen man möglichst vermeiden sollte.

Hi herw !

Würde mich sehr über etwas mehr details zu dem Thema freuen.