Iteration

[KlangRaum]

Mir geht da so eine Idee durchn Kopp: Ich stell das mal hier ein, unabhängig von meinen eigenen mikrokopischen Forschungen....
Wie könnte man in Core eine Iteration realisieren die innerhalb eines Clock-Cycle (!) eine festgelegte aber auch begrenzte Anzahl Events (zB 0...63) erzeugt. Das ganze sollte auch bei der SR.C funktionieren. Ziel ist, das man Strukturen über Tabellen indiziert ansprechen kann und damit redundante Berechnungen reduziert.

Gruss
Peter

[herw]

Mir geht da so eine Idee durchn Kopp: Ich stell das mal hier ein, unabhängig von meinen eigenen mikrokopischen Forschungen....
Wie könnte man in Core eine Iteration realisieren die innerhalb eines Clock-Cycle (!) eine festgelegte aber auch begrenzte Anzahl Events (zB 0...63) erzeugt. Das ganze sollte auch bei der SR.C funktionieren. Ziel ist, das man Strukturen über Tabellen indiziert ansprechen kann und damit redundante Berechnungen reduziert.

Gruss
Peter

was dir alles so an Gedanken während in den Kopp kommt
Zusätzliche Events während eines Clock-Cycles auch mit SR.C. sind möglich und nicht nur 64 sondern wesentlich mehr.
In einem kleinen Rahmen habe ich das auch mal (für mich) gemacht. Was aber eher theoretisch interessant war.
Die Audioausgänge einer AudioCorecell lassen nicht nur SR.C-synchrone Events heraus, sondern auch alles, was dazwischen passiert. Das grundsätzliche Problem besteht darin, dass man zwar während eines Audio-Rate-Zyklus eine Menge zusätzlicher Events hineinpacken kann, aber ein zielsicherer Zugriff schwierig ist.
Es entsteht zum Beispiel ein Konflikt, wenn ein Audiostream mit zusätzlichen z.B. 1024 Events gerade läuft; bevor jedoch die 1024 events „abgearbeitet” sind, startet eventuell schon der nächste Audio-Zyklus. D.h. man muss auf eventuelle Unterbrechungen des zwischengeschalteten Eventstreams noch achten.
Das ist äußerst komplex.
Ein ähnliches Problem gibt es schließlich bei allen Programmiersprachen, die ja zum Beispiel ein Programm laufen lassen, aber im Hintergrund ständig eine Abfrage einer Maus- oder sonstigen Aktion haben.
Also sehr sehr schwer.
Aber zeig mal deine Versuche. Vielleicht kann man darauf eingehen.

ciao herw

[Rampensau]

Vor einer gewissen Zeit, habe ich damit experimentiert. Die Versuche waren sogar wider Erwarten erfolgreich.
Ich hatte konkret mit Summenformeln experimentiert.
Heraus kommen, sollten "additiv" zusammengesetzte Grundwellenformen. So musste natürlich eine vorgegebene Anzahl von n Durchläufen für jede Sr.Clock aufsummiert werden. Mit wachsender Zahl von n Durchläufen, wächst auch die Zahl von n Harmonischen, rast auch die CPU über den Jordan.

Mit der Summenformel werden zwar keine Berechnungen reduziert, die Struktur wird mit wachsendem n jedoch um einiges eleganter.

Das Ganze liefert gültige Ergebnisse, stößt aber an die Grenzen der CPU.

Für eine relativ kleine Anzahl an Iterationen, kann man das durchaus machen.
Ich werd mein "additiv"-Oszillator gleich mal hochladen...

[herw]

Vor einer gewissen Zeit, habe ich damit experimentiert. Die Versuche waren sogar wider Erwarten erfolgreich.
Ich hatte konkret mit Summenformeln experimentiert.
Heraus kommen, sollten "additiv" zusammengesetzte Grundwellenformen. So musste natürlich eine vorgegebene Anzahl von n Durchläufen für jede Sr.Clock aufsummiert werden. Mit wachsender Zahl von n Durchläufen, wächst auch die Zahl von n Harmonischen, rast auch die CPU über den Jordan.

