Primary Ramp in Core

Fragen und Antworten, Beispiele

Moderator: herw

Primary Ramp in Core

Beitragvon pavel » So 11. Okt 2015, 13:16

Bin absoluter Core-Beginner und würde gerne endlich den Einstieg schaffen.

Vielleicht hat ja jemand Lust und Zeit mir dabei zu helfen, den Ramp Oszillator aus Primary nachzubilden und für meine Zwecke abzuwandeln.
Ziel ist später das konrollierte (getriggerte) Auslesen des Primary Audiotables, gesucht ist also ein ansteuerbarer Highres-"Oneshot"-Ramp-Makro.

Als Pseudocode habe ich mir bisher folgendes überlegt:
- positives Triggersignal -> setze Ausgangswert auf 0, setze Increment abhängig von angegebener Frequenz
- erhöhe Ausgangswert um Increment pro SR-Tick solange bis der Wert 1 erreicht ist oder springe zurück zu Punkt 1 falls neuausgelöst wird.
- wenn das Ausgangssignal den Wert 1 erreicht hat -> setze Increment auf 0 und warte auf das nächste positive Triggersignal

Wahrscheinlich verletze ich damit grundlegende Paradigmen.. da es sich ja thereoterisch um eine Mischung aus Oszillator und Envelope handelt, etwas Halbes und nichts Ganzes..
Dennoch: Habe ich beim Pseudocode etwas nicht richtig bedacht? Wie lässt sich sicherstellen, dass es wenig Aliasing gibt?
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Re: Primary Ramp in Core

Beitragvon pavel » So 11. Okt 2015, 17:33

Habe mal den Sägezahn Oszillator aus dem Manual nachgepatched und dann mit dem Sägezahn Oszillator in herws Core Additions verglichen.
Die Struktur verstehe ich soweit und erkenne die Unterschiede. Habe mir auch direkt einen freilaufenden Ramp Oszillator daraus geschustert.

Jetzt muss ich nur noch einen weg finden, den Osc triggerbar zu machen. Mal sehen..
Von alleine wäre ich aber nicht auf die Osc Struktur gekommen.. noch nicht ;)
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Re: Primary Ramp in Core

Beitragvon herw » So 11. Okt 2015, 17:36

pavel hat geschrieben:Bin absoluter Core-Beginner und würde gerne endlich den Einstieg schaffen.

Vielleicht hat ja jemand Lust und Zeit mir dabei zu helfen, den Ramp Oszillator aus Primary nachzubilden und für meine Zwecke abzuwandeln.
Ziel ist später das konrollierte (getriggerte) Auslesen des Primary Audiotables, gesucht ist also ein ansteuerbarer Highres-"Oneshot"-Ramp-Makro.

Als Pseudocode habe ich mir bisher folgendes überlegt:
- positives Triggersignal -> setze Ausgangswert auf 0, setze Increment abhängig von angegebener Frequenz
- erhöhe Ausgangswert um Increment pro SR-Tick solange bis der Wert 1 erreicht ist oder springe zurück zu Punkt 1 falls neuausgelöst wird.
- wenn das Ausgangssignal den Wert 1 erreicht hat -> setze Increment auf 0 und warte auf das nächste positive Triggersignal

Wahrscheinlich verletze ich damit grundlegende Paradigmen.. da es sich ja thereoterisch um eine Mischung aus Oszillator und Envelope handelt, etwas Halbes und nichts Ganzes..
Dennoch: Habe ich beim Pseudocode etwas nicht richtig bedacht? Wie lässt sich sicherstellen, dass es wenig Aliasing gibt?

