suche speziellen Randomgenerator

[mooncast]

Ich nutze JUCE und könnte stattdessen die dort bereitgestellte schnelle
sin-Approximation nutzen.

Das könnte auch auf Bhaskara basieren, gibt da sehr viele Variationen und optimierte Polynome.
Ich kann später auch mal meinen Sinus raussuchen, dann könnte mans direkt vergleichen.
Meine Erfahrung mit Tabellen war dass sie doch erheblichen Noisefloor machen, hab aber auch eher kleine Wavetables benutzt, 2048 Sampled, zT aber auch 65k.

 

[Turing]

Das könnte auch auf Bhaskara basieren, gibt da sehr viele Variationen und optimierte Polynome.
Ich kann später auch mal meinen Sinus raussuchen, dann könnte mans direkt vergleichen.
Meine Erfahrung mit Tabellen war dass sie doch erheblichen Noisefloor machen, hab aber auch eher kleine Wavetables benutzt, 2048 Sampled, zT aber auch 65k.

Ich habe die Bhaskara-Formel gefunden.
Sobald ich dazu kommen, würde ich deren Ergebnisse dann auch mit
der JUCE-Lösung vergleichen, vielleicht ist es dasselbe.

 

[mooncast]

hier der Faustcode wie er im Moment ist
// wrap -0.5...0.5 wrap(n) = n-( floor( n +0.5)) ; // quick sin normalized phase -0.5...0.5 qsincurve(x) = 1 - 16*( (x*x) *(1.2253517 - 3.60562732* (x*x))); qsin(x) = x+(0.5): wrap<: (abs:-(0.25):qsincurve),_:ma.copysign; // // oscillators mphasor(fw) = (+(fw) ~ (wrap)); phasor1(w) = (+(w) ~ (_<:_,(floor):-)); oscsn(fw,offset) = mphasor(fw) + offset:qsin:+~*(0.5); osc1(fw, off) = ((fw),+(off):oscsn) ~ (*(fbk1

wrap wrapt von -0.5 ... 0.5
qsincurve ist eine halbe Cosinuswelle von -0.25 bis 0.25, 7 Operationen
den phasor1 der von 0...1 geht kann man auch mit Cast statt floor machen,
ich nutz meistens aber von -0.5..0.5 weil das Vorteile für mich hat.
Mit dem Phasor1 würden nochmal 2 Additionen wegfallen.

Vorteil hier ist dass 0.25 90 Grad sind usw und alles normalisiert ist.

 

[Turing]

Leider verstehe ich Faust-Code nicht, aber die grundlegende
Formel ist ja immer dieselbe, wird nur je nach Zweck leicht
umgeformt.
Ich komme da für Tests / Genauigkeitsvergleiche also zurecht.

Habe schon festgestellt, dass die Bhaskara-Sin-Formel in Radiant
nur im Bereich [0,pi] funktioniert. Man muss sie durch eine
Fallunterscheidung auf (pi, 2pi] oder [-pi,0) fortsetzen, um
mit beliebigen Winkeln arbeiten zu können.

Alle Varianten von Bhaskara, die ich bisher gesehen habe, enthalten
eine Division - warum gibt es bei Dir keine?
(Kann aber auch sein, dass ich sie mangels Faust-Kenntnissen
übersehe)

Sofern es in Faust lokale Variablen gibt, könntest Du x*x nur
einmal berechnen (oder qsincurve gleich mit dem quadrierten
x als Parameter aufrufen), um eine Operation (die wiederholte
Quadrierung) zu sparen. Außerdem könntest
Du den Faktor 16 noch in die Klammer ziehen und mit den
anderen Faktoren im Voraus zu neuen Konstanten verrechnen,
um noch eine Operation zu sparen.

 

[mooncast]

Sorry bin grad am Handy deswegen etwas stichwortartig:
Wichtig ist nur dass die Phase hier von -0.5 bis 0.5 geht, statt zB -Pi bis Pi.

