[PD] getting sample rate of file loaded into an array

[Jonathan Wilkes]

----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: pd-list at 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 at 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&group_id=55736
>>> 
>>>>   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:
> 
> 1. 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
> 
> 2. 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>