Events und Genauigkeit

[fweth]

ich habe erst mal ein genauigkeitsproblem: ich habe in zwei getrennten ensembles einen ramp osc drinnen, die auf einer frequenz von etwa 0.2 oder so laufen, und wenn ich die beiden einmal synce, bildet sich trotzdem nach einigen durchläufen eine sichtbare differenz zwischen den beiden schwingungen. ich möchte die dinger nicht nach jedem durchlauf automatisch synchronisieren, weil ich auch die frequenz von einem vervielfachen können möchte, und trotzdem wissen dass die beiden exakt funktionieren (also an einem bestimmten punkt, wieder zusammenstoßen, falls die frequenzen ganzzahlige verhältnisse sind).

eine möglichkeit wäre das bestimmen des kleinsten gemeinsamen vielfachen (kgV) oder des größten gemeinsamen nenners (ggN), aber geht das mathematisch überhaupt, bzw. in reaktor?

ein anderes problem ist noch folgendes: ich möchte einen drumsequencer bauen, der nur samples antriggert, wo praktisch die länge des gates irrelevant, aber aus praktischen gründen am besten genau ein event lang ist. jedoch habe ich keinen event-impulse-osc oder sowas ähnliches gefunden, aber man kann bestimmt die impulse core cell ganz leicht von audio auf event umpolen..weiß nur nicht wie...

und ist die event rate das selbe wie die control rate, die man sich in den ensembleproperties aussuchen kann?

was ist überhaupt der vorteil von events, ich meine außer man möchte MIDI ausgeben oder prozessorleistung sparen, aber ist sonst nicht alles in audio viel genauer?

danke

[herw]

ich habe erst mal ein genauigkeitsproblem: ich habe in zwei getrennten ensembles einen ramp osc drinnen, die auf einer frequenz von etwa 0.2 oder so laufen, und wenn ich die beiden einmal synce, bildet sich trotzdem nach einigen durchläufen eine sichtbare differenz zwischen den beiden schwingungen. ich möchte die dinger nicht nach jedem durchlauf automatisch synchronisieren, weil ich auch die frequenz von einem vervielfachen können möchte, und trotzdem wissen dass die beiden exakt funktionieren (also an einem bestimmten punkt, wieder zusammenstoßen, falls die frequenzen ganzzahlige verhältnisse sind).

eine Möglichkeit wäre das Bestimmen des kleinsten gemeinsamen vielfachen (kgV) oder des größten gemeinsamen nenners (ggN), aber geht das mathematisch überhaupt, bzw. in reaktor?

Das kgV zu bestimmen, dürfte nicht in REAKTOR zu realisieren sein, da ja dann das Bilden der Primfaktorzerlegung implementiert werden müsste, es sei denn, Du gingest von den Primnfaktorzerlegungen aus, dann gibt es eine "Formel", ansonsten musst Du Dich mit dem Produkt der beiden Faktoren als Vielfachen begnügen. Um dann wieder auf die Teilfrequenzen zu kommen, brauchst Du nur wieder durch die anderen Faktor zu dividieren. In der Anwendung hieße das, dass Du eine virtuelle Mutterfrequenz erzeugst und dann auf die passenden Teilerfrequenzen herunter dividierst. Das Prinzip wird im Subharmonischen Oszillator angewendet (aus der REAKTOR Library).

ein anderes problem ist noch folgendes: ich möchte einen drumsequencer bauen, der nur samples antriggert, wo praktisch die länge des gates irrelevant, aber aus praktischen gründen am besten genau ein event lang ist. jedoch habe ich keinen event-impulse-osc oder sowas ähnliches gefunden, aber man kann bestimmt die impulse core cell ganz leicht von audio auf event umpolen..weiß nur nicht wie...

Das geht nicht ohne weiteres, da Oszillatoren grundsätzlich nur in AudioCoreCells erzeugt werden können. Sie haben als (notwendigen) Taktgeber die SampleRateClock SR.C. . In EventCoreCells kann man diese Taktquelle nicht benutzen. Sie kann nur von außerhalb zugeführt werden.

