PrinzThomas hat geschrieben: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).
herw hat geschrieben: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