Deutsches Reaktor Forum

das thema geistert hier ja durch verschiedene threads: sinn und unsinn von eventloops. mich würde ein konkretes beispiel interessieren:
ein event-taktgeber (clock-osc oder rechteck-LFO) triggert eine mathematische berechnung und das resultat wird wieder als ausgangswert eingesetzt.
ohne eventloops.

herws birne qualmt bestimmt schon

... meine auch...

magneton hat geschrieben:das thema geistert hier ja durch verschiedene threads: sinn und unsinn von eventloops. mich würde ein konkretes beispiel interessieren:
ein event-taktgeber (clock-osc oder rechteck-LFO) triggert eine mathematische berechnung und das resultat wird wieder als ausgangswert eingesetzt.
ohne eventloops.

wo ist das Problem?
Ich habe nicht gesagt, dass ich eventloops unsinnig finde. Nur ich vermeide sie möglichst; das ist mir bei allen bisher erstellten ensembles gelungen.
Das kann natürlich daran liegen, dass ich an solchen oben angegebenen Anwendungen im Moment kein Interesse habe.
Wenn ich eventloops in anderen ensembles begegnet bin, dann waren sie so konstruiert, dass gar nichts mehr funktionierte, wenn die Option "globally disable eventloops" aktiviert war.
Meine Forderung ist, dass man die Lösung einer bestimmten Ensemble-Struktur so formulieren sollte, dass kein eventloop nötig ist.
Dabei muss man natürlich sehen, was überhaupt an einem eventloop problematisch ist. Für mich ist der Fall problematisch, dass quasi ein gleichzeitiges Abarbeiten eines Eingangswertes und eines Feedback-Wertes zeitgleich mit dem dann wieder erstellten Feedback-Wert erfolgen soll; das kann natürlich ohne eine Abbruchregel nicht geschehen.
REAKTOR vermeidet dies durch Taktung.
Dass überhaupt diese Option (Ausschalten der eventloops) existiert, ist meiner Ansicht nach ein reines Entgegenkommen der Entwickler von REAKTOR. Aber es gibt natürlich jede Menge Eventloops, die ohne Fehlermeldung erforderlich sind, alleine schon jeder Oszillator hat einen solchen Eventloop, der aber durch die Z^-1 Funktion aufgelöst wird. Dies kann man doch auf event-Ebene ebenfalls durchführen durch das unit-delay-Modul.

Das Prinzip der heute gängigen Mikroprozessoren basiert ja gerade auf dem (genialen) Gedanken der von Neumann Maschine: alles ist getaktet.
Natürlich wünscht man sich andere (vielleicht analoge) Strukturen, die ohne diesen Takt auskommen. Dann muss man allerdings philosophieren. Ist es z.B. einer "Maschine" Mensch möglich, einen Eventloop zu verkraften? Sicherlich nicht, da wir mit unseren Gedanken ja auch den physikalischen Gesetzen unterworfen sind.
Um auf REAKTOR zurückzukommen:
Es geht auch ohne unit-delay:

Wohl bemerkt: die Option "globally disable eventloop" ist aktiviert! Trotzdem funktionieren diese Strukturen.
Ich will sagen: man muss eventloops so formulieren, dass sie konform sind mit den Strukturen, die REAKTOR zulässt.
Ein weiteres interessantes Beispiel ist das folgende: der Button startet und stoppt einen Zyklus an jeder beliebigen Stelle.

Damit habe ich aber nur einen sehr einfachen digitalen Sägezahnoszillator simuliert, der durch das "Gate"-Signal des Buttons gestartet wird.
ciao herw

herw hat geschrieben: (...)
Ich will sagen: man muss eventloops so formulieren, dass sie konform sind mit den Strukturen, die REAKTOR zulässt.
(...)

... na dann sind wir uns ja völlig einig.

puuuh , also sagt mal, können wir das nochmal für die klassenschwächeren wiederholen? also nur das erste bild.

denken wir mal das unitdly weg, wo entsteht ohne ein eventloop?
passieren diese loops nicht nur, wenn man events rückverkabelt?

helmsklamm hat geschrieben:puuuh , also sagt mal, können wir das nochmal für die klassenschwächeren wiederholen? also nur das erste bild.

denken wir mal das unitdly weg, wo entsteht ohne ein eventloop?
passieren diese loops nicht nur, wenn man events rückverkabelt?

