[PD] ipoke~ ?

katja katjavetter at gmail.com
Sat Jun 16 21:18:29 CEST 2012

On Sat, Jun 16, 2012 at 7:16 PM, Matt Barber <brbrofsvl at gmail.com> wrote:

>> When the index goes backwards in the table, the object should write
>> backwards, like [poke~] does. In my view, the object should always
>> overwrite samples, like [poke~] again. I did my sound-on-sound looper
>> with [poke~] and [tabread4~], a mix can be done externally. (see
>> http://puredata.hurleur.com/sujet-5021-sound-sound-looper-clear-option).
> Consider the use case where one wants to use the table as a buffer and
> they write through it and loop back to the beginning of the table when
> it reaches the end. Let's say the table is 44100 samples long, and the
> index loops from 44087.3 to 2.1 to start writing the table again. Does
> it interpolate all the intervening samples BACK through the table, or
> does it interpolate the 14 or so samples FORWARD through the loop? Or
> neither? These are all possibilities.

You're right, there should be a user-settable loop size (which is not
by necessity identical to table size) and if the forward or backward
interval is equal or larger than loop size, a wrap is done. But wait:
if the check is done anyway, it could as well be (a)bused to set an
upper bound to upsampling....

> As far as mixing vs. overwriting is concerned, that actually depends
> on what it's trying to model. Overwriting is probably right for a
> looper, but mixing is right for a recording of a moving sound source -
> and because [poke~] doesn't interpolate it's not an issue (it wouldn't
> be useful to model a moving sound source).

But 'approach B' condenses 4 read samples into 1 write sample, so
basically it does the same as [poke]: writing one sample at a time.
There is no need for mixing internally. If you want to mix, it can be
done externally. In my view, a Pd object need not internalize
functions that can be done externally, unless there is a huge
performance penalty involved.

> Note that "approach A" depends on mixing to work because the
> interpolation would need to be the emergent result of having mixed
> kernels into the table. "Overwriting" would defeat the purpose
> entirely.

Yes, with 'approach A' mixing is essential, as the tails of the
kernels must overlap. Then you get the amplitude effect. It is a
completely different model, and maybe these models each have their own
field of application.

>> I like the name [tabwrite4~]. Every Pd user is (or will be) familiar
>> with [tabwrite~] already, and [tabwrite4~] will be used in combination
>> with [tabread4~], nothing could be more logical.
> I think I agree -- the only problem is that we have different analogies.
> Consider all of the following:
> [tabread] : [tabread4] (control, with or without interpolation)
> [tabread4] : [tabread4~] (interpolating, one control and one for signals)
> [tabwrite] : [poke~] (write at an index using control or signal)
> [tabwrite~] : [tabplay~] (record a signal to a table, or play a signal
> from a table)
> [tabread4~] : [tabwrite4~] (read or write samples at specific index
> from/to a table with interpolation)
> [tabwrite~] : [tabwrite4~] (write samples to a table at specific index
> to a table, with or without interpolation) -- wait, that's not what
> tabwrite~ does! [tabwrite~] could have been maybe better named
> [tabrecord~]. [tabwrite] and [poke~] are the analogous objects, so one
> could make a case for calling it [poke4~] (does the same thing as
> [poke~] but with interpolation, in the Pd nomenclature).
> Or maybe [tabwrite4~] would imply to some people that you don't
> control it with indices, but with an up- or downsampling factor.
> I think [tabwrite4~] is the best name for what we've been talking
> about, but the asymmetry with the names of other objects gives me
> pause.

Yeah [poke4~] is apt for a 4 point interpolating signal write object
with index control.

> OK, onto the next flight!

Have a good trip!


More information about the Pd-list mailing list