Und dass die Phase so berechnet wird
Phase plus Schritt minus round(Phase).

Dadurch kommt das ohne Branching/Condition aus.

Die Kurve ist von - pi/2 bis pi/2 cosinus.
Dh symmetrisch um Null.
Um Sinus und die fehlende Hälfte zu berechnen wird die Phase verschoben, dann die Kurve zweimal positiv berechnet und dann ein Teil negiert.
Alles ohne Conditions nur mit add, abs und copysign.
Faust Code ist klar dass das kryptisch ist aber : bedeutet dass eine Berechnung im Anschluss kommt, ist wie neue Zeile mit ; aber mit den fortlaufenden Werten davor.
_ bedeutet der fortlaufende Wert, können auch zwei oder mehr parallel sein getrennt mit ,. ~ ist Rekursion vor dem nächsten : auf gleicher Ebene...
Also das nachzuprogrammieren ist jetzt too much zum Testen, ist nur zum Verständnis.
Wobei der Test am besten mit dem Faust generiertem C Code von allem wär weil alles zusammenspielt...

Die 16 kann man nicht zusamnenfassen u kürzen, das ist schon die Kurzform wegen den Klammern. Hinten ist x^4 eigentlich. Das x*x müsste man wiederverwenden da hast Du Recht, aber dazubin ich noch nicht gekomen weil das in Faust tricky ist, man muss das Signal trennen und später wieder einfügen... Ich hab erst letzten Donnerstag mit Faust angefangen glaub ich. Ist echt ne Knobelei.

Das Prinzip ist einfach eine Parabel plus x^4 Kurve die die Parabel nochmal korrigiert. Parabel reicht für manche Sachen sogar als Sinusersatz.
Kann man auch gut nehmen um ne Sinustabelle zu interpolieren indem man 3Stützpunkte aus der Tabelle nimmt.
Ist billiger als Spline und geht bei Sinus sehr gut.

 

[mooncast]

Vielleicht kann man die 16 doch reinrechnen, hab grad nicht so drüber nachgedacht.
Gibt noch einige so Baustellen, ein Problem ist auch dass der Code sehr unzugänglich wird wenn man sowas optimiert, aber lohnt sich schon in dem Fall.

 

[Turing]

Ein erstes Ergebnis habe ich schon.

Für 1 Million äquidistante Testpunkte in [0, pi) und bei
Verwendung von double ergibt sich:

sinBhaskara (Formel aus Wikipedia):
RMSE: 0.000973575 = 9.73575e-4
MaxAbsErr: 0.00163177 = 1.63177e-3

juce::dsp::FastMathApprox (Padé approximant continued fraction)
RMSE: 2.04645e-06
MaxAbsErr: 1.10988e-05

Hier ist RMSE der mittlere quadratische Fehler und MaxAbsErr
der größte absolute Fehler an einem der Prüfpunkte.

JUCE verwendet mit dem Padé approximant also ein anderes
Verfahren und ist noch um 2 Größenordnungen genauer.

Ergänzung: JUCE ist ja quelloffen und man kann sich die Implementierung
ansehen. Sie braucht 8 x Multiplikationen, 1 x Division und 6 x Addition/Subtraktion.
Der Aufwand ist also auch deutlich höher als bei Bhaskara.

Ergebnisse mit lookup-Tables und linearer Interpolation oder
Splines kommen als nächstes.

 

[mooncast]

Pade braucht ja Division glaub ich.
Wird dann vermutlich etwas mehr CPU brauchen, und wohl auch nur ne Teilkurve berechnen?
Der grösste Fehler ist dann doch grösser als die von mir behauteten - 80 dB aber finde ich im Rahmen.
Ich denke für Audio ist ok wenn es um bzw unter - 60 bleibt. Im Grunde ist es doch erstaunlich dass man mit so ner kleinen Rechnung so nah dran bleibt.