Nö ist alles absolut richtig. Eine envelope Rampe ist schon dasselbe, wie ein Oszillator, nur dass der Oszillator wieder an den Anfang springt und dass das Envelope auf einen Trigger wartet.
Es ist klug, mit einem Ramposzillator den Einstieg in core zu nehmen, da es relativ einfach ist, aber die Grundprinzipien der Speicherverwaltung aufzeigt.
Nimm dazu das core-Makro saw(up) LFO. Da die Version von R5 relativ kompliziert ist, habe ich dir eine neue Rampe in R5 gebastelt (da du ja noch in R5 bist) , die der R6-Version entspricht. Trotzdem würde ich an deiner Stelle später in das Original hineinsehen, da man dort wieder zusätzlich etwas lernt.
rampe r5.ens.zip
(6.42 KiB) 110-mal heruntergeladen

Er schwingt zwischen -0.5 und +0.5 und wird am Ausgang verdoppelt, damit man eine Schwingung zwischen -1 und +1 hat (der Schwingungsbereich [-0.5 ... +0.5] ist für die Erzeugung der anderen Wellenformen günstig.
Du kannst sehr schön damit experimentieren: also Schwingungsbereiche verändern, Beendigung nach einer Rampe und Neustart etc.. Siehe auch die Hints im Makro!
Du kannst ihn auch normal als Audiooszillator benutzen, nur dass eben das AntiAliasing fehlt.

Knobel zunächst mal selbst herum und mach dir die Schritte klar
ciao herw

PS: du hast schon neu gepostet: das Retriggern geht ganz einfach! Da kommst du alleine drauf! Natürlich helfe ich, falls es dir nicht einfällt.
Benutzeravatar
herw
moderator
 
Beiträge: 3044
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: Primary Ramp in Core

Beitragvon herw » So 11. Okt 2015, 17:46

Das Aliasing zu verhindern ist eine etwas ausgeklügelte Sache, die man nicht so ohne Weiteres versteht. Ich habe sie auch nur übernommen und habe in einem schlauen Buch darüber gelesen. Der „Trick” ist der, dass man die Wellenform wohl quadriert und dadurch die „schädlichen” Oberfrequenzen unterdrückt und dann wieder zurücktransformiert.
Das müsste ich aber selbst noch nachlesen. In R6 sind die Audio-Oszillatoren ganz anders gestaltet und da müsste ich wohl sehr lange darüber nachdenken, bis ich da ein bisschen verstehe. Ist für mich auch ein Buch mit sieben Siegeln.
Aber darum geht es ja nicht, sondern du möchtest ja einen Einstieg in Core gewinnen.
Benutzeravatar
herw
moderator
 
Beiträge: 3044
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: Primary Ramp in Core

Beitragvon pavel » So 11. Okt 2015, 19:21

Danke dir herw für deine Mühe!
Ja, der Mechanismus hinter dem Antialiasing ist in der Tat schwer zu verstehen. Die verdammten Grenzwerte mal wieder... (Schulmathe lässt grüßen ;)
Da brauche ich dann wirklich nicht weiter denken - wenn selbst du zur Fachliteratur greifst!

Bezüglich des Retriggerns komme ich auf keinen grünen Zweig:
Habe mit den Read/Write Modulen versucht einen weiteren Speicherpunkt für das Increment zu besetzen und dann über das Gate zu beschreiben und auszulesen und dann bei erreichen des Wertes 1
auf 0 zu setzen und wieder auszulesen.. Werte schreiben wahlweise mit Latches oder Value-Modulen.. irgendwie scheine ich das Konzept noch nicht zu verstehen..

Vielleicht kannst du mir einen Tipp in die richtige Richtung geben?
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Re: Primary Ramp in Core

Beitragvon herw » Mo 12. Okt 2015, 08:00

pavel hat geschrieben:Danke dir herw für deine Mühe!
Ja, der Mechanismus hinter dem Antialiasing ist in der Tat schwer zu verstehen. Die verdammten Grenzwerte mal wieder... (Schulmathe lässt grüßen ;)
Da brauche ich dann wirklich nicht weiter denken - wenn selbst du zur Fachliteratur greifst!

Bezüglich des Retriggerns komme ich auf keinen grünen Zweig:
Habe mit den Read/Write Modulen versucht einen weiteren Speicherpunkt für das Increment zu besetzen und dann über das Gate zu beschreiben und auszulesen und dann bei erreichen des Wertes 1
auf 0 zu setzen und wieder auszulesen.. Werte schreiben wahlweise mit Latches oder Value-Modulen.. irgendwie scheine ich das Konzept noch nicht zu verstehen..

Vielleicht kannst du mir einen Tipp in die richtige Richtung geben?

Tipp 1: lass die Rampe mal zwischen -1 und 1 laufen und wirf die Verdoppelung am Ende heraus, dann ist die Struktur noch einfacher.
Tipp 2: Und nun lass sie bei 1 enden! Wieso läuft die Rampe überhaupt?
Tipp 3: und wie wirft man die Rampe wieder an?
ciao herw
Benutzeravatar
herw
moderator
 
Beiträge: 3044
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: Primary Ramp in Core

Beitragvon pavel » Mi 14. Okt 2015, 16:46

herw hat geschrieben:Wieso läuft die Rampe überhaupt?

da die SR.C das Read-Modul ausließt und dann mit diesem Wert das x + a Modul auslöst -> der Incrementwert wird dazugezählt und dann er Write in den Speicher geschrieben und an den Ausgang geschickt.
Das wiederholt sich so lange, bis bei erreichen des Wertes 1, 1 abgezogen wird.. dann beginnt die schleife wieder von 0..

bei erreichen von 1 die Rampe anhalten, könnte ich also entweder durch setzen des Increments auf 0 oder wegleiten der SR.Clock..
wie ist mir allerdings bisher noch ein rätsel..
oder stimmt meine ausführung schon gar nicht?
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Re: Primary Ramp in Core

Beitragvon pavel » Mi 14. Okt 2015, 16:56

ah ich glaube ich hab den wald vor lauter bäumen nicht gesehen.. es reicht ja eigtl. die frequenz bei erreichen des wertes 1 auf 0 setzen und dann bei bedarf per trigger signal wieder die frequenz afu einen wert zu setzen oder?
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Re: Primary Ramp in Core

Beitragvon herw » Mi 14. Okt 2015, 18:21

pavel hat geschrieben:ah ich glaube ich hab den wald vor lauter bäumen nicht gesehen.. es reicht ja eigtl. die frequenz bei erreichen des wertes 1 auf 0 setzen und dann bei bedarf per trigger signal wieder die frequenz afu einen wert zu setzen oder?
richtig gedacht; ist doch gar nicht so schwer ;) einfacher ist es einen router an den Ausgang zu setzen, der das Schreiben in den Speicher abschneidet. In der Tat wird der Loop wieder durch einen Gate Trigger gestartet (merger an der Reseteingang).
Benutzeravatar
herw
moderator
 
