Vergleichbares zu Switch in Core?

[Triton]

Gibt es eine Möglichkeit, in einer Corecell flussaufwärts Teile per Eventsteuerung abzuschalten? Da ist mir nur das Flussabwärts-Event-Routing bekannt. Im Primary isses genau entgegengesetzt, da kenn ich keinen Weg, ein Signal so aufzuteilen, dass die Module dahinter bei Bedarf deaktiviert sind.

Will momentan einen fft-Pitchshifter die Blöcke interpolieren lassen, was aber nicht immer was (ehrlich gesagt bislang noch garnix) bringt (ringmodulator lässt ständig klanglich grüßen), aber cpu-gefräßig ist und deshalb an-/abschaltbar sein soll. Hätt aber auch so generell Verwendung für bedarfsweises Abschalten von Teilen einer Cell (flussaufwärts).

Grüßle

[herw]

Gibt es eine Möglichkeit, in einer Corecell flussaufwärts Teile per Eventsteuerung abzuschalten? Da ist mir nur das Flussabwärts-Event-Routing bekannt. Im Primary isses genau entgegengesetzt, da kenn ich keinen Weg, ein Signal so aufzuteilen, dass die Module dahinter bei Bedarf deaktiviert sind.

Will momentan einen fft-Pitchshifter die Blöcke interpolieren lassen, was aber nicht immer was (ehrlich gesagt bislang noch garnix) bringt (ringmodulator lässt ständig klanglich grüßen), aber cpu-gefräßig ist und deshalb an-/abschaltbar sein soll. Hätt aber auch so generell Verwendung für bedarfsweises Abschalten von Teilen einer Cell (flussaufwärts).

Grüßle

Ich habe das Thema auf Anregung von klangraum (Peter) ins core-Unterforum verschoben, da deine Frage wohl eher die Core-Ebene betrifft.

Ich nehme an, dass du Audio-Core-Cells benutzen möchtest. Deren Audio-Eingänge werden durch die Samplerate-Clock getaktet. Man kann versuchen, nur Event-Eingänge zu benutzen. Da ja trotzdem Audiosignale verarbeitet werden sollen, müssten diese auf primary-Ebene künstlich in Eventsignale umgewandelt werden, die trotzdem mit AudioRate eingeführt werden; dies gelingt über ein A-to-E-perm-Modul, das mit Audiosamplerate getaktet wird.

aufwärts abschaltbar.jpg

In der AudioCoreCell selbst wird die SR.C über einen Router wieder zugeführt und patcht den eventeingang. Dies ist nötig, wenn man von außen mehrere solche audio-Signale verknüpfen will und eine Gleichtaktung wieder herstellen möchte. Siehe hierzu aber umgekehrt die Bemerkungen von Krümelmonster (Gerald List) in einem anderen Thread über Nichtgleichzeitigkeit von Signalen.
Ob das allerdings einen CPU-Vorteil ergibt, kann man nicht generell beantworten; das hängt von der speziellen Anwendung ab. Man verschiebt eigentlich das Problem auf das A-to-E-perm Modul. Wenn man nur wenig Rechenoperationen durchführt, ist das nur scheinbar attraktiv, jedoch steigt die Belastung sehr schnell, wenn viele Rechnungen durchgeführt werden. Generell sind solche Kunstkniffe CPU-mäßig wenig attraktiv.
Natürlich muss auf primary-Ebene das zugeführte Audiosignal ebenfalls abgeschaltet werden.

ciao herw

[Triton]

Ooooh, vielen Dank. So einen "Signal-Damm" versuch ich mal umzusetzen. Glaub, die (vermutlich extrem "teure", also CPU-gefräßige) Wandlung in Events muss man gar nicht machen, weil ein nicht-durchgeleitetes Audiosignal ja auch die folgenden Verarbeitungen nicht triggert (so ein bisschen irgendwie doch, aber die Last sinkt deutlich). Nur dann eventuelle Sample-Clocks in den Makros dann noch abtrennen bzw. auch vor den ich nenn's mal Damm klemmen.

Wo ich das gebrauchen könnt, wären zum einen Filter, wo dann z.B. 10 Pole verbaut wären und bei Bedarf z.B. nur 2 oder 6 genutzt werden. Oder aber zusätzliche EzFFT-Blöcke, die weggeschaltet werden (die Dinger sind ja eh der Hammer, freu mich immer mehr dran).

Thx a lot.

[herw]

geeenauuu!

ciao herw

[Triton]

Das ist CPU-mäßig doch recht praktisch, weil man mit einem einzigen zentralen Router hinkommt, den Rest können alles Latches, die von dessen Signal getriggert werden, machen.

Naja, muss auch dazu sagen, ich denk immer, ich müsst optimieren (bis hin zu Core-Makros in eine Ebene höher auflösen, von wegen Overhead beim Transfer rein und raus) hab dann aber echte Klöpse in den Strukturen (z.B. viermal float nach int und rückwärts hintereinander). Manchmal ist es doch nicht schlecht, die Anleitung mal richtig gelesen zu haben. Dacht immer, viel Routen ist dolle und hab wie ein Held geroutet, um Rechen-Last zu reduzieren. Der Abschnitt "wie Sie optimale Strukturen bauen" sagt da doch wat anderes.