Phase Distortion im CZ-1 (Casio)

[herw]

Es gibt bei amazona.de einen interessanten Artikel von Holger Gerdes zum Thema Phase Distortion. Er greift dort auf eine Syntheseart zurück, die im Casio-Synth CZ-1 angewandt wurde.
Die Erklärungen sind sehr anschaulich und die Soundbeispiele informativ und beeindruckend.
Verschiedene Diagramme lassen sogleich die Lust aufkommen, entsprechende Synths (ohne Filter!) in REAKTOR nachzubauen.

ciao herw

[KlangRaum]

Klingt zwar interessant, ab so beim ersten Überfliegen des Text fehlt mir die Abgrenzung zur FM, die ja bei Yamaha in Wirklichkeit eine Phasenmodulation ist. Die Beschreibung ist etwas unklar. Liegt aber auch daran, das PD nie so richtig auf den Markt kam und man sich nur schwer was drunter vorstellen kann...

[Rampensau]

Im Grunde ist PD doch viel mehr ne Art Waveshaping.

Also eine Wellenform liest eine andere Welle aus einer Tabelle aus.
Das lässt sich mit ner Audiotable ganz einfach machen, indem man die X-Position mit nem Oszillator durchfährt.
Wenn du jetzt eine Rampe, die ja linear von 0 bis 1 verläuft, als Ausleser nimmst, kannst du die Wellenform in die Table so einzeichnen, wie sie auch rauskommt. Wenn man die Rampe jetzt verändert, erhält man interessante Klangveränderungen.

Ich habe mir zwei Audiotables genommen. In beide habe ich mehrere Wellenformen "gesamplet". Und eine Tabelle liest die andere aus. Das gibt schon ganz andere Sounds als FM.

Ein Phase Distortion wie im Casio krieg ich aber trozdem nicht hin. Der Ausleseroszillator hat zum Beispiel so einen Breakpoint in der Mitte der Rampe, der zeitlich modulierbar ist. Da habe ich mir bis jetzt noch keine Gedanken gemacht, wie ich das in Reaktor nachbasteln kann.

Aber alles in einem ist PD ne tolle Sache, finde ich

[KlangRaum]

Aber alles in einem ist PD ne tolle Sache, finde ich

Ich werd mich auf alle Fälle mal damit befassen...

Wenn du jetzt eine Rampe, die ja linear von 0 bis 1 verläuft, als Ausleser nimmst...

Hab ich schon im Ansatz als Core schon 'irgendwo rumliegen' - allerdings symmetrisch von -1…+1. Der Reiz liegt nicht darin, nur eine gezeichnete Tabelle auszulesen sondern die Wellenform per 'Formel' zu erzeugen

Gruss
Peter

[herw]

Aber alles in einem ist PD ne tolle Sache, finde ich

Ich werd mich auf alle Fälle mal damit befassen...

Wenn du jetzt eine Rampe, die ja linear von 0 bis 1 verläuft, als Ausleser nimmst...

Hab ich schon im Ansatz als Core schon 'irgendwo rumliegen' - allerdings symmetrisch von -1…+1. Der Reiz liegt nicht darin, nur eine gezeichnete Tabelle auszulesen sondern die Wellenform per 'Formel' zu erzeugen

Gruss
Peter

Ich meine mich erinnern zu können, dass ich das mal ganz einfach mit einer Excel-Tabelle gemacht habe.
Probiere ich gleich mal aus.

ja das geht: Excel Spalte erzeugen (zum Beispiel mit Formel!), dann als Textfile speichern (man erhält eine einfache Liste der Zellinhalte), dann in eine Audio- oder Event-Liste laden. - fertig

excel-audio.gif

[Rampensau]

Ist ja cool. Ich denke, die Grundwellenformen sind vllt noch mit wenigen Formeln machbar. Aber wie würde die Spalte für ein Rauschen aussehen?
Verständnisfrage: Den Ausgang der gezeigten Liste müsste man jetzt durch 25 teilen, damit die Werte 0 bis 1 rauskommen, oder?
Und wäre dann jede Spalte eine y-Position der Audiotabelle?

Kann man auch corebasierte Listen oder Tabellen per Textfile erstellen?
Ein Audiotablemodul gibt es in der Corelibrary ja nicht, oder?

