[PD] ipoke~ ?

[katja]

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

> The user-settable bound would just be in how they decided to use it.
> Think of it like [until] -- there's no reason to make the user set an
> upper iteration bound - the user does that just by using it in a way
> that doesn't crash Pd (and some until loops are more expensive than
> others).

Maybe you're right. Though [tabwrite4~] would be more complicated to
handle than [until], user-tests will indicate wether a 'safety belt'
would be desired, it is not a prerequisite for the object's
functioning.

> The main thing I see wrong with what we've been calling "approach B"
> is that there isn't a good policy for what to do when 1) the index
> goes backwards in the table, and 2) what to do when the table already
> has info in it. One could have settable "interpolate on backwards
> jump" (default should probably be no) and settable "mix new samples
> with what's there, or overwrite them."

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).

> Now, if we move forward, we need think about what to name it.
> [tabwrite~] currently does something that maybe should have been
> called [tabrecord~], so the [tabwrite4~] name is maybe a little
> misleading. The delay version could be called [vdw~] -- it would take
> two signals in and output one signal (there's no reason for it to
> maintain a multitap-able delay buffer because all the relevant work is
> done on the write end, so if you need multiple read taps you can just
> feed it into a [delwrite~] further down).

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.

> For various reasons I think what we've been calling approach A --
> writing a filter kernel into the buffer for every sample is better for
> the delay version than approach B, but I can't get into it right now
> as I'm about to board a plane!
>
> Matt

I'm about to leave for a 3 week holiday, computers will stay home!
(I'm almost tempted to smuggle one in my luggage and write the class
in my tent, Pd addict I am).

Katja