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