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
Aloha Rick
[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
Aloha Rick
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
Aloha Rick
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
Thank you roman, didn't try this one...
I'd like to know what was the bug because it gives wrong sample resolution
Colet Patrice
----- Mail original -----
De: "Roman Haefeli" reduzent@gmail.com À: pd-list@iem.at Envoyé: Jeudi 4 Octobre 2012 15:49:25 Objet: Re: [PD] getting sample rate of file loaded into an array
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2012-10-04 at 16:23 +0200, Patrice Colet wrote:
Thank you roman, didn't try this one...
I'd like to know what was the bug
http://sourceforge.net/tracker/?func=detail&atid=478070&aid=2950978&...
because it gives wrong sample resolution
Didn't know about this one. Please report it, so that hopefully it gets fixed. Does it work correctly with [ext13/wavinfo]?
Roman
----- Mail original -----
De: "Roman Haefeli" reduzent@gmail.com À: pd-list@iem.at Envoyé: Jeudi 4 Octobre 2012 15:49:25 Objet: Re: [PD] getting sample rate of file loaded into an array
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
De: "Roman Haefeli" reduzent@gmail.com
On Thu, 2012-10-04 at 16:23 +0200, Patrice Colet wrote:
Thank you roman, didn't try this one...
I'd like to know what was the bug
http://sourceforge.net/tracker/?func=detail&atid=478070&aid=2950978&...
because it gives wrong sample resolution
Didn't know about this one. Please report it, so that hopefully it gets fixed. Does it work correctly with [ext13/wavinfo]?
Yes it does,
but anyway, my bad, I didn't read carefuly enough the help file that is saying sample resolution in *bytes*, not in *bits*.
maybe one day [soundfile_info] will read aiff files as well...
On 10/04/2012 11:27 AM, Patrice Colet wrote:
De: "Roman Haefeli" reduzent@gmail.com
On Thu, 2012-10-04 at 16:23 +0200, Patrice Colet wrote:
Thank you roman, didn't try this one...
I'd like to know what was the bug
http://sourceforge.net/tracker/?func=detail&atid=478070&aid=2950978&...
because it gives wrong sample resolution
Didn't know about this one. Please report it, so that hopefully it gets fixed. Does it work correctly with [ext13/wavinfo]?
Yes it does,
but anyway, my bad, I didn't read carefuly enough the help file that is saying sample resolution in *bytes*, not in *bits*.
maybe one day [soundfile_info] will read aiff files as well...
There are two separate issues here:
- it would be lovely to have a single [soundfile_info] that gets the
meta data from any soundfile, like how [readanysf~] will play any soundfile
- People should be free to write whatever software they want. If
existing objects don't work for them, they write new ones. Therefore we have [wavinfo] and [soundfile_info].
So really, I think the best solution would be to leave both [wavinfo] and [soundfile_info] as they are, and focus efforts on making a [anysfinfo] based on gmerlin using [readanysf~] as a template.
.hc
On Thu, 2012-10-04 at 12:05 -0400, Hans-Christoph Steiner wrote:
On 10/04/2012 11:27 AM, Patrice Colet wrote:
De: "Roman Haefeli" reduzent@gmail.com
On Thu, 2012-10-04 at 16:23 +0200, Patrice Colet wrote:
Thank you roman, didn't try this one...
I'd like to know what was the bug
http://sourceforge.net/tracker/?func=detail&atid=478070&aid=2950978&...
because it gives wrong sample resolution
Didn't know about this one. Please report it, so that hopefully it gets fixed. Does it work correctly with [ext13/wavinfo]?
Yes it does,
but anyway, my bad, I didn't read carefuly enough the help file that is saying sample resolution in *bytes*, not in *bits*.
maybe one day [soundfile_info] will read aiff files as well...
There are two separate issues here:
- it would be lovely to have a single [soundfile_info] that gets the
meta data from any soundfile, like how [readanysf~] will play any soundfile
Agreed.
- People should be free to write whatever software they want. If
existing objects don't work for them, they write new ones. Therefore we have [wavinfo] and [soundfile_info].
That is someone speaking from a developers point of view. Of course, it seems feasible to write your own class, if you have the abilities. However, it (IMHO, at least) creates major pains for future users, as they have to deal with the specifics of every class. I, as a receiver of patches from others, might have to several implementations installed, because the patch authors decided to use different advantages in this. I'm all for freedom of the developers - don't get me wrong, but I think some mechanism to "forget" stuff that does not seem to proof useful is crucial. Otherwise we end up with a whole lot of half-working cruft in the future. In my opinion, it is already the case now: so many libraries that are not maintained anymore or which are broken in one way or the other. It all boils down: How to get rid of stuff? Certainly not by packaging everything into Pd-extended and saying we cannot remove stuff because of backwards compatibility. This is not at all a rant. But I'm convinced we will need to figure this out at some point in the future.
Probably this analogy is way off, but I think it is not unlike the issue with space debris in low earth orbit. The later you think about that, the more expensive it is going to be to deal with it.
So really, I think the best solution would be to leave both [wavinfo] and [soundfile_info] as they are, and focus efforts on making a [anysfinfo] based on gmerlin using [readanysf~] as a template.
Actually, I think [readanysf~] could do it. It already provides information about length of the audio file and its original samplerate. However, there are some pieces missing like number of channels.
Roman
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Thursday, October 4, 2012 12:05 PM Subject: Re: [PD] getting sample rate of file loaded into an array
On 10/04/2012 11:27 AM, Patrice Colet wrote:
De: "Roman Haefeli" reduzent@gmail.com
On Thu, 2012-10-04 at 16:23 +0200, Patrice Colet wrote:
Thank you roman, didn't try this one...
I'd like to know what was the bug
http://sourceforge.net/tracker/?func=detail&atid=478070&aid=2950978&...
because it gives wrong sample resolution
Didn't know about this one. Please report it, so that hopefully it gets fixed. Does it work correctly with [ext13/wavinfo]?
Yes it does,
but anyway, my bad, I didn't read carefuly enough the help file that is
saying sample resolution in *bytes*, not in *bits*.
maybe one day [soundfile_info] will read aiff files as well...
There are two separate issues here:
- it would be lovely to have a single [soundfile_info] that gets the
meta data from any soundfile, like how [readanysf~] will play any soundfile
- People should be free to write whatever software they want. If
existing objects don't work for them, they write new ones. Therefore we have [wavinfo] and [soundfile_info].
So really, I think the best solution would be to leave both [wavinfo] and [soundfile_info] as they are, and focus efforts on making a [anysfinfo] based on gmerlin using [readanysf~] as a template.
Part of those efforts should include updating the old external docs to point users to the newer, better external once it reaches some level of stability. Since it's impossible for the devs of the existing objects to poll svn for newer, better objects, this is the responsibility of the developer of the newer, better objects. Again-- this is only black-and-white for situations where the new external inherits the same essential features as the old external and any of its new features don't introduce any significant drawbacks for a potential user. If the new external writes to a text file in JSON format instead of outputting messages from an outlet that's a different story. -Jonathan
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
De: "Roman Haefeli" reduzent@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
On 10/04/2012 05:04 PM, Patrice Colet wrote:
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.
we don't need [binfile]!
Pd is proven to be turing complete, so it should be easy enough to write an operating system entirely in Pd (that is: a patch) that will allow you to read/write soundfiles in any desired format.
mgdasr IOhannes
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.
we don't need [binfile]!
Pd is proven to be turing complete, so it should be easy enough to write an operating system entirely in Pd (that is: a patch) that will allow you to read/write soundfiles in any desired format.
mgdasr IOhannes
True, but looking outside of the scope of audio for a second... A student of mine did a project based on microwave background radiation measurements taken from radio telescopes, in order to deal with data that was truly random in some way (I'm skipping a debate about the randomness or otherwise in cosmological terms, the big bang etc.) He accessed binary files to generate points. Admittedly this was in Processing, but the ability to deal with any binary data and decode it on an ad-hoc basis was essential for this project to work.
The point I am trying to make is that Pd should be able to read and write any file, with interpretation of the data implemented on an ad-hoc basis. In this way, mrpeach/binfile is incredibly useful. Obviously non-audio files will mostly generate noise if played back as audio, but Pd provides so many other ways in which data can be sonified, visualized etc...
Ed
On 10/06/2012 12:25 PM, Ed Kelly wrote:
True, but looking outside of the scope of audio for a second...
my point was, that there is a reason for specialized objects, even if they are written in an obscure compiled language like C.
i wouldn't want to do anything requiring low latencies (like audio) with PdOS.
The point I am trying to make is that Pd should be able to read and write any file, with interpretation of the data implemented on an ad-hoc basis. In this way, mrpeach/binfile is incredibly useful. Obviously non-audio files will mostly generate noise if played back as audio, but Pd provides so many other ways in which data can be sonified, visualized etc...
[binfile] has many uses, and i'm very glad that it is there. e.g. the [srtfile] object i mentioned in the other thread ("[text3d] & video subtitling in Pd") is really a Pd-patch around [binfile].
there is still little merit in implementing [mp3write~] as patch, besides pedagogy and ego-boosty.
mfgasrd IOhannes
De: "IOhannes m zmölnig" zmoelnig@iem.at On 10/04/2012 05:04 PM, Patrice Colet wrote:
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.
we don't need [binfile]!
how do you read the header without binfile?
Pd is proven to be turing complete, so it should be easy enough to write an operating system entirely in Pd (that is: a patch) that will allow you to read/write soundfiles in any desired format.
pd is not even able to read extended precision, that's why pd can't tell about aiff samplerate.
From: Patrice Colet colet.patrice@free.fr To: pd-list pd-list@iem.at Cc: IOhannes m zmölnig zmoelnig@iem.at Sent: Saturday, October 6, 2012 10:41 AM Subject: Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
De: "IOhannes m zmölnig" zmoelnig@iem.at On 10/04/2012 05:04 PM, Patrice Colet wrote:
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.
we don't need [binfile]!
how do you read the header without binfile?
I don't know a way without externals. Anyway, I think you're being trolled. -Jonathan
Pd is proven to be turing complete, so it should be easy enough to write an operating system entirely in Pd (that is: a patch) that will allow you to read/write soundfiles in any desired format.
pd is not even able to read extended precision, that's why pd can't tell about aiff samplerate.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 10/06/2012 06:16 PM, Jonathan Wilkes wrote:
Anyway, I think you're being trolled.
my answer was definitely not too serious.
my point remains, that if you still want to do realtime processing, you might be better of with specialized objects written in a compiled language.
fgmarsd IOhannes
----- 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
On Thu, 2012-10-04 at 13:16 -0700, Jonathan Wilkes wrote: [...]
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.
You are right. I agree with you that this is probably the best (most pragmatic / most realistic) way to have an influence as a non-ext-dev on the issue.
I'll give you an example later when I update the arraysize help patch.
I'll happily check it, when it is ready.
Thanks for your thoughts. Roman
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: "pd-list@iem.at" pd-list@iem.at Cc: Sent: Friday, October 5, 2012 3:15 AM Subject: Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
On Thu, 2012-10-04 at 13:16 -0700, Jonathan Wilkes wrote: [...]
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.
You are right. I agree with you that this is probably the best (most pragmatic / most realistic) way to have an influence as a non-ext-dev on the issue.
I'll give you an example later when I update the arraysize help patch.
I'll happily check it, when it is ready.
Ok, I updated arraysize-help.pd in svn.
Still not sure how to get expr to point to the revised PDDP docs instead of the old docs.
-Jonathan
Thanks for your thoughts. Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Ed Kelly -
Hans-Christoph Steiner -
IOhannes m zmölnig -
Jonathan Wilkes -
Patrice Colet -
Rick T -
Roman Haefeli