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