Mit der Summenformel werden zwar keine Berechnungen reduziert, die Struktur wird mit wachsendem n jedoch um einiges eleganter.

Das Ganze liefert gültige Ergebnisse, stößt aber an die Grenzen der CPU.

Für eine relativ kleine Anzahl an Iterationen, kann man das durchaus machen.
Ich werd mein "additiv"-Oszillator gleich mal hochladen...

Da kannst Du doch stattdessen das neue primary Modul Sine Bank (ab R5.5.1) benutzen. Dort kannst du hunderte und mehr Grundwellenformen addieren; angeblich beherrscht REAKTOR bis zu einer Zahl von 10.000 (!!) Obertönen und zwar polyphon; siehe das Playerensemble PRISM. Die CPU ist wenig belastet. Dieses Modul ist sensationell!

ciao herw

[Quietschboy]

Die Audioausgänge einer AudioCorecell lassen nicht nur SR.C-synchrone Events heraus, sondern auch alles, was dazwischen passiert.

Uff, da bin ich jetzt aber platt!

Es entsteht zum Beispiel ein Konflikt, wenn ein Audiostream mit zusätzlichen z.B. 1024 Events gerade läuft; bevor jedoch die 1024 events „abgearbeitet” sind, startet eventuell schon der nächste Audio-Zyklus.

Jetzt bin ich noch platter...
Hieße das nicht, daß eine Audiocell für Event und SR-Clocked Signale "parallel" existiert und abgearbeitet wird? Ansonsten müßte doch die Abarbeitung des nächsten Sampleticks warten, bis alle asynchronen Events durch sind. Sprich, der Audiopuffer muß dann halt mal herhalten. Das gilt natürlich nur für die Events, welche es überhaupt "schaffen", innerhalb der zwei SR.C Ticks erstmal in die Audiocell zu gelangen. Dann würde in Primary Audio und Event aber auch parallel existieren. Aber Event Overflows in Primary (Iterator) können doch auch Audioknackser verursachen? Oder nicht? Dann wäre die Abarbeitungsreihenfolge schön brav nach dem Motto "Vordrängeln gilt nicht!"
Ich bin jetzt etwas verwirrt, aber das Thema Abarbeitung interessiert mich gerade echt brennend! Vor allem im Zusammenhang mit Core Audio Cell - bzw. auch in Verbindung Primary zu Core zu Primary. Deine Erkenntnis, Herw, könnte nämlich durchaus mit meinem momentanen "Problemchen" zu tun haben:
Es heißt ja, Ein- und Ausgänge von Core Zellen sind grundsätzlich böse zur CPU...
Aus diesem Grund ersetzte ich testweise 5 Eventeingänge einer Audiocell durch eine Multiplexleitung (Partial Frameworks).
Das erstaunliche Ergebnis war nun, daß ich damit insgesamt eine höhere CPU Belastung hatte, als mit den 5 Einzeleingängen. Auf den Leitungen passiert nicht allzu viel - ca. 2-4 Datenevents alle 8tel oder 16tel Note insgesamt, je nachdem. Auf jeden Fall schien mir der Multiplex (Primary)/Demultiplex (Core) Aufwand nicht für eine derart angestiegene CPU Last verantwortlich zu machen. Zugegebener maßen ist das eine Bauchgeschichte, aber verglichen mit dem, was da sonst noch alles im Ensemble und v.a. in besagter AudioCoreCell passiert, sollte sich aufm CPU Meter mit den paar lächerlichen Events eigentlich nicht viel tun.
(Die Audiocorecell existiert insgesamt 5x, somit auch 5 Mux/Demux --> Einzeleingänge: ca27,8%, Multiplex: ca30,0% CPU Auslastung @ CORE I5 auf 1600MHZ runtergetaktet [/langweilmodus aus])

