Mein erster Oszillator in Core. Und Hilfe, er knackst

[Rampensau]

Hallo,
ich bin noch ziemlicher Anfänger in Core. Da habe ich mir also einen kleinen Oszillator, der die Grundwellenformen ausspuckt, zusammengebastelt. Ich tue mich auch noch etwas schwer das zu verstehen.
Ich glaube die SampleRateClock wird in diesem Read und Write Loop akkumuliert, wodurch eine Rampe entsteht, die dann in einer angegebenen Frequenz ausgelesen wird.. Wie genau das funktioniert, begreife ich aber noch nicht so ganz.

Die Umsetzung des Rampensignals habe ich mit Hilfe des Überfliegens ein paar Seiten des Core-Manuals aufgeschnappt und nachgebaut. Sollte ich zu meinem Zweck etwa das ganze Manual durchlesen? Liegen dort meine Antworten? Ich werds ja eh in Zukunft tun, aber vllt hat ja jemand vorerst eine Lösung für meine Probleme.

Die jeweiligen Umformungen zu den anderen Wellenformen habe ich, bis auf das Cosinus-Macro und den Scanner selbst "entworfen" und sind auch ziemlich genau so in der Primary Umsetzung implementiert.

Soweit funktioniert alles ganz gut. Ich bin selber noch überrascht, dass überhaupt alles so geklappt hat.

Core Oszillator.JPG

Core-Osc.ens.zip

(Ich kann leider keine ens.-Files anhängen) (Die Datei muss gezippt sein - herw)

Zu meinen Problemen:

1. Der Oszillator knackst, wenn das Gate geschlossen wird. Woran liegt das? Kann es ne falsche Reihenfolge der Read-Write Module sein? Das Knacksen nervt schon arg und macht den Oszillator unbrauchbar..

2. Der Oszillator ist nur per Event synchronisierbar. Sobald ich den Sync/ bzw Reset-eingang (den ich von einem der LFOs in Core addaptiert habe) auf Audio umstelle, ist Funkstille im Oszillator.. Wie kann ich meine Core-Rampe mit einem anderen Oszillator synchronisieren?

3. In dem Kapitel zu der Rampe, (die in dem Beispiel eigentlich eine Core-tabelle auslesen soll) steht das es möglich ist, das Signal zu interpolieren, sie es aber dem User überlassen (so heißt es an der Stelle), eine Interpolation zu implemenieren.
Eine Interpolation wäre auch bitter nötig, der Unterschied zu hohen Samplingrates ist wie Tag und Nacht. Gleiches gilt für die Tables im Primary, aber mir ist erstmal wichtig, dass der Core-Oszillator gut klingt. Wie gehe ich das an??
Ich habe schon versucht, die SR-Clock durch einen höher frequenten Clock Oszillator zu tauschen. Bringt aber nichts.

Den Multiwave habe ich mir auch schon angeschaut. Wie dort das Antialiasing von statten geht, raff ich einfach nicht, wird mir aber freundlicherweise vom Core-Benutzerhandbuch selber überlassen.



Es macht auch nichts, wenn Änderungen etwas mehr CPU beanspruchen, da der Osc ja noch recht genügsam mit der CPU ist. Auf jeden Fall deutlich genügsamer als der Multiwave-Oszillator in Core.

Über Lösungsvorschläge und Feedback zu meinem ersten Core-Oszillator, wäre ich äußerst dankbar.

Grüße

[herw]

Es gibt im englischen Forum einen ziemlichen langen Thread, der unter anderem das Gebiet Oszillator abgrast.
Wenn Interesse besteht, dann kann ich in der Core-Abteilung etwas über die Oszillatoren schreiben einschließlich audio-Synchronisation, auch so, dass es jeder versteht.
Antialiasing ist allerdings vom Verständnis her eine harte Sache, aber ich hab's einigermaßen verstanden; ist allerdings ganz viel Mathematik und Phantasie dahinter.

ciao herw

[Rampensau]

Danke. Den Thread werde ich mir mal anschauen.

Wenn Interesse besteht, dann kann ich in der Core-Abteilung etwas über die Oszillatoren schreiben einschließlich audio-Synchronisation, auch so, dass es jeder versteht.

