[PD] ipoke~ ?
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
> 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
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
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