und ist die event rate das selbe wie die control rate, die man sich in den ensembleproperties aussuchen kann?

ja

was ist überhaupt der vorteil von events, ich meine außer man möchte MIDI ausgeben oder prozessorleistung sparen, aber ist sonst nicht alles in audio viel genauer?

Der Audiodaten-Stream ist immer an die Taktfrequenz der SampleRate SR.R. gebunden. D.h., dass alle Ausgänge einer AudioCoreCell Daten mit z.B. 44100 Hz Frequenz aussenden. Das kostet viel Prozessorlast. Bei Audio-Daten ist dies nicht zu vermeiden, es sei denn man nimmt einen Datenverlust und damit Klangqualität in Kauf.
Viele Daten, wie zum Beispiel Controller-Daten (Verstellen eines Reglers auch Hüllkurven oder LFOs) haben aber eine so langsame Werteveränderung oder geben auch nur einen Wert aus, so dass sich eine Ausgabe über einen Audioausgang als unnötig Prozessor belastend erweist. Dafür benutzt man Events. Dieses sind Ereignisse, die unabhängig von der SampleRateClock direkt verarbeitet werden können. Deren Verarbeitung geschieht in den EventCoreCells. An den Event-Ausgängen werden diese Werte wieder übergeben, jedoch maximal mit einer Abtastgenauigkeit der ControlRate, in der Regel 400 Hz oder 200 Hz. Da diese kleinen Zeitverschiebungen in der Regel nicht groß auffallen, kann man sehr viel CPU-Last sparen.
Leider haben die AudioCoreCells keine Eventausgänge, obwohl in Core es im Prinzip keine Unterschiede zwischen beiden Datenarten gibt. Bei LFOs mit einer so langsamen Frequenz, wie Du sie im oben erwähnten Beispiel verwendest, kannst Du gut die LFOs mit Eventausgängen benutzen. Die treppenartigen Schwingungen sind dann schon noch sehr genau. LFOs sind erst im Bereich ab 5Hz nicht mehr gut zu gebrauchen und dann sollte man auf AudioLFOs überwechseln.

danke

[fweth]

Viele Daten, wie zum Beispiel Controller-Daten (Verstellen eines Reglers auch Hüllkurven oder LFOs) haben aber eine so langsame Werteveränderung oder geben auch nur einen Wert aus, so dass sich eine Ausgabe über einen Audioausgang als unnötig Prozessor belastend erweist. Dafür benutzt man Events. Dieses sind Ereignisse, die unabhängig von der SampleRateClock direkt verarbeitet werden können. Deren Verarbeitung geschieht in den EventCoreCells. An den Event-Ausgängen werden diese Werte wieder übergeben, jedoch maximal mit einer Abtastgenauigkeit der ControlRate, in der Regel 400 Hz oder 200 Hz. Da diese kleinen Zeitverschiebungen in der Regel nicht groß auffallen, kann man sehr viel CPU-Last sparen.

OK, vielen dank für die rasche, umfangreiche info!

heißt das also dass man sogar MIDI signale (wie zB. gate) reaktorintern theoretisch durch audiosignale ersetzen kann, die zwar nicht über die MIDI verbindungen gesendet werden können, aber einfach durch normale direkte verbindungen? ist praktisch das eventsignal nur zu ökonimischen zwecken vorhanden, aber man könnte sogar völlig auf events verzichten, ganz theoretisch (natürlich mach es keinen sinn, ich will nur das prinzip verstehen)?

