wieso knackst event so greulich?

[helmsklamm]

aufgrund cpu-ersparniss hab ich mir vor einiger zeit mühselig fast alle "audio-controll" (also bspw. lev, pan, crosfade, sends....) teile zu event konvertiert. das spart zwar jede menge cpu aber, nach einigen testläufen, muss ich einsehen, das das so gut wie unbrauchbar ist. jeder kleinste reglerdreh verursacht extreme (zuimindest hörbarer) knackser, die leider eigentlich nie musikalisch sinn machen. - es is also kein "kreatives" stören sondern tatsächlich nur reiner, ungewollter noise. und selbst die sogenannten smoother vrelargern nur das problem: zwar elemenieren sie knackser, aber anstelle dessen hageln sie einem mit ner art "zirpen" oder "fiepen" kA - jedensfall ebenfalls extrem störend- zu.

das selstsame ist:baut man sien mixer/fades/wasauchimmer konsequent als "audio", also simple multiplies/adds anstelle der EXPLIZIT dafür "entworfenenen" module, ist das nicht der fall. jeder reglermove wird völlig knackfrei übermittelt. allerdings zu einem (mehereren) hundertfachen der cpu-last. (bei heurtigen rechnern maerkt man das bei 2,3 modulen nich - is der mixer, oder was immer komplex genug, kann es schonmal ne verdoppelung der last geben).

die grundsätzliche frage: wenn rektor in smaplerate mit anderen "samplerate-controlls" gibt es keine knackser, wenn es aber mit "controll-rate" das ja im prinzip auch nix anderes als ne samplerate (nur mit viel selteneren abtastungsintervallen ist) "controlliert" wird, kommt es zum knacksen.
eigentlich müsste ja das gegensätzliche der fall sein: samplerate mal/minus/durch/plus.... samplerate "fragt" sich haltr ständig, wo wir sind, und startet die neuberechnung erst bei "taktgleichheit" und klingt somit butterweich.
wenn nun die (im verhältniss zur samplerate) seltene "controll-rate" an nem extrem ungünstigen zeitipunkt das "sample" abfragt und zur neujustierung ZWINGT kann, resp. muss es meines dilletantischen wissens vollkommen folgerichtig zu "aussetzern", sprich: knacksern kommen.
(meine dilletantische frage:) da dergleichen bei abstatstung in audio.-rate ja nicht der fall ist, müsste das problem doch ganz simpelst behoben werden könne, wenn die eventrate nur zu einem "günstigeren" zeitpunkt abgeriffen würde.
bevor ich noch weiteren unsinn erzähle: kleine mathematische (und überstzte denkaufgabe) wenn die sampleabtastung 44001 beträgt, welchen sinn macht dann ne "controll" von 400????? welche zahlen kommen da raus, oder praktischer: wo iwrd dort konkret "abgeriffen"?


oder nochal ganz anders: wenn gewährleist wäre, das der startpunkt controll-rate identisch mit ner vilefachen der sample-rate wäre: würde es dann noch knackser geben können?
und falls ja, würde dergleichen nich die gesamte engine (notwenidigkeiten) von "unötigen" berechnungeungen entschlacken)

[herw]

aufgrund cpu-ersparniss hab ich mir vor einiger zeit mühselig fast alle "audio-controll" (also bspw. lev, pan, crosfade, sends....) teile zu event konvertiert. das spart zwar jede menge cpu aber, nach einigen testläufen, muss ich einsehen, das das so gut wie unbrauchbar ist. jeder kleinste reglerdreh verursacht extreme (zuimindest hörbarer) knackser, die leider eigentlich nie musikalisch sinn machen. - es is also kein "kreatives" stören sondern tatsächlich nur reiner, ungewollter noise. und selbst die sogenannten smoother vrelargern nur das problem: zwar elemenieren sie knackser, aber anstelle dessen hageln sie einem mit ner art "zirpen" oder "fiepen" kA - jedensfall ebenfalls extrem störend- zu.

das selstsame ist:baut man sien mixer/fades/wasauchimmer konsequent als "audio", also simple multiplies/adds anstelle der EXPLIZIT dafür "entworfenenen" module, ist das nicht der fall. jeder reglermove wird völlig knackfrei übermittelt. allerdings zu einem (mehereren) hundertfachen der cpu-last. (bei heurtigen rechnern maerkt man das bei 2,3 modulen nich - is der mixer, oder was immer komplex genug, kann es schonmal ne verdoppelung der last geben).

