[PD] ipoke~ ?
jbeezez at gmail.com
Thu Jun 14 15:23:25 CEST 2012
Been in touch with P.A. (he's my supervisor at Huddersfield) and he would
be delighted to have a Pd version of iPoke~. If we get a posse together,
or if someone is happy to take it on, he's more than happy to share the
source code with us/you/them/it. There's also a new version (v.3) which
hasn't been released yet and we can take it from that.
We/you should decide who's going to take this on and then we/you can get in
touch with P.A.
Hope this helps,
On 14 June 2012 03:28, Matt Barber <brbrofsvl at gmail.com> wrote:
> >> Two points here. The last thing you said is not actually true -- each
> >> interpolation scheme has an associated convolution function, which can
> >> be calculated by imagining what the interpolation would look like for
> >> a single sample whose value was 1.0 surrounded by zeroes everywhere
> >> else. This 4-point piecewise function can be used to write four
> >> samples in its immediate vicinity the same way that the sinc does in
> >> the csound example.
> > Meaning, there is also a convolution kernel for linear interpolation?
> > How would it look like? Ah, it would be a simple dirac delta, but the
> > point is, the kernel can be applied time-shifted with fractional
> > delay, matching the fraction in the index. By the way, this also holds
> > for sinc-interpolated resampling as described by Julius O. Smith: a
> > linear interpolation in the sinc-table to make the result more
> > precise. Interpolating the interpolation kernel...
> The kernel for linear interpolation is a linear ramp from 0.0 to 1.0
> and then back down to 0.0. This means that if one were to do linear
> interpolation in the same way the csound opcode applies the sinc, you
> would center the peak of this ramp at the fractional index into the
> table, multiply it by the incoming sample, and then write the values
> of the ramp at the intersection points of the two nearby samples in
> the table to those samples.
> So, say the index is 126.78 and the incoming sample value was -0.45.
> You'd in effect ramp down from 0.0 to -0.45 over indices 125.78 to
> 126.78, and then back up to 0.0 from 126.78 to 127.78. As desired,
> this would intersect with samples at index 126 and 127, and the values
> would be -0.099 at 126 and -0.351 at 127.
> So, theoretically you could do the same with Pd's cubic lagrangian
> interpolation kernel, writing 4 points in the table for every incoming
> sample. This should work fine with a long interpolation kernel, but I
> foresee a lot of problems with doing this just for 4 points.
> Like, imagine you're going to write samples 0, 1, and 2 from the
> incoming signal to indices 2.3, 45.7, and 89.1. Doing it the way I
> described with a 4-point interpolator you'd put some values at indices
> 1-4, 44-47, and 88-91, and leave everything else at 0. Imagine you
> continued like this for a long time -- you'd have the original signal,
> each sample of which would be interpolated into 4 points, and each of
> these little spots would be, separated by long strings of zeroes. This
> isn't going to play back as "the same sound but lower," unless you ran
> it through a low-pass filter that smoothed this signal over the
> intervening samples, which I think would be pretty much like using the
> sinc for interpolating in the first place.
> I should mention that any time I've ever heard of moving the write
> head to make a variable delay, it's always with a big interpolation
> kernel. I'm going to look at a couple of other places - something like
> csound's spat3d opcode, or Richard Furse's old program "vspace" would
> be candidates for getting ideas.
> Hope this is all clear, and sorry if it's all obvious; sometimes it
> helps me to think about things to write out my thoughts.
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list