[PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)

[Roman Haefeli]

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? 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? 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)?

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

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