Man muss zur CPU natürlich berücksichtigen das bei mir noch Rechnungen dazu kommen.
Kann man aber auch abschätzen.
Ich mach da zT auch den Denfehler mir einzubilden dass abs etc ja nix kostet, weil das auf modernen CPUs alled gleichlang ist ausser Division, Log Exp unf solche Sachen.

 

[mooncast]

Ach so, Du hast ja den aus Wiki genommen.
Also wenn Du die Kurve oben auch testen könntest wär das super.
Ich glaube die ist genauer dh der Fehler gleichmäsiger verteilt.
Aber halt nur x^4, was weniger genau sein muss.

 

[Turing]

Hier noch die versprochenen Ergebnisse für die Approximation von sin in [0,pi)
über Lookup Tables und Interpolation.

Ergebnisse für lineare Interpolation mit der angegebenen Zahl von
linearen Teilstücken (Zahl der äquidistanten Stützpunkte zur Ermittlung
der Teilstücke ist um 1 höher als die angegebene Zahl):

Größe	RMSE	MaxAbsErr
1	0.707107	1
2	0.150877	0.210514
4	0.0392843	0.0703776
8	0.00992092	0.0188463
16	0.0024865	0.0047921
32*	0.000622018	0.00120309
64	0.000155529	0.000301091
128	3.88838e-05	7.52925e-05
256	9.72104e-06	1.88244e-05
512	2.43027e-06	4.70617e-06
1024**	6.07567e-07	1.17655e-06
2048	1.51892e-07	2.94137e-07
4096	3.79729e-08	7.35343e-08
8192	9.49324e-09	1.83836e-08

* besser als Bhaskara
** besser als Fast Padé Approximation in JUCE

(Alle Berechnungen mit double-Genauigkeit. Referenzwerte von std::sin in C++, MVSC 2019).

Bei linearer Interpolation (und wenn nur Zweierpotenzen als Größe betrachtet werden!) braucht man
also eine Table mit 32 Einträgen, um die Qualität der Bhaskara-Approximation zu übertreffen,
und man braucht 1024 Einträge, um die Qualität der JUCE Fast Approximation zu schlagen.

Hier nun die Ergebnisse für kubische Splines (auch wieder unter Verwendung von äquidistanten Teilstücken):

#Splines	RMSE	MaxAbsErr
1	0.135711	0.214602
2	0.00685208	0.0107907
4*	0.00044199	0.000906216
8	2.78424e-05	6.05856e-05
16**	1.74357e-06	3.84958e-06
32	1.09026e-07	2.41588e-07
64	6.81499e-09	1.51147e-08
128	4.2595e-10	9.44912e-10
256	2.66221e-11	5.90609e-11
512	1.66389e-12	3.69149e-12
1024	1.04e-13	2.30815e-13
2048	6.50787e-15	1.45439e-14
4096	4.28911e-16	1.11022e-15
8192	1.19571e-16	7.77156e-16

Bei Interpolation mit kubischen Splines (und wenn wieder nur Zweierpotenzen als Größe betrachtet werden)
genügt eine Table mit 4 Splines, um die Qualität der Bhaskara-Approximation zu übertreffen.
Mit 16 Splines schlägt man die Qualität der JUCE Fast Approximation.
Die Qualität, die die lineare Interpolation in der Tabelle darüber mit 8192 Einträgen erreicht, schafft
man mit 64 Splines.
Für noch noch größere Spline-Zahlen erreicht man eine absurde Genauigkeit mit Abweichungen im
Bereich der 16. Dezimalstelle.
Sofern man die 4 Koeffizienten zur Beschreibung eines kubischen Splines vorberechnet hat,
braucht man zum Lookup in der Table und zur Auswertung 4 Multiplikationen, 3 Additionen
und eine Anwendung von modf (Auftrennung in ganzzahligen Anteil und Nachkommastellen).
Das sind deutlich weniger Operationen als zur Ermittlung des Padé approximants in JUCE,
dafür muss man aber einmal den zu verwendenden Spline aus der Table auslesen.

