herw hat geschrieben:Bitte versuch's mal mit meinem Ensemble!
Hab ich gemacht.
Sry, Herwig, wenn ich wiedersprechen muss.
Nichts für ungut, aber - : Was hast Du verändert ?
4 Konstanten. Drei davon sind Inkremente des Counters. Die verändern ausschließlich den Betrag der Wertausgabe und zwar bei Dir dahingehend, dass die Zählerstände ab dem ersten Triggervorgang verschieden sind (die sich ergebenden verschiedenen Folgenbildungen tun hier ja nichts zur Sache).
Ich finde, dass diese Maßnahme den Blick für den Sachverhalt, um den es mir geht, eher verschleiert.
Die vierte Konstante ist die Gelatchte ausserhalb des Counters. Die "4", durch die Du die ursprüngliche "1" ersetzt hast, verhält sich im einzigen nachfolgenden Test ( >0 ?) exakt gleich. Mit anderen Worten: Strukturell hast Du nichts verändert.
herw hat geschrieben: ... Danach wird dieser Zwischenspeicher mit Audiorate ständig unverändert ausgelesen. Also logisch, dass eine 1 ausgegeben wird.
Nein, es wird nichts mit Audio-Rate ausgelesen.
herw hat geschrieben:Im zweiten Zweig wird der Latchwert 4 zwar über das merge-Modul zugeführt aber beim nächsten SR-Clock (Wert immer 0) überschrieben
Nein, es wird nichts überschrieben. Im Counter nicht, da Events <0 durch den Separator geblockt werden und am Merger davor auch nicht, weil sie NICHT gleichzeitig mit der SR.C. sind.
Das ist der entscheidende Punkt. Der Grund für den thread.
Die quickbubble über dem wire zwischen Merger und Counter mag nie eine "4" anzeigen (Trägheit von Auge und Display), überschrieben wird der Wert nicht. Er geht einfach durch.
herw hat geschrieben:Im dritten Zweig wird der Latchwert 4 beim nächsten Sample-Tick durchgereicht.
Der Latchwert 4 gelangt gleichzeitig (synchron zum Sample-Tick) als Triggerevent an das Auslesemodul des dritten Zwischenspeichers ...
Nein. Nein, nein, nein, ... Der Triggerevent ist NIE gleichzeitig mit der SR.C.
Sonst käme er nicht durch den Router !
Der entscheidende Punkt. Wieder.
Ich finde das höchst beindruckend.
Die
Gleichzeitigkeit in Core ist eine solche per declarationem: ' Alle Events, deren Ursprung ein und derselbe ist, sind gleichzeitg'. Gut.
Hier geht es um den Umkehrschluss:
"Alle Events, deren Ursprung nicht ein und derselbe ist, sind nicht-gleichzeitig." Auch nicht-gleichzeitig mit der Sample-Clock.
Die Konsequenzen daraus kann man an beiden Beispielen erkennen.
Für die meisten dürften daraus nie Probleme entstehen.
Bei der Klangerzeugung mit Oszillatoren in AudioCoreCells benutzt Du doch immer - und zwar bewußt - die Vorteile der
Gleichzeitigkeit, die durch die SR.C. entsteht.
Bei der Eventverarbeitung in EventCoreCells macht man von beiden Prinzipien Gebrauch; eine SR.C. als interne synchronisierende Maßnahme fällt weg.
Solange diese beiden Dinge nicht in AudioCore kollidieren, gibt es keine Probleme.
Ich hatte sie auch nie.
Deswegen war ich auch über einen NI-thread, den ich mal raussuchen sollte, sehr überrascht, in dem CList irgendwo ein Beispiel für diese Problemzone gibt: Eine Ramp, die ein Modulationssignal steuert, soll mit einer EXTERNEN, somit in jedem Falle nicht-gleichzeitigen Midi-Clock synchronisiert werden. Durchaus lösbar. Aber wenn es wirklich sauber sein soll ein Graus.
Mein "Problem" derzeit - eigentlich ist es gar keins - ist, ebenso eigentlich, kleiner:
Man hat ja JEDERZEIT die Möglichkeit, einkommende Events mit der SR.C. zu synchronisieren.
Ich frage mich nur, ob ich mich in meinem Falle nicht mit dieser Maßnahme vieler Möglichkeiten beraube.
In meinem Fall reichen Eventketten, deren Ursprung Event-Eingänge sind, sehr tief in den Raum einer AudioCoreCell. Das sind jetzt schon reichlich Berechnungen, die ich nur ungern mit der SR.C. synchronisieren würde. Irgendwann treffen diese Welten aber dann doch aufeinander.
Um den Zusammenhang zwischen diesen Welten - und darum, wie man sie dazu bringen kann, sich selbst zu ordnen - ging es in diesem Beispiel.
Wie gesagt, kaum einer wird damit je Probleme bekommen; ich versuche nur, das zu nutzen.
herw hat geschrieben:(kauf Dir einen gescheiten Rechner
)
Hab einen.
Könnte nur ein bischen neuer und somit flotter sein
Viele Grüße, Gerald.
Ich habe mir gerade die Finger wundgetriggert und alles läuft bestens.