Und für einen zufriedenstellenden Klang bräuchte man doch pro Sample mindestens eine Zeile. Also bei 44.1kHz = 44.1k Zeilen pro Spalte bzw Wellenzyklus, oder nicht? Oder lässt sich das zufriedenstellend interpolieren? Bei meinen Audiotables habe ich irgendwie das Problem, dass sie sich in den höheren Lagen irgendwie matschig anhören. Wenn ich das jetzt noch in Core über Exceltabellen umsetzen könnte, würde ich mir da auch Verbesserung versprechen.

Nur, in meine Tabellen habe ich unter anderem die 64 DWGS-Wellenformen von meinem Microkorg eingesamplet. Diese als Formel auszudrücken, wäre die Hölle.
Oder man gibt jeden Samplewert manuell in die Zeilen ein. Was bei 44.1k Samples eine andere Art von Hölle wäre.
Kann man Wellen irgendwie in Formeln umrechnen lassen?

Wenn das in Core nicht geht, sehe ich irgendwie kein Vorteil in der Formelmethode im Vergleich zu meiner "Sampletabelle". Im Gegenteil, ich habe so weniger Kopfzerbrechen und auch keine externe Datei, die mitgespeichert wird, da die Samples direkt in die Tabelle eingeschrieben wurden.

Edit: Mir fällt gerade auf, die Tabelle ist um die 20MB groß.. Wie kann das denn passieren?
http://www.file-upload.net/download-213 ... r.mdl.html

[KlangRaum]

Kann man auch corebasierte Listen oder Tabellen per Textfile erstellen?
Ein Audiotablemodul gibt es in der Corelibrary ja nicht, oder?

In Core kannste zwar Speicherbereiche anlegen, aber einen Datenimport gibts nicht. Du müsstest das über Umwege erst in eine Tabelle laden und danach (beim Initialiseren) rüberschieben.....

Ist ja cool. Ich denke, die Grundwellenformen sind vllt noch mit wenigen Formeln machbar.

Schau Dir mal das Core-Sinus an.

[herw]

[...]

Nur, in meine Tabellen habe ich unter anderem die 64 DWGS-Wellenformen von meinem Microkorg eingesamplet. Diese als Formel auszudrücken, wäre die Hölle.
Oder man gibt jeden Samplewert manuell in die Zeilen ein. Was bei 44.1k Samples eine andere Art von Hölle wäre.
Kann man Wellen irgendwie in Formeln umrechnen lassen?

[...]

Ich habe mir das Microkorg Handbuch mal herunter geladen:
http://www.korg.de/uploads/tx_softwarec ... ndbuch.pdf

Scheint sehr interessant und ausführlich geschrieben zu sein (Geheimtipp!).

Die 64 DRGS-Wellenformen werden nur mit Namen erwähnt. Eine Formel wird es für diese nicht geben, da sie komplexe Klänge darstellen (Piano, Orgel, Bass, etc.).

Das überlässt man Korg.
Interessant sind mathematisch erstellte Wellenformen, wenn man zwei davon ineinander morphen lässt. Dies ist durch eine relativ einfache Umrechnung möglich.
Bei jedem Sample-Clock entnimmt man aus beiden Tabellen den zugehörigen Wert und gewichtet sie. Wenn die Gewichtung von (0%|100%) durch einen LFO beispielsweise auf (100%|0%) verändert wird, hätte man einen kontinuierlichen Übergang von der einen Wellenform zur anderen.

ciao herw

[Rampensau]

Interessant sind mathematisch erstellte Wellenformen, wenn man zwei davon ineinander morphen lässt. Dies ist durch eine relativ einfache Umrechnung möglich.
Bei jedem Sample-Clock entnimmt man aus beiden Tabellen den zugehörigen Wert und gewichtet sie. Wenn die Gewichtung von (0%|100%) durch einen LFO beispielsweise auf (100%|0%) verändert wird, hätte man einen kontinuierlichen Übergang von der einen Wellenform zur anderen.

ciao herw