ciao herw

Unbedingt. Das wäre äußerst nett. Genau, was ich bräuchte..
In diesem Sinne schreit das nach einer Laola für Herw


Zur Mathematik:
Also ich hatte in meiner Prüfung zur Fachhochschulreife ne glatte 1 in Mathe geschrieben. Da ging es grob gesagt um Kurvendiskussion usw. Mehr als die Hälfte habe ich aber schon wieder vergessen. Soll nur heißen, an der Mathematik solls nicht scheitern.
Kann man sich beim Antialiasing denn auf "Standards" beziehen und diese in Core implementieren? Dann reicht ja vllt schon ne Runde Wikipedia.

Bei mir geht es so langsam in die "higher learning"-Runde mit Reaktor. In Core muss man ja echt gewissenhaft arbeiten. puh

Und habe ich denn grobe Fehler in meiner Oszillatorstruktur? Und besteht für den noch Hoffnung? Der ist so schön übersichtlich und CPU-freundlich. Klingt halt nur n bisschen doof, durchs Knacksen.

PS: Und wie findest du die Implementation der "Cosmo"-Breakpoint-Rampe aus den Casio CZs? Da habe ich mir erst voll den Kopf zerbrochen und es dann doch ziemlich simpel integriert bekommen.
Damit ist dann die Cosinusfunktion gefüttert, die sich wie im CZ zu einer Saw umbiegen lässt. Ist auch für die Symmetrie im Dreieck und Pulsweitenregulation in der "Kippstufe" verantwortlich. Beim Saw selbst bringt diese Änderung keine spektakulären Sounds.
Aber man hat PD ganz ohne Tabelle. Das war der Anreiz.

Grüße

[herw]

Danke. Den Thread werde ich mir mal anschauen.

Wenn Interesse besteht, dann kann ich in der Core-Abteilung etwas über die Oszillatoren schreiben einschließlich audio-Synchronisation, auch so, dass es jeder versteht.

ciao herw

Unbedingt. Das wäre äußerst nett. Genau, was ich bräuchte..
In diesem Sinne schreit das nach einer Laola für Herw


Zur Mathematik:
Also ich hatte in meiner Prüfung zur Fachhochschulreife ne glatte 1 in Mathe geschrieben. Da ging es grob gesagt um Kurvendiskussion usw. Mehr als die Hälfte habe ich aber schon wieder vergessen. Soll nur heißen, an der Mathematik solls nicht scheitern.
Kann man sich beim Antialiasing denn auf "Standards" beziehen und diese in Core implementieren? Dann reicht ja vllt schon ne Runde Wikipedia.

Bei mir geht es so langsam in die "higher learning"-Runde mit Reaktor. In Core muss man ja echt gewissenhaft arbeiten. puh

Und habe ich denn grobe Fehler in meiner Oszillatorstruktur? Und besteht für den noch Hoffnung? Der ist so schön übersichtlich und CPU-freundlich. Klingt halt nur n bisschen doof, durchs Knacksen.

PS: Und wie findest du die Implementation der "Cosmo"-Breakpoint-Rampe aus den Casio CZs? Da habe ich mir erst voll den Kopf zerbrochen und es dann doch ziemlich simpel integriert bekommen.
Damit ist dann die Cosinusfunktion gefüttert, die sich wie im CZ zu einer Saw umbiegen lässt. Ist auch für die Symmetrie im Dreieck und Pulsweitenregulation in der "Kippstufe" verantwortlich. Beim Saw selbst bringt diese Änderung keine spektakulären Sounds.
Aber man hat PD ganz ohne Tabelle. Das war der Anreiz.

Grüße

reinschauen ist immer mit ganz viel Arbeit verbunden, da man ja die Struktur nicht erklärt bekommt und man sich zunächst in den Programmierstil hineindenken muss. Also da muss ich aus zeitlichen Gründen zunächst mal passen.
Ein Nachmach-Artikel über Oszillatoren kann ich gerne hier schreiben, allerdings dann als Fortsetzungsroman. Das Antialiasing kann ich nur nachvollziehen und ich habe mir auch eine Begründung zurechtgelegt. Eine Nachfrage bei Stephan Schmitt ergab allerdings, dass er meinen Gedankengang nicht nachvollziehen konnte.
Aber grundsätzliches kann ich schon dazu sagen.

