Cubic or spline ramp generator?
@manuels said:
Shift register with precalculated basis functions (or rather: basis functions read from a precalculated kernel): interpolated-noise.pd
Hey, this is cool, I've never seen this. But hey, I don't know what you mean by "Shift register with precalculated basis functions (or rather: basis functions read from a precalculated kernel)"
I don't know what "Shift register" is supposed to mean here, or "precalculated basis functions", or "basis functions read from a precalculated kernel", or what is "kernel" here
I just wanted to make music, no one told me there'd be math 
What I see is that you have 6 point interpolation, even for linear interpolation, and this is really something new and confusing, a whole new approach to me, as I'd just use two points here, and you have at least 3 for that. Anyway, I also see "quadratic" and "cubic", which was my question from before...
I guess this is an interesting approach that works well for didactic reasons. I think that if I really get what is going on here I'll better understand these kind of interpolations, but it doesn't seem like a good way to code something in 'C', huh? Or is it?
Cubic or spline ramp generator?
I didn;t know about "LFDNoise3", is it a new one? Wow, I can't believe they have so many 
I see this one is dynamic. Hard to to know exactly by looking, the documentation kinda sucks in clarity, but it seems the other one "hangs" on low frequency in a way that it can't speed up follow a frequency increase from a [phasor~] or something? Wow, that's bad
So, like I said, I easily adapted [rampnoise~] to use spline, so it's a 4 point interpolation. Now, I wanted to see what kind of interpolation SC uses and it's also not clear or well documented. It just says "quadratically interpolated" or "cubic interpolated", and for someone not that much into math, this is not enough, can anyone help?
What kind of interpolation is spline? I don't wanna look into their source code 
Cubic or spline ramp generator?
@ddw_music Just to throw in another way of doing the same thing …
Shift register with precalculated basis functions (or rather: basis functions read from a precalculated kernel): interpolated-noise.pd
I used this for an interpolated version of the Gendyn stochastic synthesis algorithm, which can be used as a simple noise generator as well … gendyn-interp.pd
wavetable-synth with phasor and tabread4 / no clicking
@willblackhurst If you look at the help file for [tabread4~] you will see that correct interpolation requires guard points added to the array so that interpolation is performed correctly as [phasor~] wraps around the end of the array.
Your patch doesn't glitch between the array copies, but it does as [phasor~] wraps at the end of the 3rd copy, or where you chop into the array adjusting the clip length percentage.
@lacuna made a handy patch to add guard points automatically.... https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect
I suppose that if you want to adjust the playback length then you would need to copy a percentage of the array to a new array, and then add the guard points.
David.
Buffer delay loop
@DesignDefault Welcome to the Forum...!
Sorry, this will be a lot for a newbie.
You will see in the video @ricky has linked to that the [phasor~] object controls the speed at which the array is being read.
So you will need to increase the number that it receives at its left inlet in order to increase the speed.
It is an audio rate inlet, so you will need [sig~] to convert a control rate 1 to a signal rate 1.
1 will play at normal speed, 2 at double that speed etc.
Unfortunately you will need to "catch" a moment in the [phasor~] loop using [edge~] and then increment that value to [sig~] by whatever increase you want each time that [edge~] outputs a bang.
Catching the exact moment that it loops can be awkward and you might well need to add or subtract a value from the output of [phasor~] before sending it into [edge~]
A more reliable method would be to use a [metro] to increase the [sig~] with the metro rate set by the value from [timer].
Also, before playback (it only needs to be done once for the array after it has been filled) extra data points should be added.
That will stop clicks as [phasor~] wraps back to the beginning of the array.
https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect
That will add 3 data points to the array, allowing [tabread4~] to correctly interpolate the samples at wrap around.
For that to work properly you should then add 3.... [+ 3] to the total number of samples after the [* 44.1]
Also, if you are running Pd at 48000Hz the [* 44.1] should be changed to [* 48] for the initial playback speed to be correct.
David.
Help needed with problem in creating a grain (somewhat)
Further to @jameslo 's suggestion...... have a look at this...... https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect .... from @lacuna
Long discussion here although a different topic....... https://forum.pdpatchrepo.info/topic/14299/question-about-tabread4
[tabread4~] interpolates... so adding the guard points to the array interpolates as the playback wraps.... and there will be no clicks....
David.
looking for velvet noise generator
@ddw_music said:
Uses else's del~ because delread~ requires a message-based delay time, which can't update fast enough, and delread4~ interpolates, which smears the impulses. With del~, I could at least round the delay time to an integer number of samples, and AFAICS it then doesn't interpolate.
Actually delread4~ doesn't smear if the delay is always an integer number of samples (which makes sense from the cubic interpolation formula -- if the fractional part of the index is 0, then you just get the sample value at the integer index).
It's easier to ensure an integer-sample delay time using else/del~'s -samps flag 
I've definitely not dug deeply enough into ELSE -- so many things that are a PITA in vanilla become straightforward. (I'd have complained a lot less four-five years ago if I had known about this library from the beginning!)
hjh
looking for velvet noise generator
@porres said:
to never miss a period, but I also think this is a job for a C code.
To atone for my earlier SC jibe, here's a delay-based approach. (Also, indeed you're right -- I hadn't read the thread carefully enough. Dust / Dust2 don't implement exactly "one pulse per regular time interval, randomly placed within each interval.")

Uses else's del~ because delread~ requires a message-based delay time, which can't update fast enough, and delread4~ interpolates, which smears the impulses. With del~, I could at least round the delay time to an integer number of samples, and AFAICS it then doesn't interpolate.
It looks to me in the graphs like there is exactly one nonzero sample per phasor~ cycle.
hjh
PS FWIW -- one nice convenience in SC is that non-interpolating DelayN doesn't require the delay time to be rounded 
(
a = { |density = 2500|
// var pulse = Impulse.ar(density);
// for similarity to Pd graphs, I'll phasor it
// but the Impulse is sufficient for the subsequent logic
var phasor = LFSaw.ar(density);
var pulse = HPZ1.ar(phasor) < 0;
var delayTime = TRand.ar(0, density.reciprocal - SampleDur.ir, pulse);
var rand = TRand.ar(-1, 1, pulse).sign;
[DelayN.ar(rand * pulse, 0.2, delayTime), phasor]
}.plot;
)

fidelity of tabread4~?
@ben.wes That's a super-interesting read, thanks. It made me aware of cyclone/wave~, which in turn made me aware that Pd's interpolator is Lagrange, which appears to be not exactly the same as what's called cubic interpolation? 5 minutes with Google suggests that cubic interpolation is differentiable everywhere, whereas I think Pd's interpolator has sharp slope reversals.
Sample rate issues while using [Soundfiler]
@ChicoVaca The problem as you say is the number of samples per second for your sample. Pd will be playing them at 44100 or 48000 samples per second (which you have set for your sound card in the Pd media settings).
So 4000 samples will be played in about 1/10th of a second.
The solution is about a third of the way down the page that you linked to, and a little bit of maths can calculate the value (automatically in your patch using the sample rate from [soundfiler] and the setting for Pd) that you will need for [line~] to play the sample correctly using [tabread4~]
For correct interpolation guard points should be added to the array, and fortunately @lacuna made a patch that makes adding guard points very easy........ https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect
David.