@mooncast:
Wenn Du mir deine Formel in einer lesbaren Form gibst, teste ich dafür gerne auch
noch die Genauigkeit. Ich habe keine Kapazitäten, mich in die Faust-Darstellung einzudenken.

Und es kann auch gern wieder zum Thema counter-basierte RNG geschrieben werden!
(Allerdings habe ich den Verdacht, dass dort "Squared" nicht viel Konkurrenz hat, zumal
dieses Verfahren auch effizient implementierbar ist).

 

[mooncast]

Das verblüfft mich jetzt, dh dass die Splineinterpolation so gut ist weniger weil das ja quasi Sincs ersetzen soll die mit 4 geeigneten Punkten ja Sine machen müssen, aber die lineare Tabelle dafür um so mehr.

Du kannst die Formel so testen wie sie oben steht, die müsste ja in jeder Sprache so gehen, wenn Du die Phase durch 2Pi teilst und die Werte auf zwischen -Pi/2 und Pi/ beschränkst und mit Cosinus vergleichst.
Bzw auf positive Werte bis Pi beschränkst Pi/2 subtrahierst und mit Sine vergleichst.

Ich nehme abee an dass sie ungefähr wie die Bhaskara die Du verwendet hast abschneidet.

Welche Werte Du für den Spline vorberechnest ist mir grad nicht ganz klar, hab den Spline aber nicht im Kopf vermutlich Differenzen von Eingangswerten?

Aber die Tabelle müsste dann trotzdem mehr CPU ziehen, oder etwa gleich weil ja ohne noch die Logik dazu kommt das suf ein Teilstück zu beschränken.
Was ich mich frage ist warum JUCE dann keine Tabelle nutzt, weil der Sine dort ja wahrscheinlich weniger als Osci als als genereller präziser Sine gedacht ist.

Jedenfalls sehr interessant.
Wenn ichs überschlage komme ich nämlich zB zu ner ganz anderen Einschätzung, 32 Werte sind ja nur 8 zwischen 0 und 1, das bedeutet, würde ich denken, einen erwartbaren Fehler von ca (0.707-0.5) * 1/16 also ca.- 30 dB.
Die Überlegung dabei ist dass der Wert nicht interpoliert ca 1/16 falsch ist, und linear interpoliert dann ca.die Differenz zwischen 0.5 und Sine 45°.

Frage mich wo da der Fehler in der Erwartung ist.

 

[Turing]

Ich verwende Cubic Hermite Splines.
Dafür braucht man die Stützwerte und ihre Ableitung (hier über cos gegeben).
OK ich schaue nochmal, ob ich mit Deiner Formel klar komme.
Die Logik zur Beschränkung auf das Teilstück ist in den angegebenen
Operations-Zahlen schon mit drin.
Die Interpolation ist jeweils von 0 bis pi (halbe Periode!), weil ja
auch Bhaskara nur auf der halben Periode definiert ist.
Wenn man auf eine Fallunterscheidung verzichten will und die
ganze Periode abdecken will, braucht man für die lineare bzw. die
kubische Interpolation jeweils das Doppelte der angegebenen Anzahl.

 

[mooncast]

wirklich interessant für mich wär mal die gesamt CPU Performance im Vergleich, vielleicht können wir das irgenwann mal machen, mit dem Faust generiertem Code.

Aber ich komm jetzt auch nicht dazu das vorzubereiten.Wär aber ein Test von generellem Interesse für viele denk ich.

Hab auch einen Fehler in meiner Abschätzung, mit 0.7-0.5 ist das ja nochmal gut -12dB kleiner, und mit Wertbereich von -1 bis 1 nochmal die Hälfte. Das ist immer noch mehr als Dein Ergebnis kommt aber in die Grössenordnung.

 

[Turing]