die grundsätzliche frage: wenn rektor in smaplerate mit anderen "samplerate-controlls" gibt es keine knackser, wenn es aber mit "controll-rate" das ja im prinzip auch nix anderes als ne samplerate (nur mit viel selteneren abtastungsintervallen ist) "controlliert" wird, kommt es zum knacksen.
eigentlich müsste ja das gegensätzliche der fall sein: samplerate mal/minus/durch/plus.... samplerate "fragt" sich haltr ständig, wo wir sind, und startet die neuberechnung erst bei "taktgleichheit" und klingt somit butterweich.
wenn nun die (im verhältniss zur samplerate) seltene "controll-rate" an nem extrem ungünstigen zeitipunkt das "sample" abfragt und zur neujustierung ZWINGT kann, resp. muss es meines dilletantischen wissens vollkommen folgerichtig zu "aussetzern", sprich: knacksern kommen.
(meine dilletantische frage:) da dergleichen bei abstatstung in audio.-rate ja nicht der fall ist, müsste das problem doch ganz simpelst behoben werden könne, wenn die eventrate nur zu einem "günstigeren" zeitpunkt abgeriffen würde.
bevor ich noch weiteren unsinn erzähle: kleine mathematische (und überstzte denkaufgabe) wenn die sampleabtastung 44001 beträgt, welchen sinn macht dann ne "controll" von 400????? welche zahlen kommen da raus, oder praktischer: wo iwrd dort konkret "abgeriffen"?


oder nochal ganz anders: wenn gewährleist wäre, das der startpunkt controll-rate identisch mit ner vilefachen der sample-rate wäre: würde es dann noch knackser geben können?
und falls ja, würde dergleichen nich die gesamte engine (notwenidigkeiten) von "unötigen" berechnungeungen entschlacken)

Du solltest vielleicht mal mit dem AudioCore-Eventausgang von Gerald List (krümelmonster, cookiemonster) experimentieren; das ist ein Eventausgang, der mit der SampleRateClock synchronisiert ist und nur dann Events herausgibt, wennn sie auch wirklich da sind.

ciao herw

[helmsklamm]

ich hab mir grad das corecell-eventrate teil gedownt, das meintest du, oder?

wenn ich aber den beschreibungs-txt richtig verstanden habe, soll das ja core auf den abtatststand von primary "runterrechnen", nich wahr??

auf primary erschlisst sich mir grad der sinn nicht ganz, denn controlls senden doch sowieso nur bei bewegung - und das ist ja auch erwünscht.

der kurze snn der lange rede: ich teste es erstmal

EDIT: ich habe deinen txt grad nochmal gelesen: AHA! jup, klingt knüllig, auf zum test.

[helmsklamm]

ich habs grad "getested" und musste feststellen das ich wohl zu blöde bin.
also mit Hz-knob wähl ich wohl ne art "controll-rate" aber wo soll überhaupt mein eigentliches controll-signal rein?? und wie verdrahten?


ich hab grad nochmal nen anderen weg versucht, und zwar die contrroll-rate manual der SR anzupassen - das geht garnicht ich kann nur aus groben stepweiten wählen, aber nicht bspw. teilfaktor 10 = 441 festlegen. bei SR durch 400 erhalte ich leider 110,25 was ja wohl bedeutet, das sich contzrollrate und SR ständig in qeuere kommen und somit logeischerweise zu knacksen führen. also vielleicht denk ich ja komplett falsch, aber wäre das "event-knacksen" nicht komplett aus der welt, wenn SR und controllrate "syncronisiert" wären, also bei teilung immmer ne integer rauskommt?

[herw]

