Events und Genauigkeit

Diskussionsforum für Fragen zur Struktur und Implementation in REAKTOR, auch DSP, Literatur und begleitende Software

Moderator: herw

Benutzeravatar
herw
moderator
Beiträge: 3123
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Events und Genauigkeit

Beitrag von herw »

fweth hat geschrieben:
herw hat geschrieben: ich habe mir dein Ensemble angesehen. Kannst Du erklären, welchen Zweck die Delay- und umgebenden Makros haben?
naja die macros sind nur puls oscs, die ich mir aus dem core cell 4-wave slv gebaut habe, weil ich audio puls oscs wollte, die ich nur mit frequenz ansteuern kann, und die keinen P eingang haben. und zuerst wollte ich eben nur die genauigkeit testen (siehe ensemble genauigkeitstest), ob, wenn man den langsameren osc einen sample and hold antriggern lässt, immer die selben zahlen ausgegeben werden, oder ob sich da in reaktor ungenauigkeiten im bereich einzelner samples ergeben. zuerst hatte ich an den switch einmal ein unit delay gehängt, und einmal nichts (um, solange es keine unschärfe gibt, genau das letzte sample aus der 0er flanke oder das erste sample aus der 1er flanke zu messen). als nun aber der ausgabe wert immer nur 0 war hab ich das ganze visualisiert, und ein längeres delay dazwischengeschaltet, und jetzt sollte meiner meinung nach, wenn man sich die darstellung in den audio tables ansieht, der numeric ganz bestimmt 1 anzeigen, was er aber immer noch nicht tut :/ irgendwas muss ich da an der funktion grundlegend missverstanden haben...
das single delay ist auf 10,6 ms eingestellt. Das entspricht etwa 467 Samples. D.h., wenn Du da etwas vergleichst ist alles schon Vergangenheit. Dann ist problematisch, dass Du einen numerischen Output zur Kontrolle nimmst, da dessen Anzeige sowieso nicht in "Echtzeit" aktualisiert wird; d.h. der zeigt ohnehin nur zufällig ausgewählte Werte an.
Ich denke, du solltest noch weiter vereinfachen und das Testensemble nur auf das nötigste reduzieren und nur einen ganz bestimmten Aspekt untersuchen. Wenn Du wirklich fundierte Ergebnisse sammeln willst, dann nützt es nicht, schon an die weitere Verarbeitung zu denken.
Dazu (sorry ist etwas Lehrer-haft aber nicht so gemeint) ist auch ein übersichtlicher Strukturaufbau nötig; für einen Außenstehenden ist es nämlich schwierig, die Struktur schnell nachvollziehen zu können. Das schreckt ab, abgesehen davon willst Du ja deine Struktur auch noch in vierzehn Tagen verstehen.
Also nochmal ganz von vorne: was (nur einen Aspekt!) willst du untersuchen ?
Benutzeravatar
herw
moderator
Beiträge: 3123
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Events und Genauigkeit

Beitrag von herw »

Ich gehe mal zuerst auf die Oszillatoren ein. Du hast zwar den Synchronisationseingang benutzt, doch nicht den unteren Eingang sncH beschaltet. Die Informatiopn im inneren Makro sagt aus, dass eine Hardsynchronisation nur für den Wert 1 stattfindet, für den Wert 0 nicht (andere Werte sind verschiedene Grade von Synchronisation, was immer das heißen mag; das ist leider nirgendwo erläutert und muss untersucht werden). Du möchtest aber eine Hardsynchronisation, also muss der unbeschaltete Eingang den konstanten Wert 1 bekommen. Im Moment wird gar nichts synchronisiert.
fweth
meister
Beiträge: 118
Registriert: 21. November 2007, 16:01
Wohnort: Österreich

Re: Events und Genauigkeit

Beitrag von fweth »

