[PD] better tabread4~

[Hans-Christoph Steiner]

On Jun 24, 2008, at 8:22 AM, Matt Barber wrote:

> ====================================================================
> 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.

Yes, definitely, that's why I don't think "4c" really says much about  
what it does or what it is for.

.hc


> 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




------------------------------------------------------------------------ 
----

                             kill your television