Genau das macht doch die Table. Wenn man die y-Position interpoliert, dann werden die Amplitudenwerte kontinuierlich von einer Wellenform zur nächsten "zurechtgeschoben.
Und wären 64 solcher komplexen Funktionen (für die Funktionskomponisten) nicht erheblich rechenintensiver, als 64 Zyklen aus einer Tabelle?
Ich habe jetzt auch ne neue Wavetable gebastelt mit ein paar zusätzlichen Waves und erheblich weniger Speicheraufwand.
Außerdem habe ich sie fürs Phase Distortion aufbreitet, indem ich sie "normalisiert" und die Startphase bei jeder Welle auf einen 0-Wert verschoben habe.

Wavetable.JPG

http://www.file-upload.net/download-222 ... e.ens.html

Außerdem habe ich es hingekriegt, die Phasenwinkel der Rampe so wie im Casio zu formen. Die bei Casio haben das irgendwie mit Pi gemacht, wie genau habe ich aber nicht verstanden.

Auf Seite 14
http://manuals.fdiskc.com/tree/Casio/Ca ... Manual.pdf
Zudem fande ich den Casio so cool, dass ich mir direkt einen CZ5000 geschossen habe. Müsste die Tage einfliegen.


Der Rampenformer zerteilt mittels Clipper-Module das Eingangssignal in zwei Teile, die über Umrechnungen mit einer Variablen ("Angle") zu der Breakpoint-Rampe wird. Den Modus nenne ich halt Pi, weil Casio das mit Pi gemacht haben. Irgendwie.
Der Mirrormodus invertiert den oberen Teil der entstanden Rampe und es entsteht eine Dreieckswellenform, dessen Symmetrie über die Variable "Angle" eingestellt werden kann.

Über den PD Regler kann man zwischen normaler und geformter Rampe morphen.
Der Waveshaper ist eine andere Wavetable.

[Rampensau]

Da hatte ich ja was in dem Kontext gebastelt....

Der Vollständigkeit wegen:
https://co.native-instruments.com/index ... tchid=9657
Der Aufbau war erstmal nur ein Feldversuch... Ich hab versucht, irgendwie die Wellenformenund Verzerrungsverläufe nach Vorbild meines CZs zu erzeugen und sie möglichst von Störgeräuschen zu befreien ohne die Hintergründe genauer zu analysieren...
Eine neue aktualisierte Struktur sähe nicht ganz so nach Laientheater aus.

Dennoch war die Erstellung der Oszis ne tolle Reise durch diese Syntheseart...
In ihrem Wesen ist es eine Phasenmodulation(!) (nicht Frequenz-) bei exakt 0 Hz. Formal kann man das Signal wie folgt formulieren:

f(t) = sin{[w+y(t)]t} entspräche einer FM, wobei y(t) der Modulator und w die Kreisfrequenz ist.


Für Phasenmodualtion wird der Phasenwinkel moduliert, nicht die Kreisfrequenz:
f(t) = sin[wt+y(t)] wobei die Kreisfrequenz w = 0 ist und y(t) der "Modulator".
Der Phasenwinkel ist hier mal 0.

Also wenn w = 0:
=> f(t) = sin[y(t)].

Wenn y(t) = t ist, stellt y(t) die Phase dar, wie sie in Core-Oszillatoren generiert wird und durch Shaping-Makros gejagt wird:
=> f(t) = sin(t)
... was dem Auslesen einer Tabelle von (Bsp. Sinus-)Werten mit einer Rampe entspricht..

Naja, und wenn y(t) nun andere Formen annehmen kann als y(t) = t, öffnet das eine riesige Spielwiese an Möglichkeiten, Obertöne zu erzeugen.
z.B. f(t) = sin[Pi*sin(t)]
y(t) = Pi*sin(t)


Der Casio Sägezahn:
f(t) = sin[y(t)]

y(t) = (x - p)/(Pi + p), für t zwischen (-Pi ... p)
y(t) = (x - p)/(Pi - p), für t zwischen (p ... Pi) ...Hier muss man zur Fallunterscheidung die Boolschen zur Hilfe nehmen.
für p zwischen (-Pi, Pi)...p ist der "Verzerrungsgrad", welcher in den CZs durch Hüllkurven angesteuert wird.



Ich hoffe, die feinen Unterschiede von FM, PM und PD sind erkennbar und ich hab das nicht all zu wirr formuliert..



Grüße