Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
- Original Message - > From: Roman Haefeli > To: "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)
> De: "IOhannes m zmölnig" > 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)
>> 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)
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)
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)
- Original Message -
> From: Roman Haefeli
> 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 th
Re: [PD] opinions on the issue of concurrent implementations (was: getting sample rate of file loaded into an array)
> De: "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.
>
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
[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? 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
> > 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"
> > > À: "PD List"
> > > 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
