==================================================================== Hans-Christoph Steiner hans@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:
- [tabread4~] has several other important applications (e.g.
waveshaping), where the "tweak" and "transpose" appendages would have little relevance.
- 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.
- 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