Beiträge: 3044
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: Primary Ramp in Core

Beitragvon pavel » Mi 14. Okt 2015, 21:35

:oops: das stoppen ist so ja wirklich leicht!

Wie meinst du das mit dem Merger?

Versuche gerade den Reset mit einer Rechteckswelle auszuführen, also nach dem Motto:
wenn der Rst-Wert in den positiven Bereich wechselt, schreibe den Wert 0 in den Speicher..
mit einem Audio impuls klappt es, aber mit dem pulsosc läuft noch irgendwas falsch..

Danke auf jeden Fall für deine Unterstützung.. der Aha-Effekt liegt hoffentlich in greifbarer Nähe ;)
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Re: Primary Ramp in Core

Beitragvon pavel » Sa 17. Okt 2015, 10:30

Habe gerade leider Probleme mit meiner Festplatte und muss erstmal meien Daten sichern,
aber habe im englischen Forum gelesen, dass es mit dem Threshold-Modul gehen müsste..
mal sehen ;)
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Re: Primary Ramp in Core

Beitragvon herw » Sa 17. Okt 2015, 12:49

pavel hat geschrieben::oops: das stoppen ist so ja wirklich leicht!

Wie meinst du das mit dem Merger?

Versuche gerade den Reset mit einer Rechteckswelle auszuführen, also nach dem Motto:
wenn der Rst-Wert in den positiven Bereich wechselt, schreibe den Wert 0 in den Speicher..
mit einem Audio impuls klappt es, aber mit dem pulsosc läuft noch irgendwas falsch..

