smoother/selector verbund

[helmsklamm]

hier n kleiner trick, der uU ne ganze menge module spart:

ihr nehmt n selector (curve =lin oder sin) und nen smooth. jetzt geht euer signal einmal trocken in den ersten selector-in und nochmals, mit vorgeschalteten smooth in den zweiten selector-in. das wars!

und wozu das ganze? nun, jetzt könnt ihr zwischen SOFORT und ALLMÄHLICH ANSTEIGEND blenden, bspw. als glide-simulation oder als speed-regler für filtermodualtion, oder oder oder.

mit den smooth werten müsst ihr experimentieren, das ist natürlich fallspezifisch.

[PrinzThomas]

Die Idee ist prima allerdings funzt das nicht ganz so nach meinen Vorstellungen.
So müsste ja ein Wert von 0,5 am POS Eingang die Halbierung des Smoothers bedeuten, was leider nicht der Falll ist.
Es ist vielmehr eine direkte Mischung von 0ms Verzögerung und z.B. 100ms beim Smooth.
Ich suche nämlich auch immer noch nach einer Möglichkeit einen stufenlosen Glideregler z.B. für Filtersprünge ect. zu erstellen.
Schön wäre es wenn man einfach die Millisekunden des Smoothers regeln könnte.
Das wäre die Lösung vieler Glide-Probleme!

[helmsklamm]

du hast natürlich recht, man erhält somit keinen echten 50ms smoother, aber
hast du mal nen A/B vergleich gemacht für "50ms" auf diesem weg und und nem echten 50ms-smoother?

für viele zwecke ist dieser unterschied in der praxis völlig ignorierbar, das hörgefühl des einfadens ist hiermit gut zu imimitieren.

aber falls dir das nicht authentisch genug ist, kannst du dir natürlich auch nen 16ner selector bauen (curve = none), mit 15 verschiedenen smoothern, dann haste zumindest n paar verschiedene DIREKT zur auswahl.

aber ich stimme dir zu, das die mesiten sachen, die über die props geregelt werden auch in ner big-modul variante direkt in der struktur angeboten werden sollten. (implemientiert sind sie ja bereits, es bräuchte nur eines/mehrerer zusäzlichen IN, nix weiter) das würde bei minimalaufwand (für NI und die schrauber) nochmal nen gehörigen schub geben.

[PrinzThomas]

hehehe... ich hatte mir vorhin gerade auch einen 16 fach selector mit kleineren smooth stufen zusammen gebastelt.
leider hört man einen deutlichen unterschied zwischen 50 ms und einen mit selector erzielten mittelwert.
und theoretisch könnte man so eine stufenlösung ja mit anderen mitteln ja sogar auf 100 erweitern.
kommt halt auf den aufwand drauf an.

[herw]

hehehe... ich hatte mir vorhin gerade auch einen 16 fach selector mit kleineren smooth stufen zusammen gebastelt.
leider hört man einen deutlichen unterschied zwischen 50 ms und einen mit selector erzielten mittelwert.
und theoretisch könnte man so eine stufenlösung ja mit anderen mitteln ja sogar auf 100 erweitern.
kommt halt auf den aufwand drauf an.

und warum versuchst Du es nicht mal mit einem slew limiter?

Bemerkung: 1/50ms = 20Hz
ciao herw

[helmsklamm]

hehehe... ich hatte mir vorhin gerade auch einen 16 fach selector mit kleineren smooth stufen zusammen gebastelt.
leider hört man einen deutlichen unterschied zwischen 50 ms und einen mit selector erzielten mittelwert.

reden wir annander vorbei?
wenn die selector-curve auf none gestellt ist, ist es, als hättest du den 50ms direkt verdrahtet, denn er selektiert das teil komplett und muted alle anderen ins, also es gibt definitiv keine mittelwerte.

richtig gute glides und keine "simulation" dessen, findest du bereits in der factory-lib. der vorschlag oben bezieht sich auf sachen wo es nich so exakt sein muss, also bspw. um zwischen hart quantisierter oder sanfter einfädende modulation zu überblenden. und da erfüllt der simple patch seine aufgabe, zumindest für meine ohren, erstaunlich gut.


@herw:
naja, dat ding is halt audio. aber andre frage, wenn up/dwn gleich, gibts dann ne art sinus?

[herw]

...@herw:
naja, dat ding is halt audio. aber andre frage, wenn up/dwn gleich, gibts dann ne art sinus?

Was hast Du nur gegen Audiosignale? Reaktor ist eine Software, die primär für Audio gedacht ist.

ciao herw

[herw]

hehehe... ich hatte mir vorhin gerade auch einen 16 fach selector mit kleineren smooth stufen zusammen gebastelt.
leider hört man einen deutlichen unterschied zwischen 50 ms und einen mit selector erzielten mittelwert.

reden wir annander vorbei?...

