@porres said:

I don't get the interpolation formula, which one is it?

That's the "bad" one from tabread4~ where, in my abstraction, I used the "good" one from tabread4c~ -- see https://forum.pdpatchrepo.info/topic/14762/fidelity-of-tabread4/7

hjh

BTW I ended up still using the array for initialization -- with the samphold~ - rzero_rev~ approach, d won't receive a nonzero value until the third cycle, maybe not OK for the very slow control signals I need in this project.

But this works!

lfdnoise3~.pd

hjh

@porres said:

I had it on my list to also clone their cubic low frequency noise objects. If people want it, let me know.

Yeah, that's exactly what I wanted. I don't actually mind it being an abstraction; in the current situation (tight deadline) I'd have preferred not to have to spend time trying and failing to build it myself.

@jameslo I'd not have thought of the rzero-rev~ trick. Nice. (But I'd not use tabread4~'s formula, since tabread4c~ is better.)

hjh

@ddw_music said:

But I wonder why the shift register doesn't work -- pretty sure the same logic in SuperCollider, with BufWr, would be fine as long as the unit generator order is right. If poke~ is broke, maybe it should be fixed.

Ah, I see it... It isn't poke~ that's broke. When poke~ writes a new value in the middle of a block, any downstream tabread~ of any variety will read the new value for the whole block. (And SuperCollider would behave the same here -- my guess was wrong.) So the only way to make a shift register work is [block~ 1], which I won't do here. At any larger block size, the control point reads (not writes) are quantized to block boundaries and out of sync with the phasor.

So David's approach is right.

hjh

@jameslo said:

Instead of a shift register, I just maintain a 64 sample array of noise and refill it when I'm nearing the end, taking care to copy the samples relevant to the last read point to the beginning of the array so it can pick up where it left off.

Yes, low frequency noise, just not linearly interpolated.

I was gradually arriving at the idea of a longer array.

But I wonder why the shift register doesn't work -- pretty sure the same logic in SuperCollider, with BufWr, would be fine as long as the unit generator order is right. If poke~ is broke, maybe it should be fixed.

hjh

@jameslo said:

@ddw_music +1 to @alexandros' suggestion, but also--do you remember having this exchange? https://forum.pdpatchrepo.info/topic/14762/fidelity-of-tabread4/2
tabread4c~ doesn't have those non-differentiable points if that matters to you.

Good catch, but the shift register has to work first.

hjh

Tried to use an array as a signal-rate shift register -- it ends up in the right place but when the phasor~ resets, the shift isn't properly synced and the output glitches.

"The series of [pd] objects is meant to force scheduling order" but clearly it doesn't:

Can't avoid the cyclone reference I think b/c Vanilla has no equivalent of poke~. (Actually I wonder if poke~ doesn't update the array on time.)

lfdnoise3~.pd

hjh

@alexandros hmm... so, rotate control points through a table, that could work. Let me try later.

hjh

Anyone got a ramp generator that cubically or spline-ally interpolates between control points?

(Yeah, "you can roll your own," but I'm in a hurry and would prefer to save time if possible -- it would almost be faster to run PluginCollider via vstplugin~ and generate control signals by LFDNoise3 but that's maybe a bit much.)

hjh

@porres said:

this almost blew my speakers and ears when I opened the file watch out!

Thanks for telling me -- it was an init bug (where [change] was preventing one formant list from being init-ed).

formants.pd

Also for safety I put in a volume fade-in at init time too.

hjh