und in meinem ensemble, von dem ich berichtetete, habe ich sogar einen audio osc verwendet, trotzdem haben sich leichte ungenauigkeiten ergeben, und mich wundert das bloß von wo die in einem mathematischen programm herkommen. aber das wäre noch weniger ein problem, da kann ich natürlich so einen steuer osc machen, der die dann alle regelmäßig synct...was mich jedoch noch viel mehr wurmt ist folgendes: ich habe ein ensemble gebaut, in dem es faktisch einen master, und einen slave sequencer gibt. der slave kann nur ausgeben, wenn der master gerade 1 ausgibt (das selbe prinzip für jede voice). wenn jetzt der slave auf vierfacher geschwindigkeit läuft, müsste sich das muster trotzdem nach jedem durchgang des masters wiederholen. in der tat ergeben sich jedoch schon bei fast jedem durchgang leichte veränderungen/verschiebungen, von denen ich nicht glaube dass sie bloß aus den minimalen ungenauigkeiten des ramp oscs kommen. ich habe das ensemble gepostet, aber bitte versucht nicht das ganze zu nachzuvollziehen (es ist wirklich sehr komisch und irrational ; ) aber das grundprinzip ist ein generiertes muster, dessen geschwindigkeit sich mit dem speed regler regulieren lässt, ich denke dass der selbe fehler auch in einer stark vereinfachten version dieses ensembles auftreten würde). drückt einfach mal auf sync (links oben), und beobachtet sie sequencing muster im slave (oder nur eines). sie verändern sich wie gesagt immer ein wenig, wenn ihr jedoch den speedregler des slave auf 1 stellt, und erneut auf sync drückt, erkennt man dass die muster eigentlich ident sind (komischerweise verschiebt sich das muster dann bei dem 1. durchgang ein wenig, aber dann bleibt es konstant), sollte das nicht bei vierfacher oder mehrfacher geschwindigkeit des slaves auch so sein? die ungenauigkeit in den ramp osc, die die tables ansteuern, macht sich erst nach etwa 1 minute oder so bemerkbar, also glaube ich nicht dass dies der grund für die fehler in jedem durchgang ist. und wenn ich die control rate auf 2000 stelle wird das ganze auch nicht genauer, also habe ich das auch vorerstmal als fehlerquelle ausgeschlossen. oder meint ihr es wäre doch besser statt den clock oscs, die ja event ausgeben, audio oscs zu verwenden?

also falls euch spontan was dazu einfällt, wäre ich euch sehr dankbar!

[herw]

[...]
heißt das also dass man sogar MIDI signale (wie zB. gate) reaktorintern theoretisch durch audiosignale ersetzen kann, die zwar nicht über die MIDI verbindungen gesendet werden können, aber einfach durch normale direkte verbindungen? ist praktisch das eventsignal nur zu ökonimischen zwecken vorhanden, aber man könnte sogar völlig auf events verzichten, ganz theoretisch (natürlich mach es keinen sinn, ich will nur das prinzip verstehen)?
[...]

