[PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
Jonathan Wilkes
jancsika at yahoo.com
Thu Oct 4 22:16:07 CEST 2012
----- Original Message -----
> From: Roman Haefeli <reduzent at gmail.com>
> To: pd-list at 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
> <colet.patrice at free.fr>
>> > 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 at gmail.com>
>> > > À: "PD List" <pd-list at 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 at iem.at mailing list
>> > > UNSUBSCRIBE and account-management ->
>> > > http://lists.puredata.info/listinfo/pd-list
>> > >
>> >
>> > _______________________________________________
>> > Pd-list at iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list