Ich kanns mir bis jetzt nur so erklären, daß entweder der Multiplex-/Demultiplexaufwand tatsächlich so hoch ist und den Leistungsbedarf mehrer Event-Ins überschattet, oder aber die Asynchronität der Events ansich, bzw deren asynchrone Abarbeitung zur SR.C den Codeablauf negativ beeinflußt (also so oder so das Mux/Demuxing).
Oder aber es hat irgendwie (auch?) was mit Verschachtelung zu tun, welche sich negativ auf den Programmablauf auswürgt. Ok, lassen wir das jetzt mal. Ist auch nur so ein Bauchgefühl (Stichwort: überproportionale CPU Auslastung bei duplizierten Macros. Vorallem in Verbindung mit Multiplexleitungen??? Oder Generell?)

Eventuell ziehen Event-Ins ja auch nur Saft, wenn tatsächlich ein Event anliegt. DAS wäre natürlich auch mal sehr interressant zu wissen.

Ich überlege schon, mal einen "CORE Optimieren" Thread aufzumachen. Hätte ja da doch noch so ein paar quälende Fragen, aber auch kleine Erkenntnisse.
Die Tage mal...

Gruß, Mark

[herw]

Reine event-cells belasten die CPU überhaupt nicht. Iterationen in Verbindung mit audiocorecells sind dann problematisch, wenn sie bei jedem sample tick stattfinden sollen.
Gerald List (krümelmonster) hat mal mit parallelen audio-streams gearbeitet, die in event-streams umgewandelt werden.
ich habe auch mal ein Beispiel konstruiert, mit dem man in einer einzigen audiocorecell mehrere Effektstränge modular verknüpfen konnte ohne ein sample Versatz (ähnlich wie im ensemble finger, aber ohne eine einzige Struktur doppelt anlegen zu müssen). Es ist möglich, aber REAKTOR ist dafür nicht gemacht.
Auch eine Ansteuerung von eventcorecells mit einer äußeren SampleRateClock kann man ausprobieren. Alles machbar aber eben viel CPU-lastiger als direktes Programmieren.
Trotzdem ist es interessant, in diesem Gebiet zu "forschen", man lernt dabei Vieles über Reaktor, auch die Grenzen.

Um auf deine ursprüngliche Frage zurückzukommen: Iterationen aus einer audiocorecell sind, so lange sie nicht zu häufig auftreten, machbar. Du findest ein entsprechendes chain iteration Modul im partial frameworks.
Ich habe es noch nicht ausprobiert, aber es ist wohl so gut gestaltet, dass es die im letzten Jahr angesprochenen möglichen Probleme mit den eventuell zwischenzeitlich eintreffenden SampleTicks beherrscht.
Max Zagler hat damit ein Wunderwerk geschaffen.

Ciao herw

[Rampensau]

[...]
Da kannst Du doch stattdessen das neue primary Modul Sine Bank (ab R5.5.1) benutzen. [...]

ciao herw

Das Sinebank-Modul lässt in einigen Belangen zu wünschen übrig.
Bsp FM, PM, PD, Sync-
Ist mit der Sinebank (nicht alles) im Frequenzbereich möglich, und wenn dann sehr akademisch.
Im Zeitbereich lässt sich die Sinebank kaum durch solche einfachen Sachen würzen....

Außerdem ist mir aufgefallen, dass die Partials nicht synchron sind.
Nach einer Zeit im Leerlauf verformt sich das Signal durch Phasenverschiebungen höllisch.

Daher greife ich lieber auf andere Techniken zurück....

Grüße

[Rampensau]

[...]
ich habe auch mal ein Beispiel konstruiert, mit dem man in einer einzigen audiocorecell mehrere Effektstränge modular verknüpfen konnte ohne ein sample Versatz (ähnlich wie im ensemble finger, aber ohne eine einzige Struktur doppelt anlegen zu müssen). Es ist möglich, aber REAKTOR ist dafür nicht gemacht.[...]

