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