Die Eventloops entstehen, wenn REAKTOR bei der Berechnung oder Auswertung einen Wert benötigt, der durch dasselbe Modul erst erzeugt werden muss, grob gesprochen passiert das, wenn man "rückverkabelt" wie du sagst.

Wenn in der Preferenzen von REAKTOR "globally eventloop disabled" deaktiviert ist, dann akzeptiert REAKTOR dies trotzdem und baut (unsichtbar) ein sogenanntes Unitdelay ein (genauso wie in CoreCells ein Z^-1). D.h. mit der Auswertung wird genau ein Audiosample (1/44100 s) gewartet. Bei Events im PrimaryLevel ist das keine große Sache, da Events sowieso nur mit ControlRate (meistens 400Hz) aktualisiert werden. Bis dahin ist dieser Audiosample schon längst geschehen.
Bei Audiosignalen, die routen sollen, kann es schon mal auf einen genauen Zeitpunkt ankommen, also sollte man dies selbst besser direkt unter Kontrolle haben durch punktgenaue (sprich SampleRate-genaue) Ereignisse.
Ich aktiviere daher grundsätzlich immer "globally eventloop disabled" und erhalte dann eine entsprechende Fehlermeldung. Ich baue dann die Struktur so um, dass diese Fehleranzeige vermieden wird. Dies erfordert bei wenig Erfahrung erst einmal Mehrarbeit, gibt aber hinterher sehr stabile Strukturen. Wie du an den anderen beiden Beispielen sehen kannst kann man einen solchen Konflikt auch durch einen Audio/Event-Konverter (A/E-Modul) lösen. Auch das akzeptiert REAKTOR, da nun durch einen eindeutigen Takt (ControlRate) die Auswertungsreihenfolge eindeutig festgelegt ist.
Das Rückkoppeln von Werten taucht häufig auf, wenn Anzeigen und Panelelemente auf mehrere Arten aktualisiert werden sollen (durch Maus oder Snaps zum Beispiel).

ciao herw

hi herw, vielen, vielen dank, dass du nochmal auf dieses (nich-beliebt-aber-nötig) thma eingehst.

herw hat geschrieben: Die Eventloops entstehen, wenn REAKTOR bei der Berechnung oder Auswertung einen Wert benötigt, der durch dasselbe Modul erst erzeugt werden muss, grob gesprochen passiert das, wenn man "rückverkabelt" wie du sagst.

mM! aber wo entsteht in deinem 1. bild die/der eventloop (sieht man mal vom unitdly ab?)
sind die reaktor-"primarys" nich darauf optimiert, das sie dergleichen aufjden fall vermeiden - also: so mal rein "intuitiv" - würde doch bedeuten, dass ich als "ent-anwender" mir zumindest bei koorekter "nach vorn verdrahtung"erstmal zunaächst überhaupt keine gedanken machen musss?

sorryy, muss hier abrechen - hatte, schonmal "komplett" geantet, aber durch falschen klick komplett alles ver-nirvanerrt. (also inclusive zitat-edings, antworts, zitats, antworts....etc. verloren)

aber vielleicht is das auch ok, <<-- zwingt mich zum "selbst-überlegen-müssen" anstelle des bequemeren antworten-erwartens.

wobei speziell indiesem fred, antworten, bzw. sehr didaktische hinweise schon besser wären >>>bei obigem prob würd ich wahrscheinlich zeit vertrödeln, falls ich slebstständig die antwort suchen müsste.

www = wieso, weshalb, warum?

helmsklamm hat geschrieben:hi herw, vielen, vielen dank, dass du nochmal auf dieses (nich-beliebt-aber-nötig) thma eingehst.

herw hat geschrieben: Die Eventloops entstehen, wenn REAKTOR bei der Berechnung oder Auswertung einen Wert benötigt, der durch dasselbe Modul erst erzeugt werden muss, grob gesprochen passiert das, wenn man "rückverkabelt" wie du sagst.

mM! aber wo entsteht in deinem 1. bild die/der eventloop (sieht man mal vom unitdly ab?)
sind die reaktor-"primarys" nich darauf optimiert, das sie dergleichen aufjden fall vermeiden - also: so mal rein "intuitiv" - würde doch bedeuten, dass ich als "ent-anwender" mir zumindest bei koorekter "nach vorn verdrahtung"erstmal zunaächst überhaupt keine gedanken machen musss?

sorryy, muss hier abrechen - hatte, schonmal "komplett" geantet, aber durch falschen klick komplett alles ver-nirvanerrt. (also inclusive zitat-edings, antworts, zitats, antworts....etc. verloren)