Ich nutze das selbst in einem Softsynth, an dem ich gerade schreibe.
Dafür wollte ich eh mal einen Thread aufmachen, vielleicht ist es an der Zeit!
Die Diskussion hier hat mich jetzt zumindest dazu gebracht, den
geplanten Spline-Interpolator zu implementieren - und
die Ergebnisse sind offensichtlich sehr gut und übertreffen eine
lineare Interpolation mit demselben RAM-Bedarf.
(RAM-Bedarf: für n Splines könnte man mit gleichem Speicherbedarf
linear mit 4n Stützpunkten interpolieren. Die Qualität der linearen
Interpolation mit der 4-fachen Zahl der Stützpunkte ist oben
im Beispiel aber schlechter als die der Splines mit der einfachen Zahl.
Das spricht für mich für die Nutzung der Splines.
Außerdem erhält man einen differenzierbaren Kurvenverlauf
ohne "Knicke".)
Wie sich der Rechenaufwand im Vergleich zur linearen Interpolation
verhält, muss ich noch bewerten, die Zahl der zusätzlichen Operationen
ist aber nicht allzu hoch, wenn man die Koeffizienten vorberechnet
hat, s.o.).
Im Moment habe ich in meinem Projekt noch viele lose Enden.
Profiling oder Micro-Benchmarks habe ich zwar auf dem Plan,
aber die Mühe lohnt sich erst, wenn der Durchstich errreicht ist
und alles grundsätzlich läuft.

 

[mooncast]

Für linear interpolierte Wavetables und generelle Kurven heisst das ja dass man ca 32 fach oversamplen muss, für minus 60 dB Fehler. Das trifft sich etwa mit meiner Erfahrung.
Ich hab 2048 Samples Table benutzt, durch alle Oktaven gleich, so dass das zunehmend oversamplet wird, mit linearer Interpolation, Splines fand ich zu rechenintensiv, hab aber keine Werte vorberechnet.
Für andere Funktionen hab ich 2^15 und 2^16 lange Tables genutzt, hatte aber dennoch messbare Artefakte.
Da wurde allerdings zT der Wert einer Tabelle durch den einer anderen geteilt was nochmal ein ganz anderes Problem ist.
Jedenfalls würd ich mich eher an der CPU Perfrormance orientieren, unter - 60 dB kann man viel mesden aber nicht hören.

 

[mooncast]

Profiling oder Micro-Benchmarks habe ich zwar auf dem Plan,
aber die Mühe lohnt sich erst, wenn der Durchstich errreicht ist

Für ein VST muss das auch nicht zwingend sein, aber ich will meinen Synth ja auf Plattformen bringen die damit ausgereizt sind, da ist das dann schon sinnvoll.

 

[Turing]

hier der Faustcode wie er im Moment ist
// quick sin normalized phase -0.5...0.5 qsincurve(x) = 1 - 16*( (x*x) *(1.2253517 - 3.60562732* (x*x)));
qsincurve ist eine halbe Cosinuswelle von -0.25 bis 0.25

Es handelt sich m.E. nicht um Bhaskara, sondern einfach
um eine Approximation von cos durch ein Polynom 4. Grades.

Habe daraus für den Test jetzt den entsprechenden sin
auf [0, pi] definiert.

Hier die erzielten Fehler:

RMSE: 0.000601698
MaxAbsErr: 0.00115326

Die Qualität ist also leicht besser als die der Bhaskara-Formel,
und man braucht keine Division.

 

[Cyclotron]

Was ich mich frage ist warum JUCE dann keine Tabelle nutzt, weil der Sine dort ja wahrscheinlich weniger als Osci als als genereller präziser Sine gedacht ist.

