Simpler Sinus-Oszillator

[Rampensau]

Hey Leutz,
wer einen Sinus-Oszillator CPU-schonend implementieren will, benötigt dafür keinen Shaping-Algorithmus.
Viel mehr lässt sich schon während der Generierung des Signals mit rekursiven Elementen (z^-1 Makros) zu einem obertonfreien Sinus "filtern".
Ganz ohne Rampe oder Wrapping.
Habe ich im Sync Modular gefunden und wollte es euch nicht vorenthalten.

SM Sine.JPG

Das in Reaktor-Core übersetzte Makro könnt ihr euch herunterladen

Sine Oscillator.zip

Bei Hardsync ist nur zu beachten, dass die beiden z^-1-Module verschiedene Initialwerte haben, also nicht einfach auf 0 zurückgesetzt werden können.

[herw]

Hey Leutz,
wer einen Sinus-Oszillator CPU-schonend implementieren will, benötigt dafür keinen Shaping-Algorithmus.
Viel mehr lässt sich schon während der Generierung des Signals mit rekursiven Elementen (z^-1 Makros) zu einem obertonfreien Sinus "filtern".
Ganz ohne Rampe oder Wrapping.
Habe ich im Sync Modular gefunden und wollte es euch nicht vorenthalten.

SM Sine.JPG

Das in Reaktor-Core übersetzte Makro könnt ihr euch herunterladen

Sine Oscillator.zip

Bei Hardsync ist nur zu beachten, dass die beiden z^-1-Module verschiedene Initialwerte haben, also nicht einfach auf 0 zurückgesetzt werden können.

interessante Variante, müsste man mal genau auseinandernehmen, was die zwei z^-1-Module genau bewirken.
Die Synchronisation dürfte in der Tat schwierig sein.

[PrinzThomas]

Ja, ohne Hardsync nützt der schönste Sine-Osc nix, wenns ständig am Anfang knackt oder man kein syncronisiertes Multisine hinbekommt.
Allerdings mit langen Attackzeiten als Sub-Osci oder evtl. auch als FM-OP denkbar.
Obwohl FM ohne Sync nicht wirklich Sinn macht. ^^

[herw]

Ja, ohne Hardsync nützt der schönste Sine-Osc nix, wenns ständig am Anfang knackt oder man kein syncronisiertes Multisine hinbekommt.
Allerdings mit langen Attackzeiten als Sub-Osci oder evtl. auch als FM-OP denkbar.
Obwohl FM ohne Sync nicht wirklich Sinn macht. ^^

ich habe mir den Algorithmus nicht genauer angesehen, ich vermute aber mal, dass der „Sinus” eine wohl bekannte quadratische Näherung ist, die allerdings einer hohen Qualität einer reinen Sinusschwingung nicht standhält, aber raffiniert ist es schon. Aber vielleicht liege ich auch falsch. Woraus schließt du, dass diese Variante obertonfrei ist?

[PrinzThomas]

Mit Multisine meinte ich lediglich einfach zwei addierte Sine-Oscis, die evtl zu einander verpitcht sind.
Wenn da das Gate die Oscis nicht syncen kann, dann klingt sowas bei jedem Tastenanschlag anders.
Bei schnellen Sequenzen nerven dann diese Phasingeffekte ziemlich.
Grundsätzlich kann ich persönlich einen Osci ohne die Möglichkeit mit dem Gatesignal zu syncen überhaupt nicht brauchen.
Das gilt auch für alles, was schwingt, denn die meisten Wellen sind abhängig vom Tastenanschlag (zumind. sollten sie es meist sein) - ob es nun ein LFO ist der neuschwingen soll oder Sinuswaves mit kurzen Attackwerten.

[herw]

Mit Multisine meinte ich lediglich einfach zwei addierte Sine-Oscis, die evtl zu einander verpitcht sind.
Wenn da das Gate die Oscis nicht syncen kann, dann klingt sowas bei jedem Tastenanschlag anders.
Bei schnellen Sequenzen nerven dann diese Phasingeffekte ziemlich.
Grundsätzlich kann ich persönlich einen Osci ohne die Möglichkeit mit dem Gatesignal zu syncen überhaupt nicht brauchen.
Das gilt auch für alles, was schwingt, denn die meisten Wellen sind abhängig vom Tastenanschlag (zumind. sollten sie es meist sein) - ob es nun ein LFO ist der neuschwingen soll oder Sinuswaves mit kurzen Attackwerten.

In der Abbildung aus dem sync modular kann man ersehen, dass der Initialisierungswert 1 beträgt. Wenn man diese 1 bei allen Oszillatoren durch einen gate-On-Event setzt, hat man bei jedem Tastendruck eine Synchronisation.

[PrinzThomas]

Dann scheint ja die Syncronisation doch nicht so schwierig zu sein.

Ich müsste mich wirklich mal in die Corewelt niederlassen... ich bin eben leider etwas zu faul dazu. ^^
Überzeug mich doch bitte mal!
Gibt es grundsätzlich Dinge, die man in Core entwickeln kann, die auf der Primaryebene nicht nachvollziehbar sind?
Solange ich Module von Core und Primary-Makros verglichen habe - fiel mir immer wieder auf, dass die Coresachen stets mehr an Auslastung verursacht haben.
Ob es ein LFO ist oder ein Osci - jedesmal greife ich auf die Primary-Module zurück, weil ich bei den Coresachen ganz schnell die CPU hochflattern sehe.
Gibts eigentlich - außer den NI-Manuals - Bücher oder gute Tutorialseiten über die Coretechnik bei Reaktor?

[Snafic]

Auf der Website von N.I. gibt es weitere Infos zu Core.
Music DSP
Die Leistung wird bei einem Core Macro wohl immer höher sein als bei einem vergleichbaren Primary Modul, Core ist ja nur eine weitere Simulation wenn ich das richtig verstehe, der Rechenaufwand ist höher, dafür gibt es mehr kreative Möglichkeiten.

[herw]

[...] dafür gibt es mehr kreative Möglichkeiten.

viel mehr!

[Rampensau]

Woraus schließt du, dass diese Variante obertonfrei ist?

Es sieht jedenfalls so aus.

Sinus.JPG

Hardsync ist wirklich nicht so schwierig. Ich habe ja auch oben schon angeritzt, was da zu beachten ist. Hier meine Lösung in Core:

Sine (Sync).zip

Der Sync-Eingang ist auch auf Audio umschaltbar. Aber das gibt dann zu viel Aliasing.

Jedoch gestaltet sich ne FM sehr problematisch. Die Amplitude geht durch die Decke, sobald die Frequenz moduliert wird. hmmm.