ciao herw

[Rampensau]

Ich bin für jede Information dankbar.

Ich mutmaße mal, wie die "Phasenrampe" entsteht:
Im Read-Write-Loop entsteht eine Art Rampen-Tabelle. Das Wrapmodul sorgt dafür, dass das alles in einem Loop von -0.5...0.5 gezählt wird.
Der "Syncphasenbaum" bestimmt über das Writemodul ab welcher Zahl diese Rampe eingeschrieben/ ausgelesen wird. Setzt die Zählung also per Gate mit einem eingestellten Phasenwert zurück.
Jetzt weiß ich auch wo der Haken beim Sync mit Audio ist. Da wird ja kontinuierlich ein Wert geschickt. Das Writemodul setzt die Lesung/ Zählung also bei jedem Clock zurück.
Wie der Frequenzbaum funktioniert kann ich mir noch nicht ausmalen.

Ab dem Punkt ist mir die Arbeitsweise eigentlich bewusst. Also:
Das Wrapmodul gibt nun ein Rampensignal von -0.5...0.5 aus. Dazu werden 0.5 addiert. Ab hier fängt der ""Cosmo"-Alogorithmus" an, wobei die Rampe in eine Rampe von 0-° und eine Rampe von °-1 geteilt.
Der Bereich über ° wird folgendermaßen verzerrt: (A -°) * (1/(1-°)) für die Rampe >0
Der Bereich unter ° so: A * (1/°)-1 für die Rampe <0
Die Ergebnisse werden zusammengemischt.
Wenn man also ° von der Mittelstellung (0,5) aus gegen 1 dreht, wird die Phase über 0 "schneller" und unter 0 "langsamer". So entsteht die Verzerrung.

Dieses verzerrte Rampensignal wird dann mit einer Cosinusfunktion verrechnet, um aus der Rampe ein Sinus zu formen, wobei über ° der Sinus "CZ-artig" zum Sägezahn morpht.

Das Dreieck entsteht, indem der Rampenteil >0 invertiert wird und die Mischung von 0...1 auf -1...1 konvertiert wird, wobei über ° die Symmetry geregelt wird.

Das Square entsteht in der "Kippstufe". Wobei das einfach nur ein Selector mit zwei Zuständen (-1 und 1) ist. Der Selector wird mit der Rampe durchfahren und ° gibt dabei die Pulsweite an, also wenn der Sägzahn über 0 ist, springt die Kippstufe auf 1.

In den Macros passiert also nicht weltbewegendes, sodass ich dachte, ein versierter Builder, wie du, müsse die Struktur nur sehen, um zu wissen, wo der Haken hängt. (Übertrieben gesprochen) Ist ja nicht sehr komplex die Struktur.

Mein Hauptproblem ist also die Phasenentstehung an sich und wie sie sich "audibel" syncen lässt. Also ähnlich den Oscis im Primary Level.

Ich mach jetzt erstmal ein paar Hausaufgaben

Danke

[herw]

[...]
In den Macros passiert also nicht weltbewegendes, sodass ich dachte, ein versierter Builder, wie du, müsse die Struktur nur sehen, um zu wissen, wo der Haken hängt. (Übertrieben gesprochen) Ist ja nicht sehr komplex die Struktur.
[...]

mit einmal hinsehen ist es nicht getan; ich schaue hier und im englischen Forum pro Tag ca. 1-2 Stunden hinein, springe von Thread zu Thread und versuche interessante Beiträge zu lesen und mich einzumischen. Natürlich sehe ich Grundprinzipien und eventuell auch unrichtige Ansätze; darauf muss man aber erst mal antworten, auf Gegenantwort warten, neu argumentieren etc. das zehrt an der Zeit; eigene REAKTOR-Vorlieben bleiben dann liegen; d.h man kann nicht unaufhörlich als Oberlehrer auftreten und ich bin sehr dankbar, wenn hier im Forum auch andere sich zu Wort melden, damit unser Forum lebendig bleibt.
Wenn ich mich in etwas hineinkniee, dann auch richtig; da muss ich zum Selbstschutz (Zeit) abwägen.

