----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, October 4, 2012 10:44 AM Subject: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
Hi all
The thread below makes me curious about what people think about the support of two or more several implementations of the similar functionality.
There are a few such cases:
- [ext13/wavinfo] vs. [iemlib/soundfile_info]
- OSCx vs. mrpeach's osc library
- arraysize vs.[expr size("array-name")] (which could be turned
easily into an abstraction)
There are certainly more similar examples. Is that a good or a bad thing?
Inarguably there is a cost to the user of multiple developers solving the same problem in a way that creates two or more externals that do essentially the same thing. There is a further cost to the users of these externals having different interfaces, which is the vast majority of the cases I've run into when revising help patches for externals. There is another cost to both developers and users when all these externals are packaged together (or separately) without regard for the costs above or documentation that guides the user to choose the least buggy/most featureful/expressive/etc. external in these cases. (And please note I'm talking about externals that are essentially the same, _not_ externals that approach a broad problem or domain from different perspective or design philosophy.) There is a benefit to _developers_ of having a system where there is essentially zero pressure in the community for them to work together to at least create a common interface when adding functionality to Pd through externals. (The one exception is outputting messages received at the same logical time in right-to-left order which seems to be obeyed by every external I've seen, even though it's possible not to follow that design.) Other than asking for svn commit permissions there is really no barrier to entry. There is probably also a cost to developers of not having something like a "contributors guide" that specifies at least something about the purpose of committing an external library to svn, not to mention the fact that pre-Pd-extended libs very often seemed to have been simply a place for some Pd users to remotely store a directory of utilities that they built for their own personal use without much thought about designing them to be generally useful or approachable by others.
Do you rather find it annoying when you find two or more implementations for the same thing or do you consider it a question of choice: more is better?
If the two externals do _exactly_ the same thing but have a different name the annoyance to the user is that they waste time asking on the list (or figuring out on their own) that there is redundancy in Pd that provides no benefit to them. If one external is preferable to the other but this is not clearly documented, then the annoyance is compounded, and possibly the user suffers from using the less well-designed external before finding out about the better one. If both externals have excellent documentation that clearly explains the benefits of one over the other the annoyance is the time it takes the user to read the documentation. Also, if neither external is stable then the user also suffers from less quality than they would have gotten if the developers of each had instead focused their efforts into one solution with more eyes, more tests, and more bug fixes.
Is it possible at all to make generalizations about that? Is it the lesser of two evils to keep each implementation for the sake of backwards compatibility or is it preferable to focus on one single (best working) implementation and get rid of the rest (which breaks compatibility, of course)?
It is preferable to focus on one single best working implementation where possible, but that doesn't imply that you need to get rid of redundant implementations. For me it means telling people to focus on the best implementation and make them explain why an inferior implementation that necessarily limits which versions of Pd the user's patch will run on by default should drain any developer resources whatsoever.
My personal stance on the issue: I don't remember all cases, but in the case of [wavinfo] vs. [soundfile_info] I spent a lot of time figuring out which works for which files.
Exactly-- the developers' gain from not having to devote energy to researching extant solutions and possibly working together is your loss as a user.
Also, I wanted to know which is mature enough so that it's worth to write bug reports to its author. This consumes quite some time and I think everyone who discovers that there are many solutions for her problem needs to invest some time to find out which works best. Personally, I think this is lost time, because not only it needs twice as much time to implement the same thing twice, every user needs to figure out the small differences. Well aware, that this (my) opinion is likely not applicable to others, I tend to think that patches are too much treated like holy cows whose breaking should be avoided by any means. If it turns out, that my patches use an inferior of concurrent implementations, I'd be happy to switch them to the new class, especially if it helps to keep the future clean.
Advocate for the superior external, write crystal clear documentation for it, and write crystal clear documentation for the inferior one to explain why to use the other one. Then get the authors to accept your doc changes (or doc creation as the case may be). That's the only way to ensure that your lost time doesn't become other users' lost time. I'll give you an example later when I update the arraysize help patch. -Jonathan
My two cents
Roman
On Thu, 2012-10-04 at 15:49 +0200, Roman Haefeli wrote:
Hi Patrice and Rick
Unfortunately, there are several different types of wav files, also the header size is not always the same.
IIRC, [ext13/wavinfo] assumes a fixed size of the typical 44 byte header and probably because of other reasons as well does not recognize many real-world wav-files. Sometimes it gives totally strange numbers instead of reporting an error.
[iemlib/soundfile_info] seems to support a much wider range of wav-files around and also I reported once a bug and it got fixed.
For reasons above I encourage you to use [iemlib/soundfile_info].
Roman
On Wed, 2012-10-03 at 14:09 -1000, Rick T wrote:
Thanks
On Wed, Oct 3, 2012 at 1:45 PM, Patrice Colet
wrote: [ext13/wavinfo] or more complicated for the fun, with [mrpeach/binfile] and https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ it's attached ^^ Colet Patrice ----- Mail original ----- > De: "Rick T" ratulloch@gmail.com > À: "PD List" pd-list@iem.at > Envoyé: Jeudi 4 Octobre 2012 00:26:15 > Objet: [PD] getting sample rate of file loaded into an
array
> > > Greetings All > > I load a wavefile into an array using openpanel but how
can
I go > about getting the sample rate of the wav file? > > I'm trying to load the sample rate data into an expr
object
> Example: expr (sample rate) / f$1 > > Aloh > Rick > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list