Thanks for the heads up! I will update, test, and commit soon (end-quarter
crunch right now)
- Julius
On Thu, Jun 9, 2016 at 3:24 AM, Bart Brouns wrote:
> Hi Julius,
>
> I just noticed, in oscillator.lib, sawN still uses the old saw algo.
>
> Cheers,
> Bart.
>
>
> On Thu,
Hi Julius,
I just noticed, in oscillator.lib, sawN still uses the old saw algo.
Cheers,
Bart.
On Thu, Jun 02, 2016 at 07:32:17AM +0200, Bart Brouns wrote:
>Thanks!
>
>On 2 jun. 2016, at 03:00, Julius Smith wrote:
>
>> Yes, the two cases behave surprisingly differently
Thanks!
On 2 jun. 2016, at 03:00, Julius Smith wrote:
> Yes, the two cases behave surprisingly differently (to me) in the
> time-varying case. Yours is more robust, so I've adopted it as
> follows:
>
> // --- lf_sawpos ---
> // simple sawtooth waveform oscillator
Yes, the two cases behave surprisingly differently (to me) in the
time-varying case. Yours is more robust, so I've adopted it as
follows:
// --- lf_sawpos ---
// simple sawtooth waveform oscillator between 0 and 1
lf_sawpos(freq) = frac ~ +(freq/ml.SR) with { // Bart Brouns version
frac(x) =
Hi Julius,
I just tested with moving frequencies and the difference becomes even
bigger:
(par(i, 1000, my_lf_sawpos(abs((i+10) *lfo) )):>_)/1000
(par(i, 1000, lf_sawpos( (i+10) *lfo )):>_)/1000
take 30 and 65 % respectively, even with the (usually unneeded) abs.
Cheers,
Bart.
Hi Julius,
Here is a screenshot of the output with default slider values, so the
frequency modulates between 0 and 110.
https://i.imgsafe.org/d635e0c8e8.png
I looked at the CPU usage too, and it turns out that on my system at
least, my saw is cheaper:
(par(i, 1000, my_lf_sawpos(i+10 )
Hi Bart,
As can be seen from its implementation:
// --- lf_sawpos ---
// simple sawtooth waveform oscillator between 0 and 1
lf_sawpos(freq) = lf_rawsaw(periodsamps) / periodsamps
with {
periodsamps = float(ml.SR)/max(1.0e-7,abs(freq));
};
lf_sawpos takes the absolute value of its freq