On Sat, Jun 16, 2012 at 12:03 PM, katja katjavetter@gmail.com wrote:
On Sat, Jun 16, 2012 at 5:01 PM, Matt Barber brbrofsvl@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).
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.
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).
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.
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.
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.
OK, onto the next flight!