Die Ursache von Adioknacksern kann sehr vielfältig sein. Ich hatte selbst beim Modular lange damit zu kämpfen (Umschalten der snaps).
Die Hauptursache ist allgemein ein "unsteter" also sprunghafter Übergang von Audiodaten (bei sampleloops würde man dies zum Beispiel hören, wenn Ende und Anfang eines Sampleloops nicht auf derselben Höhe sind. Bei Mixern hört man es, wenn ein "Gleichspannungsanteil" zusätzlich hinzukommt.
Ich vermute (keiner Expertenmeinung) mal, dass es beim Abtasten eines Audio-Signals zu einem Event-Signal dadurch zu Sprüngen kommt, da ja in dem Zeitraum eines Control-Rate-Zeitraums schon etliche Audio-Signale vergangen sind und es dadurch zwangläufig zu unerwünschten Sprüngen kommt.
Der Event-Ausgang von Gerald (ich hoffe Du hast das richtige Macro heruntergeladen) ist ein Audio-Modul, das events mit Audiorate-Auflösung verarbeitet und ausgibt und zwar nicht in einem Audio-Stream wie normalerweise alle AudioCore-Zellen, sondern nur bei ihrem wirklichen Auftreten.
Beispiel: Ich füttere eine AudioCore-Zelle mit den Event-Daten eines Reglers. Dann gibt diese AudioCore-Zelle brav mit SampleRate also 44100 mal pro Sekunde den aktuellen Wert aus. Beim Regeln also viel zu oft unnötigerweise. Schalte ich ein AtoE Modul dahinter, dann wird dieser Event 200mal, 400mal pro Sekunde je nach Kontrollrate ausgegeben, auch unnötigerweise.
Der AudioCore-Eventausgang nun unterbindet dies ganz raffiniert. Es ist nach außen hin nach wie vor ein Audioausgang, gibt aber diesen Event (als einzelnen Event zum jeweiligen Zeitpunkt (mit der Auflösung der Samplerate) nach außen ab und sonst nichts. D.h. es gibt keine Belastung nach außen zum primary level oder auch intern in den weiteren CoreCell-Strukturen. Ein AtoE-Modul oder ein dupl-Modul im Innern liefert keine Lösung, da nach wie vor entsprechend abgetastet würde.
Das ist von Gerald genial gelöst und es ist schade, dass NI das noch nicht durch ein Mini-Update mit eingebaut hat.

ciao herw

[KlangRaum]

jeder kleinste reglerdreh verursacht extreme (zuimindest hörbarer) knackser

ich kann da jezz nichso ganz nachvollziehen, wo bei einer eventrate von 200/400hz und smoother hinterallem, was hörbare sprünge prodzieren könnte, knackser kommen. welche zeibasis nimmste dafür?

vielleicht bau ich meine schaltungen intuitiv *anders*... aber das pob hatte ich eigentlich so noch nicht.

machma den erklärbär...

[herw]

jeder kleinste reglerdreh verursacht extreme (zuimindest hörbarer) knackser

ich kann da jezz nichso ganz nachvollziehen, wo bei einer eventrate von 200/400hz und smoother hinterallem, was hörbare sprünge prodzieren könnte, knackser kommen. welche zeibasis nimmste dafür?

vielleicht bau ich meine schaltungen intuitiv *anders*... aber das pob hatte ich eigentlich so noch nicht.

machma den erklärbär...

Oh da kann ich dir einige kräftige Knackser um die Ohren hauen, dass dir Angst und Bange um deine PA wird. Kleines Beispiel: nimm mal einen einfachen My-first-synth mit mehreren Waveforms und speise damit das tube-macro. Baue dann einige switches hinter den osc und auch welche, um den tube zu umgehen, damit du zwischen den Wellenformen umschalten kannst und speichere mal entsprechend mehrere snaps ab. Dahinter schalteset am besten noch ein delay. Es kann ordentlich knallen, wenn du den Tubolator mal eingespannt hast und mal außen vor lässt. Vorsicht mit der Laustärke!
Wenn Du das nicht schaffen solltest, kann ich dir mal ein Negativbeispiel schicken. Die erste Version von MM1 knallte auch noch bei einigen snaps kräftig.

ciao herw

[helmsklamm]

also bei mir macht sich das hauptsächlich mit tieffreqeunten signalen bemerkbar: ne vol-pan-send- modulation is ohne <100ms smother undenkbar, und selsbt mit sind bei manchen "hartnäckigen" signalen immer noch krischel-knackser zu vernehmen, ganz abgesehen vom schwammigen timing, das das nach sich zieht. oder selbst beim filtermodulieren: ich muss immer die F-varainte wählen, weil der event-cutoff bei tiefen eingangssignalen und lowpass keine knackfreie filterfahrt hinkriegt. die F-variante macht das butterweich.

[helmsklamm]

also ich hab das grad nochmal mit controllrate 100 probiert, dann ist es "hinten" zumindest integer, aber das is wohl doch nicht der grund.
aber warum knackst das sonst? bei audio brauch ich (wenn überhaupt) nen smoother mit 3ms und die artefakte sind VOLLSTÄNDIG verschwunden.
ich begreif das nicht.

[KlangRaum]

das ein switch zwischen 2 audiosignalen knackst ... ist logisch.
hat eigentlich auch damit nix tu tun...

audiosignale lassen sich nur im nulldurchgang knackfrei schalten, was in der praxis (ohne weiter maßnahmen fast) unmöglich sein sollte

oder selbst beim filtermodulieren: ich muss immer die F-varainte wählen, weil der event-cutoff bei tiefen eingangssignalen und lowpass keine knackfreie filterfahrt hinkriegt. die F-variante macht das butterweich.

das ist eigentlich auch logisch: den event verwende ich eigentlich nur zur grund/offset-einstellung (via smoother 10-20ms) .... ich moduliere nicht damit.

ein modulierendes eventsignal in einem audiozweig packt dir fast immer die controllrate als intermodulations-geschwurbel mit drauf ....

modulationen von audiosignalen mache ich generell nur mit audiosignalen.
wenn ichs mal genau überlege: meine schaltungen brauchen durchweg *einiges* an cpu... vermutlich weil ich bisher ohne weiteres nachdenken einen gewissen weg gegangen bin. und deswegen sind mir solche effekt noch nie aufgefallen.......

[helmsklamm]

ein modulierendes eventsignal in einem audiozweig packt dir fast immer die controllrate als intermodulations-geschwurbel mit drauf ....

kannst du das bitte näher erläutern?

modulationen von audiosignalen mache ich generell nur mit audiosignalen.
wenn ichs mal genau überlege: meine schaltungen brauchen durchweg *einiges* an cpu.

das is wohl so : bei manchen signalen (speziell bass) darf man wohl nicht zu cpu-geizig sein. [/quote]

[KlangRaum]

ein modulierendes eventsignal in einem audiozweig packt dir fast immer die controllrate als intermodulations-geschwurbel mit drauf ....

kannst du das bitte näher erläutern?

äääähm *schnauf*.... :roll: ...ich bräuchte da ne kreidetafel
modulationen mit der samplingrate wirken stetig und sind nicht mehr hörbar. im gegensatz zu modulationen mit der eventrate (hier kann man im prinzip auch mal einiges aus dem abtasttheorem anwenden)

gegenüber dem audiosignal wirkt ein eventsignal nicht stetig....

...blahfasel.....theorie.... wech damit....

wenn ein event-lfo mit 10hz einen audiooszillator moduliert, dann ist dieses 10hz-signal quasi mit 400hz digitalisiert. gegenüber einem 10hz audio-lfo hat das ausgangssignal einen fehlanteil im nutzsignal - sprich weitere oberwellen die ein störgeräusch erzeugen können.....

der event-lfo enthält quasi immer ein 400hz-signal...

[helmsklamm]

ok, im ansatz (glaub ich) verstanden, aber wenn beim lfo-bsp. das 10hz teil mit SR moduliert wird (also 44100 bspw.), dann müsste dadurch noch ein viel größerer fehler im nutzsignal entstehen - oder meinst du, weil dieses teil dann mit 44100 digitalisiert ist (also exakt wie das zu-modulierende-signal) gleicht sich das aus?? also ne art positiver "phassenauslöschung"??? oder noch anders: wenn die controll-rate 44087 wäre, wäre dann das störgeräusch noch viel höher oder eher niedriger und warum?

sorry für deine bemühungen aber ich find das thema ziemlich spannend.

[tymes2]

Herw's Workshop 3 (-> Punkt 2). Das LFO Signal wird nicht mit der Sampling-Rate moduliert sondern von der Kontroll-Rate quasi gesampelt ("digitalisiert" hat Klangraum das treffend genannt). In der Nähe der Nyquist-Frequenz (halbe Abtast-Rate, hier = Kontroll-Rate) treten verstärkt Artefakte auf, aber auch darunter ist man selten sorgenfrei. Ich habe gute Erfahrungen mit einem LPF hinter dem LFO gemacht, der hat Gezwitscher wegbekommen das ein Smoother nicht weggekriegt hat.

[helmsklamm]

yup, selbstredend kriegt man idR alle mod-siagnlae mithilfe eines 1pol LP oderwasimmer, ABSOLUT sorgenfrei.
aber, das war nich die frage: der LP is ja n zusätzliches "audio" modul, das seines zeichens auch ertsmal berechnet werden will. defacto handel ich mir dort also noch ein signal das auf verarbeitung schreit MEHR ein, anstelle weniger = noch me cpu - oder is es tatsächlich so, das das 1pol-LP weniger saft verbrät als ne direkte audio-multiplikation? ich kanns mir net vorstelle, abbe wer weischh dät scho-en...