Danke auf jeden Fall für deine Unterstützung.. der Aha-Effekt liegt hoffentlich in greifbarer Nähe ;)
zeig mal deine Lösung, wahrscheinlich reicht ein treshhold und ein dup-flt-modul; wenn es eine Audioquelle ist, dann wird ständig resettet, deshalb diese Kombination.
ciao herw
Benutzeravatar
herw
moderator
 
Beiträge: 3044
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: Primary Ramp in Core

Beitragvon pavel » Do 22. Okt 2015, 10:21

habe im englischsprachigen forum gelesen, dass die verwendung eines dup-flt meist einen kompromiss darstellt
und es einen eleganteren weg geben sollte.. ist da was dran?
bild: scheint sowohl mit puls und rechteck zu funktionieren..
Dateianhänge
core-ramp.jpg
core-ramp.jpg (25.33 KiB) 3426-mal betrachtet
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Re: Primary Ramp in Core

Beitragvon herw » Do 22. Okt 2015, 14:40

pavel hat geschrieben:habe im englischsprachigen forum gelesen, dass die verwendung eines dup-flt meist einen kompromiss darstellt
und es einen eleganteren weg geben sollte.. ist da was dran?
bild: scheint sowohl mit puls und rechteck zu funktionieren..
Die Frage ist, wie du den Reset einsetzen möchtest. Wenn du nur einzelne events erwartest (also zum Beispiel von einem Midigate oder sonst einem (zeitlich) einzelnen erzeugten Event, dann funktioniert deine Lösung, Wenn du eine Rechteckschwingung benutzt, dann musst du bei deiner Lösung ein dup-flt-Modul einsetzen, sonst feuert der Eingang während der gesamten positiven Phase mit audio-Rate.
Wenn du den Ramp-Oszillator von audio-signalen resetten möchtest (man spricht dann von Sychronisation), dann verwendet man meistens den Übergang der negativen zur positiven Phase (oder umgekehrt), da ja nicht nur Rechteck sondern auch andere Wellenformen vorliegen können (Dreieck, Sinus etc).
Dies geschieht durch einen Z^-1-Modul, in das der vergangene Wert gespeichert wird und dann mit dem aktuellen Eingangswert verglichen wird:

sorry die Abbildungen sind aus R6, aber ich denke du erkennst trotzdem alles wieder:
01.png
01.png (36.71 KiB) 3425-mal betrachtet

Die Einspeisung in den Oszillator sieht dann etwa so aus:
02.png
02.png (22.43 KiB) 3425-mal betrachtet

ciao herw
Benutzeravatar
herw
moderator
 
Beiträge: 3044
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: Primary Ramp in Core

Beitragvon pavel » So 25. Okt 2015, 18:06

ah so langsam fügen sich die einzelnen Teile zusammen.. die Synchronisation gleicht ja fast der SM deiner Oszillatoren in den Core Additions - jetzt kann ich mir sogar endlich mal was unter gesyncten Oszillatoren vorstellen.. :)

Das Resetten durch den Übergang von negativer zu positiver Phase habe ich gesucht. Die richtige Begrifflichkeit hat mir allerdings mal wieder gefehlt.

Danke dir auf jeden Fall! Ich denke, dass hat mir schon mal weiter geholfen!
Werde mal versuchen, davon ausgehend, meine Vorstellungen umzusetzen ::kaffee::
Benutzeravatar
pavel
synthesist
 
Beiträge: 52
Registriert: Mo 16. Dez 2013, 16:49

Nächste

Zurück zu MODULE UND MAKROS (core)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron