[PD] ipoke~ ?

katja katjavetter at gmail.com
Fri Jun 15 01:06:58 CEST 2012

On Thu, Jun 14, 2012 at 8:41 PM, Miller Puckette <msp at ucsd.edu> wrote:
> I've been thinking about this for some days.  I agree there are two
> fundamentally different approaches (A: deal with each incoming sample
> independently, for each one adding some sort of filter kernel into the
> table; or B: advancing systematically through the table, filling each point
> by interpolating from the input signal).

I've been focused on approach B (interpolate from the input signal)
for long time because it could eventually use the [tabread4~]
interpolation scheme, creating a parallel between those processes.
But... today I realized why approach B could not work at all for an
object which takes float indexes as arguments for writing, like you
would expect from [tabwrite4~], [ipoke~] or any variable speed writer:
for each perform loop, you get N (=blocksize) signal values and
equally many index values, so it would be logical to iterate over N
input samples, but in contrast, it would be very complicated to
iterate over the output samples and couple these to index values. In
fact, it would require yet another interpolation. Approach B would
only work fine for an object which has a fixed resampling factor,
settable via message. And then, the question how to synchronize it
with a [tabread4~] is still open.

It's weird how puzzling the task of fractional speed writing is,
compared to fractional speed reading. Better focus on approach A
(adding a fractionally delayed kernel into the array for each input
sample). Approach A does not in itself impose a preferred kernel type
or length, so different options could be offered to the user, varying
in performance and precision aspects. Each kernel length, if it is
fixed (and zero-phase), would imply a known delay, so the user can
reckon with it. As I see it, calculating the resampling factor for
normalization purposes need not be spoiled by numerical disasters, as
each difference is found from two consecutive input index values,
there is no autonomous cumulative effect. Or did I overlook something?
Anyway, I have to reset my brain again for a new focus on
[tabwrite4~], [vtabwrite~] or whatever it's name could be.


More information about the Pd-list mailing list