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

Patrice Colet colet.patrice at free.fr
Thu Oct 4 17:04:57 CEST 2012



> De: "Roman Haefeli" <reduzent at gmail.com>
> 
> 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.
> 
Hi Roman,

 I think that it's better when we can modify the behavior of an object by modifying a pd patch.
When everything is enclosed into an external, somehow it's private, and then it's not really pd anymore.
 More people are able to debug a pd patch, anyone could fix the problem without compiling anything.

 We should use C language only when we need it, in the example of [waveinfo] vs [soundfile_info], both aren't the good way for me,
we just need the [binfile] external for reading the header, and all the other stuff can be done into a pd patch.

my one cent



More information about the Pd-list mailing list