Nachträgliches Syncen

Diskussionsforum für Fragen zur Struktur und Implementation in REAKTOR, auch DSP, Literatur und begleitende Software

Moderator: herw

Antworten
PrinzThomas
meister
Beiträge: 158
Registriert: 10. September 2006, 18:23

Nachträgliches Syncen

Beitrag von PrinzThomas »

Hallo,
es ist ärgerlich, dass es bei einigen Modulen wie z.B. Par PWM oder Tri/Par Symm keinen Sync-Eingang gibt.
In erster Linie geht es mir darum, dass bei Tastenanschlag die Welle vom Nullpunkt starten sollte damit man das typischen Knacksen bei kurzen Attackzeiten vermeidet.
Ich habe mir nun gedacht, ob es denn Sinn macht sich an eine nachträgliche Syncronisation zu machen.
Folgende Überlegung:
Bei bekanntem Pitchwert und dem Amplitudenwert des Ausgangs könnte man sich doch die Position in Millisekunden (Phase) der aktuellen Welle zum Zeitpunkt des Tastenanschlages errechnen.
Mit Hilfe diesen Wertes wäre doch ein nachträglicher Ausgleich mit einem Delay + Gate denkbar.
Natürlich verzögert sich dann die Sache je nach Position um max. fast eine Wellenlänge beim Tastenanschlag, aber ich schätze, dass diese Verzögerung so kurz ist, dass man sie 1. nicht wirklich wahrnimmt und sie gegenüber dem Nutzen eigentlich zu vernachlässigen ist.
Was denkt ihr darüber?
PrinzThomas
meister
Beiträge: 158
Registriert: 10. September 2006, 18:23

Re: Nachträgliches Syncen

Beitrag von PrinzThomas »

Keine eine Meinung dazu?
hmm...
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Nachträgliches Syncen

Beitrag von herw »

PrinzThomas hat geschrieben:Keine eine Meinung dazu?
hmm...
doch, aber ich habe mal einen Kurzurlaub gemacht.
Das einfachste ist, wenn du dir einen eigenen synchronisierbaren Oszillator in Core selbst bastelst; das ist eine sehr gute Einstiegsübung.
Wenn Du das kapierst, dann stehen dir alle Türen in Core offen.

ciao herw
PrinzThomas
meister
Beiträge: 158
Registriert: 10. September 2006, 18:23

Re: Nachträgliches Syncen

Beitrag von PrinzThomas »

Das Problem, was ich mit Core eigentlich habe ist 1. die Performancelast und 2. dass die Dinge meist einfach nicht gut klingen.
Beispiel sind einfache Sinus-Oszis.
Mit Primary klingt das auch noch in höheren Lagen wie ein Sinus.
In Core habe ich so viel Lösungen dazu angehört und da klirrt es nur noch wir meine Spülmaschine ab C4.
Und ich sehe nicht ein die Rate auf Kosten der CPU so hoch zu setzen, dass dieses Manko behoben wird.
Irgendwie muss ich sagen im direkten Vergleich bei Filtern - um mal ein anderes Beispiel zu nehmen - klingen die Primary Filter auch viel bauchiger.
Das Core klingt einfach an vielen Stellen zu genau, zu rein... einfach "zu digital". ^^
Anderes Beispiel sind LFOs und ENVs: ich habe aus Überzeugung, diese Sachen wären in Core einfach genau, mal einen Synthie darauf basierend aufgebaut.
Großer Fehler, denn die Core-LFOs und ADSRs verursachten fast 3 mal so viel CPU-Last.
Dem gegenüber steht natürlich die Freiheit des freien Programmierens - keine Frage.
Aber wenn das auf Kosten des Klanges geht verzichte ich großzügig darauf.
Für viele andere Steuer- und Eventsachen ist Core allerdings wirklich die bessere Wahl - z.B. für zyklische Schalter ;)
Das muss ich definitiv zugeben.
Aber zurück zum Thema... jetzt einen extra Core-Oszi zu entwickeln löst aber die ursprüngliche Aufgabe nicht.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Nachträgliches Syncen

Beitrag von herw »

PrinzThomas hat geschrieben:[...]
Aber zurück zum Thema... jetzt einen extra Core-Oszi zu entwickeln löst aber die ursprüngliche Aufgabe nicht.
Natürlich löst es das Problem, da sich aus dem im Core-Handbuch beschriebenen Sägezahnoszillator sehr leicht ein parabolischer Oszillator ableiten lässt. Um das Antialiasing brauchst Du dich auch nicht zu kümmern, da der parabolische Oszillator nichts anderes ist, als ein Sinusoszillator, der nur die Taylorreihenentwicklung bis zum dritten Summanden benutzt.
Wenn Du mal in den Core-Sinusoszillator hinein schaust, dann wirst du entdecken, dass es dort ebenfalls keinen Antialiasing-Algorithmus gibt, der auch nicht nötig ist.
Die Synchronisation ist ein einfaches Zurücksetzen des momentanen Phasen-Speichers auf Null, also kein Drama.
Die Beschäftigung mit dieser Art von Aufgabenstellungen hat für mich den endgültigen Durchbruch zur Core-Ebene gebracht.
Dass die Rückkonstruktion von primary-Level-Makros in Core eine höhere Perfomance benötigt, ist klar, da die primary-Ebene eben optimiert ist.
Dafür kann man sich aber leicht neue Spezial-Makros erfinden, die primary nicht anbietet.
Die CPU-Last dann auf ein Minimum zu reduzieren, ist Erfahrungssache.

Viel Spaß
PrinzThomas
meister
Beiträge: 158
Registriert: 10. September 2006, 18:23

Re: Nachträgliches Syncen

Beitrag von PrinzThomas »

Die Aufgabe war aber einen nicht syncbaren Oszi mit einer besonderen Methode nachträglich zu syncen.
Das hat nichts damit zutun, ob man sich gleich einen Oszi erstellen kann - außerdem wie gesagt bin ich Core-Gegner, was Oszis betrifft.
Ich weiß ja, dass du absoluter Core-Fan bist, aber vielleicht auch etwas zu verbohrt darin, zu erkennen, dass nicht alles darin gut ist.
Es ist einfach ein Fakt, dass die Core Sachen einfach nicht so dolle klingen.
Zumindest, was Dinge angeht, die man auch auf Primary Ebene lösen kann.
Aber das soll keine Diskussion über die Sinnhaftigkeit der 2 Ebenen antreiben.
Das Thema war ja wie man es schaffen kann durch Nachschaltung einen Oszi zu syncen - evtl. kann man diese Methode auch für andere Sachen nutzen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Nachträgliches Syncen

Beitrag von herw »

PrinzThomas hat geschrieben:Die Aufgabe war aber einen nicht syncbaren Oszi mit einer besonderen Methode nachträglich zu syncen.
[...]
Das Thema war ja wie man es schaffen kann durch Nachschaltung einen Oszi zu syncen - evtl. kann man diese Methode auch für andere Sachen nutzen.
ok - dann mach es eben so, wie Du es für gut empfindest - kein Problem
Ich bin auf deine Lösung gespannt.

ciao herw
Antworten