[PD] ipoke~ ?

katja katjavetter at gmail.com
Sat Jun 16 11:32:59 CEST 2012

On Fri, Jun 15, 2012 at 3:34 AM, Matt Barber <brbrofsvl at gmail.com> wrote:

> If it used the same interpolator as tabread4~, you could in principle
> do approach B -- you'd need a struct that held on the the last samples
> of the previous block, and offset it by a sample.
> So, let's say you have a blocksize of 4, the first block of incoming
> signal is [-0.3, 0.4, 0.6, -0.8], and the index block is [0.2, 1.4,
> 3.0, 5.8]. The way this could work would be to imagine a previous
> signal block of [0, 0, 0, 0]. Put the "last 0" of that block at index
> 0.2 and the -0.3 at index 1.4. This crosses sample 1, so you find out
> where that sample sits as a fraction of the difference between those
> two indices (in this case 0.66666), use [0, 0, -0.3, 0.4] as the four
> points for interpolation between 0 and -0.3, writing sample one as
> though you were reading from a table with those four points at 0.66666
> between the 0 and the -0.3 (so far so good?).
> Then you put 0.4 at index 3.0. Now your interpolation points are [0,
> -0.3, 0.4, 0.6] to interpolate between -0.3 and 0.4. Index 2 occurs
> 0.375 between these samples so you run the interpolation function for
> that fractional index and write sample at index 2, and then you go
> ahead and write the 0.4 to index 3.
> Finally, you put 0.6 at index 5.8. You're interpolating between 0.4
> and 0.6, and the points are [-0.3, 0.4, 0.6, -0.8]. Index 4 occurs
> 0.357143 between the two samples and index 5 occurs 0.714286 between,
> so you run the interpolator twice for those fractional indices, write
> those samples.
> Then you save 0.4, 0.6 and -0.8 (the last the samples of the current
> block of incoming signal), and 5.8 (the last written index) for the
> next block. When you have the next block you'll have enough info to
> interpolate between 0.6 and -0.8 from the last block and between -0.8
> and the first sample of this one (these steps were actually implied
> the first time around), and then you're good to go for the next four
> samples.
> If I haven't forgotten a step, the same principle ought to work for
> any blocksize 4 or larger, and you'd need specialized policies for
> blocksizes of 1 or 2.
> Sorry for the length, but sometimes detailed examples can be helpful
> to get things straight.

After reading through it several times, I think I understand your
example, and how this could be expressed and implemented generally:

- an outer perform loop iterates over N input signal samples / float
write indexes, where N = blocksize
- an inner loop iterates over all integer write indexes inbetween
float write indexes stored at [n] and [n+1] (there could be none, one,
or more than one integer index in that interval)
- for each integer write index, calculate the corresponding read index
as a fraction of the interval between the two enclosing float indexes
- based on that fraction, do the four point interpolation to calculate
the sample that must be written

Not sure if I got it right, and if this would give correct results for
all cases.

Also, there would be no natural bound on the amount of samples
written. Imagine a user feeding large random numbers to the write
index inlet... There could be a user-settable bound on resampling
factor. For moderate resampling purposes it could be an efficient
model. Seems we're getting close to an implementation of [tabwrite4~].


More information about the Pd-list mailing list