Ich denke, wenn ich auf Oszillatoren eingehe, wird das Thema Synchronisation auch in jedem Fall vorkommen.
Nur vielleicht soviel vorweg (was ich aus deinem Beitrag entnehme): die Synchronisation findet nur zu bestimmten isolierten Zeitpunkten statt: zum Beispiel, wenn die Welle von - nach + wechselt oder umgekehrt. Du findest das in den core additions, die ich mal vor einiger Zeit in die userlibrary hochgeladen habe; nicht schwer nachzuvollziehen.
Die Beschäftigung mit Core-Oszillatoren finde ich zum Beispiel fundamental und kann man auch zu 90% gut nachvollziehen, so dass man eigene Oszillatoren konstruieren kann.

ciao herw

PS: übrigens ein Knacksen habe ich eigentlich nicht vernommen.

[Rampensau]

Ich will natürlich niemandes Zeit in Anspruch nehmen. Solcher Hilfestellungen bedarf es den meisten ja auch nicht, es scheint ja auch "autodidaktisch" zu fruchten. Ich bin jedem dankbar, der sich Zeit nimmt, meine Lernkurve ansteigen zu lassen. Daher habe ich dafür vollstes Verständnis.

Aber bist du dir sicher, dass du dir die Coreversion angehört hast?

bei mir hört sich das so an:
http://soundcloud.com/risikopatienten/knacks

Ich habe auch rausgefunden, woher das kommt. Immer, wenn das Gate auf 0 springt, wird auch die Phase zurückgesetzt. Ich habe schon versucht den "0-Event" irgendwie zu unterdrücken, aber das krieg ich auch nich hin.

Was hälst du eigentlich von der Idee, den Square durch eine Art "Kippstufe"(die ich jetzt durch ein Relay erzeuge) entstehen zu lassen, anstatt durch "zwei" Sägezähne?
Nimmt auch etwas weniger CPU, wenn man den DC-Offset nicht extra wegnehmen muss. Ein paar Module kann man so durchaus einsparen.

Ich habe mal beide Versionen eingebaut. Einen Unterschied kann ich jetzt nicht wahrnehmen.

[Rampensau]

Ich würde deine Beiträge über Oszillatoren und deren Tuning mit viel Interesse verfolgen. Vllt kann man schon im Vorhinein ein paar Fragestellungen in Angriff nehmen. Und falls die Rückkopplung auf dieses Thema doch sehr gering ist (was ganz den Anschein hat), könnte ich es vollkommen verstehen, wenn du gar keine Lust auf diesen Roman hast. Und da hätte ich "Angst", dass die ursprüngliche Fragestellung untergeht, oder vllt gar nicht (mehr) behandelt wird, aus Gründen der mangelnden Rückkopplung. Ich bin ja im Moment das einzige Seelchen, dass nach einer Erläuterung des Core-Oszillators giert.
Aus Gründen der Archivierung und Sammlung von Workshops wäre das natürlich Gold wert und ich finde jeder Mensch ist ein Held, wenn er Zeit investiert, um sein Wissen ganz ohne entlohnende Erwartungen weiterzugeben.

Es wäre jedenfalls sehr schön, das Thema von dir in einem "Komplex" als Fortsetzungsroman abgehandelt, zu lesen.

Und meine Fragen richten sich ja nicht speziell an dich. Ich hatte auch gehofft mehr Rückkopplung zu meinem selbstgedrehten Oszillator zu bekommen. Der ja mal etwas funtkionaler als der vorgestopfte Multiwave-Oszillator ist, durch fehlendes Antialiasing aber nur mit hohen Samplingrates gut klingt. Naja, und er knackst noch immer.

Ich habe ja im Moment ein eingegrenztes Problem. Und da geht es unter Umständen erstmal schneller, schon mal hier speziell dies anzusprechen. Weil ein "Fortsetzungsroman" den Anschein hat, als würde der Sachverhalt, der mein Problem behandelt, erst in einem fortgeschrittenen Kapitel behandelt. Ein ganzer Roman wären in diesem Falle vielleicht sogar Perlen vor die Säue.
Aber du wirst den Oszillator-Workshop ja sicherlich nicht ausschließlich für meine Zwecke machen wollen. Sondern für das Wohl der Allgemeinheit.