JUCE wird hier zugunsten der Performance Abstriche machen. Wenn man es ganz präzise braucht, muss man eben zu std::sin() greifen. Tabellen haben neben dem Aufwand der Adressierung auch das Problem von cache misses. Insbesondere bei großen Tabellen und / oder wenn man mit den Adressen beim Auslesen herumspringt. Außerdem verbaut man sich - je nach Einsatzzweck - mit Lookups auch ziemlich sicher die Möglichkeit, dass bei der Optimierung die automatische Vektorisierung eingesetzt werden kann (beispielsweise wenn man eine Sine Bank bauen will).

 

[mooncast]

Eben. meine Rede sozusagen. Die Padé Methode ist aber auch nicht umsonst.
Dh das mein Ansatz auf Tabellen zugunsten von schnellen Aproximation hier schon gerechtfertigt ist.
Allerdings weiss ich auch immer nicht wo auf welcher Plattform die Grenzen sind, zB kann man auch über Matheoperationen Clippen, dh den Wert beschränken ohne Conditions die ja ähnliche Problem machen.
Ob das sinnvoll ist weiss ich aber nicht.

 

[mooncast]

Es handelt sich m.E. nicht um Bhaskara, sondern einfach
um eine Approximation von cos durch ein Polynom 4. Grades.

Habe daraus für den Test jetzt den entsprechenden sin
auf [0, pi] definiert.

Hier die erzielten Fehler:

RMSE: 0.000601698
MaxAbsErr: 0.00115326

Die Qualität ist also leicht besser als die der Bhaskara-Formel,
und man braucht keine Division.

Vielen Dank.
Du hast Recht, das ist gar nicht Bhaskara der tatsächlich eine rationale Annäherung macht.
Dass es vergleichbar ist ist umso erstaunlicher finde ich.
Für meine Zwecke reicht es jedenfalls und wenn mans nochmal zusammenfasst wie Du vorgeschlagen hast wird es sehr effizient.

 

[Turing]

Ich hab 2048 Samples Table benutzt, durch alle Oktaven gleich [...]
Für andere Funktionen hab ich 2^15 und 2^16 lange Tables genutzt, hatte aber dennoch messbare Artefakte.

Wenn Du nicht gerade ein Sinusoid nachbildest, dann wird die Verwendung einer festen
Table für alle Frequenzen kaum ohne Aliasing funktionieren.
Eine klassische Lösung ist die Verwendung von vorberechneten Mipmaps.
Oder man nimmt tatsächlich eine naive feste Wavetable und nutzt BLITs,
BLEPs & Co, um im Nachhinein die hörbaren Artefakte zu verringern.
Infos dazu z.B. hier: https://www.metafunction.co.uk/post/all-about-digital-oscillators-part-2-blits-bleps
Worauf ich hinaus will: eine bestehende komplexe Wellenform einfach nur durch mehr Stützpunkte feiner
aufzulösen, damit die Interpolation genauer ist, wird das Aliasing-Problem nicht lösen.
Wahrscheinlich ist Dir das klar, aber der Beitrag war nicht ganz eindeutig.

 

[mooncast]

Wenn Du nicht gerade ein Sinusoid nachbildest, dann wird die Verwendung einer festen
Table für alle Frequenzen kaum ohne Aliasing funktionieren.
Eine klassische Lösung ist die Verwendung von vorberechneten Mipmaps.
Oder man nimmt tatsächlich eine naive feste Wavetable und nutzt BLITs,
BLEPs & Co, um im Nachhinein die hörbaren Artefakte zu verringern.
Infos dazu z.B. hier: https://www.metafunction.co.uk/post/all-about-digital-oscillators-part-2-blits-bleps
Worauf ich hinaus will: eine bestehende komplexe Wellenform einfach nur durch mehr Stützpunkte feiner
aufzulösen, damit die Interpolation genauer ist, wird das Aliasing-Problem nicht lösen.

