On Sat, Jun 16, 2012 at 7:16 PM, Matt Barber brbrofsvl@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!
Katja