also was ich jetzt genau will, ist ein Oszillator, den ich sowohl mit einem Gate syncen kann, als auch per Oszillator, wobei die Startphase einzustellen sein soll. Muss es zur Oszillatorsynchronisation ein Saw-Up Signal sein?

Wenn kein Signal gespeist wird, soll er natürlich freilaufend sein.

Ich möchte also einen Oszillator, der genau so gesynct werden kann, wie sein Primary- Pendant. Also sobald der Snc-Wert größer als 0 wird(egal ob von Audio oder Event), soll lediglich einmal der Reset-Event stattfinden.

Die aktuelle Situation
>Mein Oszillator kann schon ohne mal Beanstandung frei laufend sein.
>Sofern man Gate anschließt wird auf jedem Event zurückgesetzt, also "Gate an" und "Gate aus" senden beide einen Reset
>Sofern man den "Snc"-Eingang auf Audio umstellt, wird die Phase zu jeder Taktung zurückgesetzt. Ganz gleich ob ein Gate ankommt oder Audiosignal und ganz gleich, welchen Wert der Event hat.

Wenn du das in deinem Workshop behandeln wirst, und somit hier keine Erwähnung finden muss, dann muss ich mich halt gedulden. Dann dauert es halt so lange es dauert.

Grüße

[herw]

[...]
also was ich jetzt genau will, ist ein Oszillator, den ich sowohl mit einem Gate syncen kann, als auch per Oszillator, wobei die Startphase einzustellen sein soll. Muss es zur Oszillatorsynchronisation ein Saw-Up Signal sein?

Wenn kein Signal gespeist wird, soll er natürlich freilaufend sein.

Ich möchte also einen Oszillator, der genau so gesynct werden kann, wie sein Primary- Pendant. Also sobald der Snc-Wert größer als 0 wird(egal ob von Audio oder Event), soll lediglich einmal der Reset-Event stattfinden.

Die aktuelle Situation
>Mein Oszillator kann schon ohne mal Beanstandung frei laufend sein.
>Sofern man Gate anschließt wird auf jedem Event zurückgesetzt, also "Gate an" und "Gate aus" senden beide einen Reset
>Sofern man den "Snc"-Eingang auf Audio umstellt, wird die Phase zu jeder Taktung zurückgesetzt. Ganz gleich ob ein Gate ankommt oder Audiosignal und ganz gleich, welchen Wert der Event hat.

Grüße