aber vielleicht is das auch ok, <<-- zwingt mich zum "selbst-überlegen-müssen" anstelle des bequemeren antworten-erwartens.

wobei speziell indiesem fred, antworten, bzw. sehr didaktische hinweise schon besser wären >>>bei obigem prob würd ich wahrscheinlich zeit vertrödeln, falls ich slebstständig die antwort suchen müsste.

www = wieso, weshalb, warum?

sorry helmsklamm,
ich habe mir für die obige Antwort sehr viel Zeit genommen (auch für mehrfaches Redigieren meines Antworttextes);
mit Deiner Reaktion stehe ich etwas ratlos da, da ich manche Deiner Abkürzungen, Wortkürzungen bzw. -veränderungen nur mit Mühe verstehen kann.
ciao herw

PS: ohne das unitdelay entsteht natürlich überhaupt kein eventloop, da dann keine Rückwärtsverdrahtung vorhanden ist.

...mit Deiner Reaktion stehe ich etwas ratlos da, da ich manche Deiner Abkürzungen, Wortkürzungen bzw. -veränderungen nur mit Mühe verstehen kann.

sorry, du hast natürlich recht, das soll hier kein forum für kryptologen werden.

PS: ohne das unitdelay entsteht natürlich überhaupt kein eventloop, da dann keine Rückwärtsverdrahtung vorhanden ist.

das war so in etwa die frage. aber: ich lese mir deine ausführungen nochmal genau durch, und erst wenn ich glaube, zumindest den ansatz begriffen zu haben, FORMULIERE ich meine frage(n). <- dürfte heute allerdings nix werden, war gestren noch "um die ecke" und bin gelinde gesagt heute etwas unpässlich;)

helmsklamm hat geschrieben: ... heute etwas unpässlich;)

"suboptimal!"

handelt es sich bei einer schaltung bei der ein oszillator im spiel ist wirklich um einen eventloop? ist es nicht vielmehr ein audio feedback? dabei muss freilich ein unitdelay gesetzt werden, und das ist auch kein brechen der regeln - das ist ja eine elementare DSP technik.
baut man ein unitdelay in eine eventschleife ein, wird es ein audio-, kein eventstram. das wirkt sich auf den CPU verbrauch aus.
ich hätte besser formuliern sollen beim starten des threads:
wie vermeidet man eventloops ohne den einsatz von unitdelays oder A/E convertern? (die schaltung soll auch unabhängig von controlrate bedingter taktung sein).

@herw:
sollte man nicht das iterations modul verwenden?
das ist eine spekulative frage, denn ich habe das modul mangels verstehen noch nicht eingesetzt.

magneton hat geschrieben:handelt es sich bei einer schaltung bei der ein oszillator im spiel ist wirklich um einen eventloop? ist es nicht vielmehr ein audio feedback?

Wie im Handbuch beschrieben, macht man auf Core-Ebene keinen Unterschied mehr zwischen Events und Audiosignalen. Dies ist eigentlich nur notwendig, um den Übergang zur PrimaryLevel sauber zu gestalten.
Wenn Du mal die CORE-Sonde von Gerald List aus der Library herunterlädst, dann wirst Du sehen, dass es keinen Unterschied gibt.

dabei muss freilich ein unitdelay gesetzt werden, und das ist auch kein brechen der regeln - das ist ja eine elementare DSP technik.
baut man ein unitdelay in eine eventschleife ein, wird es ein audio-, kein eventstram. das wirkt sich auf den CPU verbrauch aus.
ich hätte besser formuliern sollen beim starten des threads:
wie vermeidet man eventloops ohne den einsatz von unitdelays oder A/E convertern? (die schaltung soll auch unabhängig von controlrate bedingter taktung sein).

Ich glaube nicht, dass es darauf eine generelle Antwort gibt. Das hängt von der jeweiligen Situation ab, ob man eine Struktur auch so gestalten kann, dass es zu keinen Eventloop kommt.

@herw:
sollte man nicht das iterations modul verwenden?
das ist eine spekulative frage, denn ich habe das modul mangels verstehen noch nicht eingesetzt.

Das angegebene Beispiel diente nur zur Illustration, dass man die Einstellung "globally disable eventloops" immer aktiviert lassen kann.
Vielleicht haben wir uns da missverstanden. Natürlich ist die erste Schaltung quasi ein Iterator, das war aber auch der Zweck der Übung.

ciao herw