Die Events werden auf primary- und core-Ebene unterschiedlich interpretiert. Chris List ((CList vgl. englischsprachiges Forum) hat das einmal sehr treffend beschrieben: Events auf primary level sind wie Blasen, die eine Röhre entlanglaufen, und werden, wie sie kommen, ausgewertet. Sie unterliegen keinem Takt. Dies ist manchmal wünschenswert. Sie können dadurch noch schneller verarbeitet werden als Audiosignale. Es ist zum Beispiel möglich, innerhalb eines Samples (Audio-Taktintervall also zum Beispiel innerhalb 1/44100 Sekunde) mehrere hundert (!) Events (zum Beispiel mit Hilfe eines Iterators) über eine Leitung zu schicken. Der Nachteil ist der, dass sie innerhalb einer AudioCoreCell wiederum sich dem Audiostream anpassen müssen (spätestens beim Ausgang), also wieder mit Hilfe eines Latch-Moduls mit der AudioRate getaktet werden müssen. Wenn sie nicht in einen Audiostream eingebaut werden müssen, dann kann man sie zum Beispiel dazu verwenden, Delay-Speicher während eines Samples(!) umzuprogrammieren (auf Null setzen). Man möge mich korrigieren, wenn es nicht möglich ist. Ich arbeite selbst gerade erst mit dieser Idee. Leider handhaben Primary- und Core-Ebene Audio-Daten und Event-Daten unterschiedlich. In Core gibt es keine Unterschiede; diese treten nur an den Schnittstellen zum Primary Level auf.
Leider ist REAKTOR 5 in dieser Hinsicht ein Kompromiss.
Auf Primary-Ebene gibt es nicht den Begriff der Gleichzeitigkeit. Gelangen zum Beispiel auf ein Additionsmodul zwei Events gleichzeitig, so werden sie sequentiell (hintereinander) bearbeitet: ein sehr einfaches Beispiel:

primary events 1.gif

Der obere Button (Toggle-Betrieb) gibt entweder eine 1 oder eine 0 aus, der untere setzt zurück durch 0 und auf Durchgang durch die 1 (Toggle-Betriebsart).
Die Schaltung ist äußerst einfach: Nachdem der Reset-Schalter wieder auf 1 gesetzt wurde, drücke ich den Summanden-Button. Er gibt nur einen Event aus (die 1). Das Additionsmodul verarbeitet aber zunächst einen der Eingänge (welchen zuerst, hängt davon ab, welche Verbindung ursprünglich zuerst gezogen wurde (häufige „Fehlerquelle”)), daher gibt das Additionsmodul zunächst 1 aus; danach wird der zweite Eingang bearbeitet und der Wert aufaddiert. Das kann problematisch sein, wenn man vom Ergebnis abhängige Entscheidungen automatisch treffen möchte (Router, weitere Events etc.).

primary events 2.gif

Das entspricht nicht der natürlichen (mathematischen) Denkweise. Mit Core wurde dieser Missstand abgeschafft. Dort gibt das Additionsmodul tatsächlich nur einen Event aus, nämlich die Summe 2 (ausprobieren!).
Man erkennt daran, dass eine Gleichbehandlung wünschenswert ist. Core entspricht dem normalen Denken (Gleichzeitigkeit). Leider trauen sich nicht sehr viele daran, obwohl es in diesem Bereich so leicht ist.

ciao herw

[KlangRaum]

ein anderes problem ist noch folgendes: ich möchte einen drumsequencer bauen, der nur samples antriggert, wo praktisch die länge des gates irrelevant, aber aus praktischen gründen am besten genau ein event lang ist. jedoch habe ich keinen event-impulse-osc oder sowas ähnliches gefunden, aber man kann bestimmt die impulse core cell ganz leicht von audio auf event umpolen..weiß nur nicht wie...

was ist der unterschied zwischen einem trigger und einem gate ?
ein trigger ist ein impuls ohne zeitliche länge - er "startet" je nach definition mit einer steigenden flanke (von 0 nach 1) oder fallenden flanke (von 1 nach 0) und hat eigentlich kin ende.
ein einzelner event entspricht einem trigger, der zb das auslesen eines SAMPLER starten kann.... nur starten, weiter nix, der sampler läuft dann durch bis an das sample-ende oder wird beim nächten trigger restartet.... und das beste: dieser event ist genau einen event lang

ein gate hat einen definierten start- & ende-zeitpunkt - bei einem gate ist ausschlaggebend, wann und wie lange das signal auf 1 steht.
ein 1'er event und ein darauf folgender 0'er event entspricht dann einem gate - damit kann das signal zb per envelope zeitlich begrenzt werden.
(folglich besteht ein gate aus 2 trigger - einem start und einem ende)

eine analogie dazu: eine ampel entspricht einem gate: solange es grün ist, darf man dran vorbei.
ein startschuss bei einem autorennen entspricht einem trigger..... den sonderfall eines vorzeitigen start oder verspätungen durch abgewürgten motor lassen wir mal beiseite - da kümmern sich andere filterdingse drum



im anhang:
diese art sampler benutze ich für allerwelts-drummereien.... schau dir das mal an, ob du es gebrauchen kannst.
das sampler-modul braucht zum start eigentlich nur einen entsprechenden trigger-event. was du wie mit der hüllkuve machen willst, musst du dann selbst entscheiden... da benötigst du dann uU. wieder ein gate.

[KlangRaum]

....
Auf Primary-Ebene gibt es nicht den Begriff der Gleichzeitigkeit. Gelangen zum Beispiel auf ein Additionsmodul zwei Events gleichzeitig, so werden sie sequentiell (hintereinander) bearbeitet...

das sind dann die sogenannten event-bomben, die dann manchmal entstehen können...

es gibt sehr viele fälle, in denen eine ganze reihe von events mit gleichem wert auftreten - und letztendlich dafür sorgen, das jedes mal das gleiche getan wird. bestes beispiel ist aus einem SongPostion/96 mittels modulo einen zähler aufzubauen, der eine tabelle für einen sequencer ausliest. im endeffekt kostet das nicht nur haufenweise cpu-zeit, reaktor kann je nach rechnerleistung bei grossen schaltungen träge werden..... oder sich auch stoppen. hier liegt die essenz des StepFilter btw Separator. ein stepfilter hinter jedem modulo verhindert nicht nur das wiederholte auslesen der tabelle.(*)

viele schaltungen erledigen reine steuerungsaufgaben als audiosignal. die erste optimierungsidee ist dann die umstellung auf events, wobei oft ein fehler begangen wird: das man nicht sofort merkt, wenn gleiche events mehrfach auftreten können. das sowas cpu kostet, ist eine sache. je nach interpretation der events als trigger oder gate kann das dazu führen, das eine schaltung vom ansatz her nicht richtig funktioniert oder das sich fehler einschleichen, die nur unter bestimmten bedingungen auftreten und man sich danach einen wolf sucht....
(*) im falle einer tabelle in einem sequencer kann dadurch zB eine einzelne 1/16note in 6 einzelne fragmente aufgeteilt werden und man fragt sich, wo die klickgeräusche herkommen.....

[fweth]

hmm danke vielmals, auch wenn ich jetzt noch nicht alles verstanden habe, aber das wichtigste bestimmt

zu trigger und gate wollte ich noch wissen: gibt es eine möglichkeit, dass bei jeder steigung des wertes ein trigger ausgelöst wird? also wenn ich zB. zwei puls oscs addiere, dann kommen manchmal auch sprünge von 1 auf 2 vor, aber die sollten auch einen trigger auslösen...wie wäre das möglich?

und außerdem: so mathematische operatoren, zB. vergleichsoperatoren, haben die immer ein unit delay eingebaut? sonst wären ja bestimmte schaltungen loops (zB. der ausgegebene wert wird laufend verglichen mit einem anderen, und das ergebniss des vergleichs bestimmt den neuen wert).

noch etwas anderes: angenommen ich habe zwei osc, wobei der zweite genau auf dreifacher geschwindigkeit käuft. nun triggert jeder ein sample+hold ding an, der wie oben beschrieben die ausgegebenen werte vergleicht, und neue werte errechnet. ist vielleicht jetzt umständlich ausgedrückt, aber mein eigentliches problem ist daraufhin folgendes: wenn ein osc mit 3 Hz läuft, und der andere mit 6 Hz, die beiden werden von einem "mutterosc" mit 1Hz immer gesynct, kann ich dann trotzdem davon ausgehen das jeder schlag des langsameren EXAKT mit jedem zweiten schlag des schnelleren übereinstimmt? wenn der auch nur ein sample verspätet wäre, wären ja die vergleiche nicht mehr korrekt, weil dann vielleicht von einem osc schon der "neue" wert mit dem "alten" des anderen verglichen wird, wenn sich einer nur um eine 44100stel sek. verpätet (sind beides audio oscs).

und hat sich vielleicht wer mal kurz mein oben gepostetes ensemble angeschaut? ich bin draufgekommen, dass die ungenauigkeiten nichts mit dem master/slave ding zu tun hatten, sondern allgemein bei höheren frequenzen auftreten. liegt das vielleicht doch an der ungenauigkeit der eventausgebenden clock oscs?

vielen dank

[herw]

hmm danke vielmals, auch wenn ich jetzt noch nicht alles verstanden habe, aber das wichtigste bestimmt

zu trigger und gate wollte ich noch wissen: gibt es eine möglichkeit, dass bei jeder steigung des wertes ein trigger ausgelöst wird? also wenn ich zB. zwei puls oscs addiere, dann kommen manchmal auch sprünge von 1 auf 2 vor, aber die sollten auch einen trigger auslösen...wie wäre das möglich?

In core reicht ein z^-1 Modul, mit dem man den vorangegangenen Wert durch Differenzbildung vergleicht.

und außerdem: so mathematische operatoren, zB. vergleichsoperatoren, haben die immer ein unit delay eingebaut? sonst wären ja bestimmte schaltungen loops (zB. der ausgegebene wert wird laufend verglichen mit einem anderen, und das ergebniss des vergleichs bestimmt den neuen wert).

Das unit delay wird von REAKTOR beim Compilieren automatisch gesetzt und zwar irgendwo innerhalb des Loops. Das ist erkennbar durch mehrere vertikale Striche an einem der Eingänge des loops (oft schnell zu übersehen). REAKTOR "baut" dann von sich aus ein unit delay ein. Besser ist es, in primary selbst das unit delay einzubauen bzw. in core das z^-1-Modul zu verwenden.

noch etwas anderes: angenommen ich habe zwei osc, wobei der zweite genau auf dreifacher geschwindigkeit käuft. nun triggert jeder ein sample+hold ding an, der wie oben beschrieben die ausgegebenen werte vergleicht, und neue werte errechnet. ist vielleicht jetzt umständlich ausgedrückt, aber mein eigentliches problem ist daraufhin folgendes: wenn ein osc mit 3 Hz läuft, und der andere mit 6 Hz, die beiden werden von einem "mutterosc" mit 1Hz immer gesynct, kann ich dann trotzdem davon ausgehen das jeder schlag des langsameren EXAKT mit jedem zweiten schlag des schnelleren übereinstimmt? wenn der auch nur ein sample verspätet wäre, wären ja die vergleiche nicht mehr korrekt, weil dann vielleicht von einem osc schon der "neue" wert mit dem "alten" des anderen verglichen wird, wenn sich einer nur um eine 44100stel sek. verpätet (sind beides audio oscs).

Synchronisation heißt synchron mit Samplegenauigkeit, ja.

und hat sich vielleicht wer mal kurz mein oben gepostetes ensemble angeschaut? ich bin draufgekommen, dass die ungenauigkeiten nichts mit dem master/slave ding zu tun hatten, sondern allgemein bei höheren frequenzen auftreten. liegt das vielleicht doch an der ungenauigkeit der eventausgebenden clock oscs?

vielen dank

hab ich nicht angesehen, da ich selbst wenig Zeit habe; vielleicht mal jemand anderer?

ciao herw

[fweth]

Synchronisation heißt synchron mit Samplegenauigkeit, ja.

ja, aber immer nur an der stelle wo die oscs gesynct werden, oder auch dazwischen, wenn sie sich nur der logik nach begenenen sollten? zB. ein osc hat 10 Hz, ein anderer 20 Hz, der mutterosc (der die beiden synct) 1Hz, begegnen sie sich dann auch ganz exakt auf einer halben sek. wo sie gerade nicht gesynct werden, oder nur immer jede ganze sek.?

danke

[herw]

Synchronisation heißt synchron mit Samplegenauigkeit, ja.

ja, aber immer nur an der stelle wo die oscs gesynct werden, oder auch dazwischen, wenn sie sich nur der logik nach begenenen sollten? zB. ein osc hat 10 Hz, ein anderer 20 Hz, der mutterosc (der die beiden synct) 1Hz, begegnen sie sich dann auch ganz exakt auf einer halben sek. wo sie gerade nicht gesynct werden, oder nur immer jede ganze sek.?

danke

"begegnen" ist hier sehr missverständlich; alle (normalen) Oszillatoren liefern mit der SampleRate ihre momentane Amplitude. Alle Oszillatoren werden durch einen jeweiligen Ramposzillator (Sägezahn) angetrieben.
Eine Synchronisation setzt den Ramposzillator z.B. auf die Phase 0 (Nulldurchgang mit steigender Flanke) zurück. Dann laufen jeweils die Schwingungen weiter. Erfolgt keine weitere Synchronisation, dann würden zwei Oszillatoren mit 20Hz und 30Hz sich immer wieder nach 2 Schwingungen des 20 Hz Oszillators (und drei Schwingungen des 30 Hz Oszillators) wieder gleichzeitig im Nulldurchgang (mit steigender Flanke) befinden. Am bestendu malst dir das für Sinusschwingung mal auf. Eine weitere Synchronisation ist daher nicht nötig, da ja alle Oszillatoren mit der SampleRate zur jeweils nächsten Phase wechseln.
Soweit die Theorie ABER : Der Ramposzillator (man kann sich eine Treppe vorstellen) endet wegen der vorgegeben SampleRate bei der letzten Stufe fast nie mit einer ganzen Stufe. Dies ist umso problematischer, je höher die Schwigungsfrequenz gegenüber der SampleRate ist. Dadurch hält der Ramposzillator(en) niemals seine vorgegebene Frequenz exakt ein. Man gleicht dies durch einen so genannten AntiAlaising-Algorithmus aus. In den NI-Oszillatoren der Core-Ebene findest Du überall Makros, die mit AA bezeichnet sind. Diese versuchen den kleinen Fehler auszugleichen. Diesen Algorithmus zu erklären ist, nicht einfach und bleibt auch mir im Wesentlichen schleierhaft, da ich die Theorie dazu nicht kenne. Nur soviel habe ich erkannt, dass am oberen Ende der "Treppe" das "Wrappen" (Herunterspringen an den Treppenanfang) nicht apruppt erfolgt, sondern in einer etwas geglätteten Kurve.
Wenn Du exakte Synchronisation zwischen den beiden Oszillatoren haben möchtest, dann müsstest Du jeweils den Zeitpunkt, wann die beiden Schwingungen sich rein rechnerisch wieder "begegenen" sollen, durch einen der beiden Oszillatoren synchronisieren oder beide Oszillatoren durch denselben Ramposzillator antreiben und durch Frequenzteilung die entsprechenden Frequenzen ableiten.

Ich hoffe es war etwas verständlich und halbwegs richtig; ich habe es aus dem Bauch geschrieben und soweit ich das verstehe.
Wer mehr Ahnung hat, möge mich korrigieren und ergänzen.

[fweth]

OK, ich verstehe schon

ich hab jetzt ein ensemble gemacht, mit dem ich die genauigkeit teste (siehe anhang), in der diese oscs eben funktionieren. man kann erkennen dass das ganze bei niedreigen frequenzen recht genau und zuverlässig funktioniert, bei höheren aber eine stärkere fehlerquote vorhanden ist.

allerdings verstehe ich jetzt ein paar sachen gar nicht mehr. meines erachtens sollte mein ensemble genau umgekehrt funktionieren, bei 1 sollte 0 auf dem numeric erscheinen, und bei 0 eigentlich 1, meiner logik nach. außer man gibt dem vergleichsoperator für A eine 1 ein, dann funktioniert das ganze aber erst recht wieder umgekehrt, also wieder anders als ich es erwartet hätte. das andere ist, dass das ding, obwohl ja beide oscs ständig gesynct werden, manchmal einfach bei 0 hängenbleibt, auch wenn man den switch immer wieder betätigt, und erst wenn man den prozessor im reaktor kurz ausmacht und wieder an, läuft das ganze wieder.

außerdem: kann man mehrere unit delays aneinanderreihen (mit dem effekt, dass die delaytime mehrere units dauert)? gibt es die möglichkeit, ein delay zu bauen, bei dem man die delay-time frei in units angeben kann?

und noch eine frage unabhängig zu diesem ensemble: wie kann es sein, dass in einem ensemble, wenn ich wo ein single delay mit der delaytime 0 dazwischenhänge, das ganze nicht mehr funktioniert?!? das delay ist mono, wie der rest auch, daran kann es also nicht liegen. aber sollte ein delay mit der delay time von 0 nicht überhauptnichts ausmachen? ich kann auch dieses ensemble posten, aber vielleicht wisst ja auch eine allgemeine antwort.

und noch etwas völlig anderes, was aber auch zu dem thread thema passt: ich habe einen generativen sequencer gebaut, und da ich den erst mal für die memory drum verwendet habe, habe ich einfach für die anschläge, die man nicht hören sollte, den pitch 0 verwendet. wenn man aber jetzt einen synth ansteuert, ist auch der pitch von 0 zu hören, deshalb habe ich jetzt versucht einen weg zu finden, so dass nur dann ein gate aktiviert wird, wenn der pitch über 0 liegt (siehe screenshot). das ergebniss sind jetzt total varierende gates von 0 bis 1 (was eigentlich nicht uninteressant klingt ; ) aber ich weiß weder den ursprung dieser variationen, noch wie man sie beseitigen könnte...

vielen dank

[herw]

... habe ich einfach für die anschläge, die man nicht hören sollte, den pitch 0 verwendet....

Pitch = 0 bedeutet etwa 8,1758 Hz. Vergleiche Handbuch zum modular m1 (Anhang).

[fweth]

0 bedeutet etwa 8,1758 Hz. Vergleiche Handbuch zum modular m1 (Anhang).

ja..ich habs ja anfänglich auch nur für die memory drum verwendet, und zufällig war in der standardeinstellung kein sample für den pitchzustand 0. da aber das eben keine allgemeine lösung ist, habe ich ja versucht, wie oben beschrieben, einfach die bedingung "wenn pitch = 0, dann soll kein gate zustande kommen" zu stellen, was aber noch nicht ganz korrekt funktioniert...

was ich übrigends vorher gemeint habe

allerdings verstehe ich jetzt ein paar sachen gar nicht mehr. meines erachtens sollte mein ensemble genau umgekehrt funktionieren, bei 1 sollte 0 auf dem numeric erscheinen, und bei 0 eigentlich 1, meiner logik nach. außer man gibt dem vergleichsoperator für A eine 1 ein, dann funktioniert das ganze aber erst recht wieder umgekehrt, also wieder anders als ich es erwartet hätte.

habe ich jetzt schon verstanden, wenn die frequenz mit einer geraden zahl multipliziert wird, trifft immer eine steigende flanke der langsamen osc auf eine fallende des schnellen (und umgekehrt), das hatte ich nicht bedacht. ich hab das ganze jetzt ein wenig visualisiert (mit audio table), aber jetzt kann ich das überhaupt nicht mehr nachvollziehen. in dem jetzt gerade geposteten ensemble sollte doch eindeutig der numeric den wert 1 ausgeben, oder nicht (dort, wo bei dem langsamen osc die stigende flanke ist, gibt der schnelle osc immer 1 aus)!?!

danke

[herw]

[...]
allerdings verstehe ich jetzt ein paar sachen gar nicht mehr. meines erachtens sollte mein ensemble genau umgekehrt funktionieren, bei 1 sollte 0 auf dem numeric erscheinen, und bei 0 eigentlich 1, meiner logik nach. außer man gibt dem vergleichsoperator für A eine 1 ein, dann funktioniert das ganze aber erst recht wieder umgekehrt, also wieder anders als ich es erwartet hätte.

habe ich jetzt schon verstanden, wenn die frequenz mit einer geraden zahl multipliziert wird, trifft immer eine steigende flanke der langsamen osc auf eine fallende des schnellen (und umgekehrt), das hatte ich nicht bedacht. ich hab das ganze jetzt ein wenig visualisiert (mit audio table), aber jetzt kann ich das überhaupt nicht mehr nachvollziehen. in dem jetzt gerade geposteten ensemble sollte doch eindeutig der numeric den wert 1 ausgeben, oder nicht (dort, wo bei dem langsamen osc die stigende flanke ist, gibt der schnelle osc immer 1 aus)!?!

danke[/quote]
ich habe mir dein Ensemble angesehen. Kannst Du erklären, welchen Zweck die Delay- und umgebenden Makros haben?

-unklar.gif

[fweth]

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...