Zunächst zum Knacksen: (ich hab's jetzt auch gehört). Dies wird eindeutig durch das GateOff-Signal erzeugt.

Knacksen.gif

Wenn Du die Verbindung zwischen Latch-Modul und write-Modul entfernst, hört es sofort auf.
Das Knacksen erfolgt dadurch, dass Du beim GateOff-Signal einen 0-Event sendest. In dem Fall wird der momentane Loop-Speicher des Oszillators abrupt auf 0 gesetzt. Das hört man besonders dann, wenn die ADSR-Kurve nicht schon auf geringe Lautstärke abgefallen ist. Noch unangenehmer wäre es, wenn dahinter dann noch ein Effektmodul (Hall, Echo) käme.
Um den Rücksetzbefehl durch das GateOff-Signal auszuschalten, kannst Du es mit einem Separator ausfiltern:

GateOn-Filter.gif

Nun zur generellen Synchronisation: Gute Hintergrund-Information zur Synchronisation erhältst Du auf der Doepfer-Seite zum A100: (das Online Handbuch ist gut zu lesen, wenn man sich die Mühe macht, einzelne Abschnitte herunterzuladen). Du kannst natürlich auch mein Handbuch zum Modular lesen. Da gibt es ein Extra-Kapitel zur Synchronisation.
Die stetige Synchronisation durch einen anderen Oszillator ist eigentlich das Spannende (Synchronisation durch das GatOn-Signal sind vor allem zur FM-Symhtese wichtig oder auch bei LFOs.)
Zur Synchronisation nimmt man eine Schwingungsform, die pro Periode eine eindeutige Situation erzeugt zum Beispiel den Übergang von negativen zu positiven Werten oder Null.
Eine komplexe Schwingungform die zum Beispiel durch Addition mehrerer Sinusschwingungen mehrfache Nulldurchgänge pro Periode enthält, ist dann nicht eindeutig, also ungeeignet.
Rechteck-signale sind auch problematisch, wenn man in den Bereich sehr hoher Frequenzen kommt, da der Nulldurchgang sich für verschiedene Tonhöhen sehr verschieben kann.
Ein Sägezahn muss es nicht sein, auch ein Sinus oder Dreieck sind gut geeignet.
Gemeinsam ist immer die Abfrage nach dem Übergang zu positiven Werten (man kann natürlich auch den Nulldurchgang von + nach - nehmen).
Dies geschieht durch einen (ständigen) Vergleich des synchronisierenden Signals:

Snychonisation.gif

Da es sich um ein Audiosignal handelt, wird es durch die SampleRateClock getaktet. Man speichert nun den jeweiligen Wert in einem Z^-1-Modul und vergleicht diesen mit dem nächsten Wert. Ist der vergangene alte Wert kleiner oder gleich Null und der neue positiv, dann wird der Loop-Speicher des synchronisierten Oszillator zurückgesetzt (oder durch eine Phase versetzt, wie Du es machst), sonst wird nur der neue Wert in den Z^-1-Speicher gebracht und auf den nächsten SampleTick gewartet. Alles ist nur eine Sache der richtigen Reihenfolge von Lese und Schreibbefehlen.
In der obigen Abbildung siehst Du die zwei Eingänge:
sync ist das synchronisierende Signal das von einem Oszillator kommt. Der Eingang Synchart entspricht Deinem Eingang Phase, wobei ich die Phase im Synchronisationsfall direkt in den LoopSpeicher schreibe.
Die Struktur ist fast selbst erklärend: das Signal vom sync wird in das Z^-1-Modul geschrieben. Das ist als erste Maßnahme zunächst mal erstaunlich, daher werfen wir zunächst einen Blick dort hinein:

Z-1-Modul.gif

Der untere Eingang ist der Clock-Eingang. Er ist hier intern mit der SampleRateClock verbunden, liefert also ständig ein Clocksignal auch ohne Verbindung von außen.
Nun ist die Reihenfolge der Schreib-Lese-Module entscheidend. In der OBC-Verbindung liegt das Lese-Modul vorrangig vor dem Schreibbefehl. Beide Eingänge werden gleichzeitig verarbeitet (das obere Audiosignal ist schon durch die SR.C. getaktet, also gleichzeitig zur SR.C. unten.
Damit entscheidet Core, dass zunächst der Lesebefehl ausgeführt wird und dann der Schreibbefehl, was nichts anderes bedeutet, dass der vorangegangene Wert an den Ausgang geschickt wird.

Nun wieder zurück zur Abbildung darüber.
Wir wissen nun, dass das Z^-1-Modul den vorangegangenen Wert liefert. Dieser wird mit dem aktuellen Wert sync verglichen. In diesem Beispiel wird überprüft, ob der vergangene Wert negativ war und der aktuelle Wert positiv oder Null ist. Die beiden Logikmodule liefern nur beim Nulldurcgang von negativ zu positiv oder Null gemeinsam den Wahrheitswert 1 und damit auch das Produkt der beiden (man hätte hier auch ein AND-Modul nehmen können. Was danach folgt, ist lediglich wieder eine Filterung des sync Signals genau für diesen Fall und das anschließende Setzen der Start-Phase. Hier sind Werte zwischen -1 und 0 geeignet. Ich wähle meistens nur die Extreme.

Nun wie wird das ganze eingebaut?

Audiosynchronisation.gif

no comment - siehe Abbildung.
Wichtig ist nur noch, dass der Synchronisationseingang selbstverständlich ein Audio-Eingang sein muss, sonst gäbe es ja nicht die Abfrage mit jedem SampleRate-Tick.

ciao herw

[herw]

[...]

Was hälst du eigentlich von der Idee, den Square durch eine Art "Kippstufe"(die ich jetzt durch ein Relay erzeuge) entstehen zu lassen, anstatt durch "zwei" Sägezähne?
Nimmt auch etwas weniger CPU, wenn man den DC-Offset nicht extra wegnehmen muss. Ein paar Module kann man so durchaus einsparen.

Ich habe mal beide Versionen eingebaut. Einen Unterschied kann ich jetzt nicht wahrnehmen.

Davon halte ich gar nichts. Für den Gebrauch als LFO ist dagegen nichts einzuwenden. Will man jedoch Aliasing und manch andere Unliebsamkeiten (einzelne Peaks) vermeiden, nimmt man ganz bewusst die Addition der beiden Sägeazahnanteile, da der Antialiasing-Algorithmus auf beide Anteile gleichzeitig wirkt und damit auch für den Rechteck.
Es lohnt sich da mal wirklich das Antialiasing-Macro zu überbrücken und dann die Kurvenverläufe mit einem Oscilloskop anzusehen (Eigenforschung).

ciao herw

[Rampensau]

wow Danke. Damit werde ich mich erstmal auseinander setzen. Ich konnte schon die ersten Denkfehler bei mir ausmachen.

Und genau, das Gate-Sync brauche ich für den Fall der FM-Synthese, oder wenn ich einen LFO daraus machen will, was nicht selten vorkommt. Meistens habe ich dann min 2 Operatoroszillatoren, die sich gegenseitig mannigfaltig modulieren können.
Den Freilaufmodus brauche ich ebenfalls für eine gewisse Bewegung zwischen zwei Oszillatoren.
Und dann natürlich Audiosync für die geilen Sync-Effekte.

Das mit dem Seperator hatte ich auch schon versucht. Nur hat das "Scope" dann verrückt gespielt. Jetzt weiß ich, woran es lag. Die Rampe für das Scope muss ja genau so behandelt werden. Klar.

Eine Frage: Hast du die Comparemakros für den Wahrheitswert hinter dem Z^-1 selber gemacht. Ich habe sowas schon überall gesucht, aber nirgends gefunden.


Jedenfalls blicke ich jetzt schon viel mehr durch. Tausend Dank

[herw]

[...]
Eine Frage: Hast du die Comparemakros für den Wahrheitswert hinter dem Z^-1 selber gemacht. Ich habe sowas schon überall gesucht, aber nirgends gefunden.
[...]

Das kann man in den Properties einstellen:

compare.gif

Die Logik-Makros habe ich dann eben einfach umbenannt mit >= , etc. da ich das eingängiger fand als IEG etc.

ciao herw

[Rampensau]

also ich meinte eigentlich das Makro

Compare.JPG

und als ich das nachgebaut habe, habe ich später gemerkt, dass es das "GT"-Makro aus dem Standard-Macros->Logic-Menü ist.

[Rampensau]

Ich habe es endlich hingekriegt. Nach langem Rumfummeln, habe ich testweise das DNC-Modul aus dem Latch-Makro entfernt und der Oszillator arbeitet genau so, wie gewollt. Au man, ich war schon zig mal so nah an der Lösung. Bis ich das ausprobiert habe sind viele Haare gerauft worden. Jetzt funzt er wie im Primary-Level.

Z-1-Modul.gif

Latch.JPG

Und hier ist der Primary-Clone-Saw-Sync-Oszillator in Core.
http://www.file-upload.net/download-226 ... s.zip.html

(Das Kontingent für Dateianhänge ist bereits vollständig ausgenutzt.)

Einmal roh als Core-Cell und einmal getunt als Multiwave-Osc in einem kleinen Testgelände enthalten.

Testgelände.JPG

[Rampensau]

Im Testgelände habe ich mal das Antialiasing für Saw uns Square aus deinen Oszillatoren adaptiert.
Da blicke ich noch nicht so ganz durch.

Außerdem würde ich gerne mehr Primary-Clones in Core basteln und die dann in die UL hochladen. Wäre es okay, wenn in die Makros vorläufig dein Antialiasing-Algorithmus eingebaut ist?
Würde dann ungefähr so aussehen:

AA by Herw.JPG

Dass ich dafür in meinen Bauten Verwendung finde, kann ich erstmal nicht verhindern.

Grüße und Danke