herw hat geschrieben:Ich denke, du solltest noch weiter vereinfachen und das Testensemble nur auf das nötigste reduzieren und nur einen ganz bestimmten Aspekt untersuchen. Wenn Du wirklich fundierte Ergebnisse sammeln willst, dann nützt es nicht, schon an die weitere Verarbeitung zu denken.
Dazu (sorry ist etwas Lehrer-haft aber nicht so gemeint) ist auch ein übersichtlicher Strukturaufbau nötig; für einen Außenstehenden ist es nämlich schwierig, die Struktur schnell nachvollziehen zu können. Das schreckt ab, abgesehen davon willst Du ja deine Struktur auch noch in vierzehn Tagen verstehen.
ja klar...das habe ich gerade kürzlich selber erfahren, wie ich neu gewonnene kentnisse in ein etwa ein monate altes ensemble integrieren wollte ;) hab halt die dinger ausgetauscht, die ich erneuern wollte, aber vom kontext habe ich nichts mehr mitgekriegt.
herw hat geschrieben:Also nochmal ganz von vorne: was (nur einen Aspekt!) willst du untersuchen ?
OK, also ich habe 2 oszillatoren, die regelmäßig von einem mutterosc gesynct werden, und in ganzzahligen frequenzverhältnissen laufen (skizze).
oscsketch.gif
jetzt sollten die beiden oscs auch an einigen stellen zwischen den syncimpulsen genau gleichzeitig von 0 auf 1 springen (triggerimpuls, rot umrandet). mit meinem ensemble wollte ich eben feststellen ob das ganze wirklich samplesynchron passiert, dazu lasse ich den langsamen osc bei jedem trigger (sprung von 0 auf 1) eine abfrage an den schnellen osc machen. ohne verzögerung sollte dann immer der wert 1 erscheinen (weil der schnelle osc auch in dem selben moment auf 1 springt, wenn der langsame die abfrage macht). wenn man an den schnellen osc ein unit delay hängt, sollte der langsame bei jeder abfrage immer noch gerade den wert 0 erwischen. wie genau hier reaktor arbeitet, wollte ich eben mit diesem ensemble testen, weil ich es für eine art generativen sequencer benötige. ich habe diese idee jetzt nochmal in ordentlicher form gepostet, aber es läuft überhaupt nicht so wie ich mir denke (der wert bleibt immer auf 0).
herw hat geschrieben:das single delay ist auf 10,6 ms eingestellt. Das entspricht etwa 467 Samples. D.h., wenn Du da etwas vergleichst ist alles schon Vergangenheit. Dann ist problematisch, dass Du einen numerischen Output zur Kontrolle nimmst, da dessen Anzeige sowieso nicht in "Echtzeit" aktualisiert wird; d.h. der zeigt ohnehin nur zufällig ausgewählte Werte an.
ja, dass ich das vorher mit der vergangenheit verglichen habe war absicht, weil so wirklich 100%ig 1 erscheinen sollte in dem numeric, wie man auch in dem audio table sehen kann (wo man auch den delayeffekt erkennt, und dass bei der steigenden flanke des langsamen osc der schnelle schon eine ganze weile, 467 samples wie du sagst, auf dem wert 1 steht) aber anscheinend habe ich da eben einen denkfehler gehabt...
herw hat geschrieben:Dann ist problematisch, dass Du einen numerischen Output zur Kontrolle nimmst, da dessen Anzeige sowieso nicht in "Echtzeit" aktualisiert wird; d.h. der zeigt ohnehin nur zufällig ausgewählte Werte an..
danke, das habe ich noch nicht gewusst. in meinem fall sollte es aber eigentlich nichts ausmachen, weil der osc nur jede sekunde den wert im sample+hold ändert (triggert), dann sollte der numeric genug zeit haben sich auf den neuen wert einzustellen.

bei den oscs habe ich jetzt auch den sncH eingang angesteuert.

Ich habe deinen Beitrag mal editiert. Du kannst die Bilder oder auch download-links von ensembles an passender Stelle anzeigen lasen, indem du den Cursor in den Text positionierst und dann bei den angehängten Dateien auf den Button "IM Beistrag anzeigen" klickst. (herw)
Genauigkeitstest_ordentlich.ens
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3123
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Events und Genauigkeit

Beitrag von herw »

