Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
- Original Message - From: Roman Haefeli reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
De: IOhannes m zmölnig zmoel...@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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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. Thanks for your thoughts. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
De: Roman Haefeli reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
- Original Message - From: Roman Haefeli reduz...@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
