[PD] better tabread4~

[Matt Barber]

====================================================================
Hans-Christoph Steiner <hans at eds.org> wrote:
>> Yes that'right, hmm I guess I knew that but said it in a woolly way
>>
>> Amend that to
>>
>> [tabread~] - "play back at exactly" the original rate
>> [tabread4~] - "play back at close to the orginal rate"
>> [tabread4c~] - "play back with wider transposition"
>
>>
>
> Perhaps these could have more descriptive names, especially if there
> was a "tabread", etc. library.  Some quick ideas:
>
> [tabread_tweak~]
> [tabread_transpose~]
>
> .hc
>



I really hate to be a fart on this one, but I'm sorry to say I don't
like this scheme at all.  This implies that the tabread classes are
only used for sampling.  I understand that probably 95% of their use
is for sampling, and that for a majority of users the more descriptive
names might be helpful in that context, but I really feel bad about it
for a number of reasons aside from the "real estate" arguments in
other posts:

1)  [tabread4~] has several other important applications (e.g.
waveshaping), where the "tweak" and "transpose" appendages would have
little relevance.

2)  I tend to greatly prefer object names which say what the object
"does," not what it is "for," especially with rather low-level
objects.  IMO, the latter labeling tends to constrain one's thinking
about the use of an object in a way that the former does not.

3)  In pedagogical situations I dislike "black box" objects which hide
too much of the implementation.  This probably wouldn't be the case
with these objects, but it feels like it's leaning too far in that
direction.  One could argue that those who want to really know what's
going on would have to page through the documentation just as much as
someone who just wants things to work in the easiest way.  I very much
understand the need to get things done, however, and I am sensitive to
the balance between having a substantial set of ready-to-use tools
that you don't have to build, and the set of tools you would want to
restrict yourself to if you were trying to learn the fundamentals of
DSP and program flow.  I think that vanilla Pd's leanness and
explicitness make it an ideal teaching tool, but extended might better
make Pd a production tool... however I don't think you would introduce
descriptive names like this into vanilla, and especially into
something as low-level as a table reader.

All of that said, I think something like the [sampler~] object
proposed in another post would be much in keeping with the
"user-friendly" filter objects like [bp~] (as opposed to [rpole~] and
[rzero~] which are the real "building block" kinds of filter classes).
 An object name like [sampler~] would indeed restrict its relevance to
sampling, and the automatic interpolation schemes would support this
restriction... such a thing might be useful in readsf~ contexts as
well.


Thanks,

Matt