MIPMaps hatte ich schon, ich glaub 3 Waves pro Oktave. Heute würde ich vielleicht eher eine pro MIDI Pitch verwenden.
Das meinte ich damit dass das zunehmend oversampled war: die Tables waren alle 2048 Samples, unabhängig vom Content. Dh die tiefen Frequenzen waren praktisch 1:1 und die höchsten dann nur noch Sinus in 2048.
BLEPs kenne ich schon, also ich hab früher solche Sachen für Geld gemacht und bin jetzt nicht ganz unbeleckt davon.
Ich mach auch das Noise hier im Prinzip mit ner Art BLEP, dh es gibt nur 1 neuen Wert alles paar Samples, und zwischen den Werten ist eine Art BLEP, in dem Fall nur eine parabolische Kurve aber das Prinzip ist dss selbe.
Die Lösung ist nicht besonders gut, aber die billigste die mir einfiel um das antialiased zu synchen.

 

[mooncast]

Wo ich mit Tables Probleme hatte war "Infinite Linear Oversampling", eine Methode die von Leuten bei Native Instruments vorgrschlagen wurde um Verzerrungskurven aliasarm zu machen.

Im Prinzip wird da mit dem Integral der Kurve gearbeitet und der Ableitung, dh Differenzsignal des Inputs, und beides Differentialgleichungsmässig geteilt.
Und da gibts dann je nach dem Probleme wenn man das mit Tabellen macht, geht aber.
Hat mit Wavetables nicht so viel zu tun aber ich hatte das nicht mehr so im Kopf wo die Probleme auftauchen.

 

[Turing]

Das meinte ich damit dass das zunehmend oversampled war: die Tables waren alle 2048 Samples, unabhängig vom Content. Dh die tiefen Frequenzen waren praktisch 1:1 und die höchsten dann nur noch Sinus in 2048.

OK, dann meintest Du mit "durch alle Oktaven gleich" nur, dass die Größe einheitlich war (nicht der Inhalt), das sollte dann ein valider Ansatz gewesen sein. Ich war nur auf das "durch alle Oktaven gleich" angesprungen, das war dann wohl falscher Alarm.

Ich mach auch das Noise hier im Prinzip mit ner Art BLEP, dh es gibt nur 1 neuen Wert alles paar Samples, und zwischen den Werten ist eine Art BLEP, in dem Fall nur eine parabolische Kurve aber das Prinzip ist dss selbe.
Die Lösung ist nicht besonders gut, aber die billigste die mir einfiel um das antialiased zu synchen.

Der Begriff synced noise sagt mir ehrlich gesagt bisher nichts.
Meinst Du damit ein getaktetes Sample&Hold-Signal mit zufälligem Haltewert - das aber von den Aliasing-Störungen möglichst befreit werden soll?
Wenn die Sync-Frequenz kein Teiler der Sample Rate wie z.B. 44100 Hz ist, wie handhabst Du dann die Fälle, dass der Sync-Zeitpunkt irgendwo zwischen dem Zeitraster der Sample Rate liegt?

 

[mooncast]

Wie bei Oscillator-Sync, die Noise Sequenz fängt periodisch mit frei bestimmbarer Frequenz von vorne an und wiederholt sich.
Wenn die Phase des Sync-MasterOszillators von 0. bis 1 geht, dann ist der relative Wert des ersten Samples nach dem Sprung von 1auf 0 verglichen mit der Schrittweite die Zeit als Bruchteil eines Samples die man den Startwert verschieben muss.
Sagen wir die Sequenz besteht aus 0,1,2,3,4,...
und die Schrittweite ist F/Samplerate, und R ist der erste Wert der Phasenrampe nach dem Sprung, dann muss man mit
R/Schrittweit zwischen 0 und 1 interpolieren weil das die Zeit ist die schon vergangen ist.
Allerdings muss man eigentlich das Sample das hinten als nächstes käme mit dem ersten Samples der Sequenz interpolieren, und das nicht nur 1 Sample lang sondern zB 4. Und besser ist wenn der Übergang wie ein Bandlimitierter Step ist.
Wavetables kann man so auch synchen, das Noise wird wie eine Wavetable aus unterschiedlichen Kurvenstücken behandelt.