ich glaube ja; bitte stellt doch mal einen screenshot hier ins Netz

[helmsklamm]

Was hast Du nur gegen Audiosignale? Reaktor ist eine Software, die primär für Audio gedacht ist.

ciao herw

und der grund, warum sich hunde in den schwanz beisen, ist: weil sie es können????

natürlich kann reaktor audio sher gut,
aber wenn es A soundtechnisch keine grund und B irgendwie ne möglichkeit gibt, ne cpu-berechnung durchschnilltlich zu hundersrstelen, dann suche ich sie eben. ansonsten hab ich eigentlich nix gegen "audio".

[magneton]

Was hast Du nur gegen Audiosignale? Reaktor ist eine Software, die primär für Audio gedacht ist.

ich glaube, ich muss hier mal einhaken:
mit dem slew limiter habe ich auch brauchbare dinge realisiert, keine frage, aber auch ich suche nach lösungen auf eventebene. ganz einfach darum, weil ich sehr viele von diesen smoothern brauche und das in der summe einfach (für mein live-ensemble) zu viel CPU verbraucht.
zudem ist es auch nur nötig dass controller/eventsignale geglättet werden (wozu meist eine CR von 100 Hz völlig ausreicht).

[herw]

...ich glaube, ich muss hier mal einhaken:
mit dem slew limiter habe ich auch brauchbare dinge realisiert, keine frage, aber auch ich suche nach lösungen auf eventebene. ganz einfach darum, weil ich sehr viele von diesen smoothern brauche und das in der summe einfach (für mein live-ensemble) zu viel CPU verbraucht.
zudem ist es auch nur nötig dass controller/eventsignale geglättet werden (wozu meist eine CR von 100 Hz völlig ausreicht).

Könntest du dann nicht einen event-smoother bauen, der von einer 100Hz-clock gesteuert wird? Ich habe mal die Idee dazu im Bild dargestellt.

Der 100Hz-Clockgenerator ist irgendwo zentral deponiert und sendet mit Hilfe des Flip-Flops abwechselnd 0 und 1 (das IC-Send-Modul sendet nur wechselnde Werte). Dies Clocksignal wird über ein IC-Send allen IC-Receives angeboten (habe ich nur der Anschauung halber in eine Strutkur gepackt). So hast Du eine zweite CR. Die smoother müsstest du dann noch konstruieren zum Beispiel, in dem man den vorgegebenen Wert mit dem neuen Wert vergleicht und in entsprechenden Häppchen aufaddieren lässt.

ciao herw

[magneton]

ein ClockOsc mit 100 Hz? der verbraucht eine menge CPU (und wenn er an einer umfangreichen schaltung angeschlossen ist, noch viel mehr!).
wozu das flipflop? der ClockOsc schickt doch eh' 0 und 1 raus?
nebenbei:
klar, der ClockOsc schickt events raus, kein audio. dennoch verbraucht er CPU, ähnlich einem LFO (event), der an viele "verbraucher" angeschlossen wird. (einfach mal den "eventwatcher" dranhängen und CPU messen).

[herw]

ein ClockOsc mit 100 Hz? der verbraucht eine menge CPU (und wenn er an einer umfangreichen schaltung angeschlossen ist, noch viel mehr!).
wozu das flipflop? der ClockOsc schickt doch eh' 0 und 1 raus?
nebenbei:
...

ja den flipflop habe ich vor lauter core-Blindheit schon automatisch eingefügt, da ja in Core clocksignale keine Amplitude haben und ich nur mit Einsen gerechnet hatte.
Den CPU-Verbrauch teste ich mal; interessant war dieses Beispiel ja nur, weil meine Vor-Schreiber auf einen eventsmoother (event-Ein- und Ausgang) bestanden.

ciao herw

[helmsklamm]

ja den flipflop habe ich vor lauter core-Blindheit schon automatisch eingefügt, da ja in Core clocksignale keine Amplitude haben und ich nur mit Einsen gerechnet hatte.


ciao herw

sowas kommt von sowas

aber sagt mal: wie soll 100hz (= 100 abtastungen per sekunde, oder?) irgendwas smoothen? standardmässig dürfte CR mit 200 oder 400 bereits anliegen, also von sich aus schon doppelt/viermal "smoother" auflösen???
habt ihr ne 0 vergessen, oder überseh ich hier was gravierendes?

achja, und wenn ich den als direkten smoother neben möchte, müsste ich dann anstelle der 1 konstante einfach nur meinen knob dort einklinken?

[herw]

...aber sagt mal: wie soll 100hz (= 100 abtastungen per sekunde, oder?) irgendwas smoothen? standardmässig dürfte CR mit 200 oder 400 bereits anliegen, also von sich aus schon doppelt/viermal "smoother" auflösen???
habt ihr ne 0 vergessen, oder überseh ich hier was gravierendes?

bitte 10. Post lesen; dort wurde 100Hz gewünscht.