==================================================================== 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
Hallo, Matt Barber hat gesagt: // Matt Barber wrote:
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.
Though I would rather avoid the terms "sampler" or "sampling", as "sample" already has so many different meanings in the audio world, it almost lost all usefulness.
Ciao
Frank Barknecht _ ______footils.org__
On Jun 24, 2008, at 8:22 AM, Matt Barber wrote:
==================================================================== 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.
Yes, definitely, that's why I don't think "4c" really says much about
what it does or what it is for.
.hc
- 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
On Tue, 24 Jun 2008, Matt Barber wrote:
[tabread_tweak~] [tabread_transpose~]
I really hate to be a fart on this one
You should love it, if you intend it for the good of pd.
- I tend to greatly prefer object names which say what the object
"does," not what it is "for,"
This is one of the major points of the DIY movement.
I'm sure that there are men who buy themselves «bikini line trimmers» in pink boxes labelled «designed exclusively for women» just so that they can have more precision tailoring themselves a chin pinch, and this doesn't have anything to do with being gay or effeminate, though the peer pressure wouldn't miss making that kind of allusion or another of the same level. Some other people would use the same bikini line trimmer to perform intricate pruning on bonsaï trees.
(doesn't anyone feel embarrassed that someone talks about a bikini line trimmer on pd-list? does it make me pervert, gay, or just oblivious to social customs? doesn't that exactly prove our point? consider the object for what it can do.)
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.
I'd say that beyond "what it does" and "what it's for", there is also "what it's marketed as" or "what you will be told that it's for", which might be the same as "what it's for", but modified and specialised to make it more obviously relevant to people's life.
A major schism in the pd world is how GEM/PDP feel somewhat more "what it's for" than pd itself, whereas GF and pd are more "what it does". This is about both the naming and how an object's multipurposeness is only multiple ways of thinking about what is the single thing that the object does, rather than have multipurposeness correspond to multiple behaviours defined separately, each matching a single "what it's for".
This is a gross generalisation. There are definitely GEM/PDP classes that were designed in a "what it does" way, and GF classes that are definitely "what it's for" in style, but when asking yourself the question of why something is different in GF than in [pix_...], that kind of difference is often the most important difference.
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).
I consider [lop~] to be on essentially the same level as [rpole~], really. [rpole~] is simply a different kind of building block that appeals more to people who work in terms of so-called «transfer functions».
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Matt Barber