Ich denke, das dein grundsätzlicher Ansatz, den gleichzeitigen Wechsel von beiden Oszillatoren von -1 auf +1 durch eine Gleichheit abzufragen, schon problematisch ist. Ein solcher Neustart eines Oszillators wird durch einen sample-genauen Vergleich des Wechsels von z.B. - nach + (positive slope) vollzogen:
In Core sieht ein solches Makro folgendermaßen aus:
- pos slope.gif
Es werden immer die aktuelle und die vorangegangene Phase auf ihr Vorzeichen abgefragt, sobald die aktuelle Phase positiv ist und die vorangegangene negativ war, gibt es eine 1 am Ausgang.
Der Slope wird am Ausgang des jeweiligen Ramposzillators abgefragt; bei einer Abfrage an den steilen Flanken einer Rechteck- oder auch Sägezahnwelle (also am Ausgang des eigentlichen Oszillators) bekommt man sicherlich Schwierigkeiten wegen des Antialaisings. Das angegebene Makro muss in diesem Fall in eine Audio-Core-Cell eingebaut werden. Wenn Du für beide Oszillatoren jeweils solche Makros anhängst und deren Ausgänge weiter logisch verarbeitest, müsste man genauere Auskunft erhalten (ich hab's aus Zeitgründen nicht selbst getestet).
Ich würde die beiden Oszillatoren auch direkt in eine AudioCoreCell packen.

Deine letzte angehängte Datei habe ich noch nicht geladen (muss jetzt auch noch ein wenig arbeiten).
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
fweth
meister
Beiträge: 118
Registriert: 21. November 2007, 16:01
Wohnort: Österreich

Re: Events und Genauigkeit

Beitrag von fweth »

gut danke!

ich bin jetzt aber auch auf einen fundamentaleren feler draufgekommen, der auch mitverursacht hat, dass meine letzten "genauigkeitstest" ensembles nie funktioniert haben. unter bestimmten umständen kann anscheinend ein delay einen triggerimpuls "verschlucken"...keine ahnung wie das sein kann.

ich hab das ganze jetzt mal genauer unter die lupe genommen, und wieder ein testensemble dafür gebaut. das ganze funktioniert so: verschiedene pulsoscs geben auf verschiedene arten triggerimpulse aus, mit einem switch kann man jeweils einen kanal an den triggereingang eines sample+hold weiterleiten. wenn der impuls richtig interpretiert wird, ändern sich die zahl in dem numeric laufend, weil der sample+hold von einem random osc gespeist wird. ohne delay werden alle kanäle richtig interpretiert. wenn man aber jetzt über den 2. switch ein unitdelay oder ein simpledelay (sogar mit der delaytime 0!) dazwischenschaltet, werden die triggerimpulse der kanäle D und E "verschluckt" (vielleicht ist das ein bug, der nur bei mir auftritt, probiert bitte mal ob das bei euch auch so ist). ich denke das ensemble ist sonst ganz verständlich, aber die herkunft dieser fehlfunktion (wie kann ein delay mit der delaytime 0 irgendwas an dem signal verändern!?!) kann ich mir einfach nicht erklären. (aus irgendeinem grund konnte ich das ensemble so nicht hochladen, es kam die fehlermeldung "dateianhang ens ist nicht erlaubt, jetzt hab ich es zippen müssen :/ )

vielen dank!
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
fweth
meister
Beiträge: 118
Registriert: 21. November 2007, 16:01
Wohnort: Österreich

Re: Events und Genauigkeit

Beitrag von fweth »

und da gibt es noch etwas mit delays, was ich nicht ganz verstehe. ich habe wieder so einen art zähler auf der primary ebene gebaut. aber komischerweise, wenn man ihn ganz schnell in ganz hohe bereiche zählen lässt, und dann wieder eine höhere verzögerung einstellt, dann spinnt er total und spuckt völlig zufällige werte aus, obwohl er ja einfach wieder langsam weiterzählen sollte. wie kommt das? (zum restarten in dem ensemble einfach den switch betätigen)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Antworten