On Sat, Jun 16, 2012 at 7:16 PM, Matt Barber <brbrof...@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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list