Genau diesen Beitrag habe ich mal vergeblich gesucht... Ich konnte nicht rekonstruieren, wo ich mal darüber gestolpert bin.
Für jeden Hinweis wäre ich dankbar.

[herw]

[...]
ich habe auch mal ein Beispiel konstruiert, mit dem man in einer einzigen audiocorecell mehrere Effektstränge modular verknüpfen konnte ohne ein sample Versatz (ähnlich wie im ensemble finger, aber ohne eine einzige Struktur doppelt anlegen zu müssen). Es ist möglich, aber REAKTOR ist dafür nicht gemacht.[...]

Genau diesen Beitrag habe ich mal vergeblich gesucht... Ich konnte nicht rekonstruieren, wo ich mal darüber gestolpert bin.
Für jeden Hinweis wäre ich dankbar.

das Beispiel habe ich nicht veröffentlicht, es ist auch sehr theoretisch und in REAKTOR nicht sehr zu empfehlen.
Es basiert auf asynchronen Audiosignalen, die von außen in eine audiocorecell über einen Eventeingang eingeschleust werden.
Ich kann noch mal danach suchen. Die Effektstränge sind einfache mathematische Berechnungen wie clipping, Spiegelung etc. In dem Beispiel ging es nur darum zu zeigen, dass man die Reihenfolge von mathematischen Berechnungen verändern kann, ohne Teilstrukturen der Corecell nochmals duplizieren zu müssen. Also eine Corecell, deren Struktur man von außen (durch einen Wahlknopf) verändern kann. Wie gesagt sehr theoretisch. Im Ensemble FINGER ist dies gar nicht erst versucht worden. Wenn du dort in die Struktur siehst, erkennst du, dass die Effektstränge mehrfach vorliegen.
Hier ist schon mal etwas zum Nachlesen (asynchrone Audiosignale).

ciao herw

PS: ich habe das Beispiel gefunden:

Effektkette 1.ens.zip

Die Effektkette besteht aus sechs frei wählbaren Effekten:

Effektkette 3.jpg

links siehst du ein Eingangssignal (in diesem Fall eine Sinuskurve).
Rechts davon siehst du die Effekte, die man über einen Drehknopf einstellen kann.
Alle Effekte sind in einer einzigen AudioCorecell vereinigt und existieren nur einmal. Die Audiocorecell erhält von außen eine sechsfach asynchrone Eventclock, die mit Samplerate arbeitet (Makro fx-Verteiler). Wenn Du in dieses Makro hineinschaust siehst du zwei Möglichkeiten, wie man asynchrone Audioclocks erzeugen kann (durch eine Iteration und einen Bus oder mehrere Eventausgänge).

Effektkette 2.jpg

Ich kann nun mit sechs Drehreglern die Effekte in ihrer Reihenfolge auswählen (auch mehrfach). Innerhalb eines SampleRateTicks, werden diese sechs Effekte durchlaufen.
Ich kann sie sogar einzeln an den Audioausgängen abgreifen (Zwischenergebnisse).

Effektkette 1.jpg

Um kompliziertere Effekte wie Filter, Hall etc. zu verknüpfen, ist eine komplizierte Logik erforderlich. Das war mir dann doch zu anstrengend. Es reicht, wenn man das Prinzip mal gesehen hat. Ob sich das lohnt, oder man doch die Strukturen mehrfach erzeugt bzw. einen SampleRateTick-Versatz in Kauf nimmt, ist ungeklärt.

[Rampensau]

besten Dank...
Filteranordnungen wollte ich auf die Art mal ausprobieren....

Ob das in Reaktor nun sinnvoll ist, macht ja nichts..
Wenns danach geht, habe ich bisher eh nur wenig Sinnvolles in Reaktor vollbracht.

Grüße