2017-02-22 13:33 GMT-03:00 IOhannes m zmoelnig <zmoelnig@iem.at>:

On 2017-02-22 17:11, Alexandre Torres Porres wrote:
> good, bit depth is important too, I could add file extension to the list

whatever features you want to extract, i suggest to not use a specific
outlet for each, but instead add a 2 info-outlet that outputs key/value
pairs that are easily routable.

isn't the file-extension input data?

yes, still find it useful, specially for input from openpanel, but I see might be pushing here...

2017-02-22 9:22 GMT-03:00 Ed Kelly via Pd-list <pd-list@lists.iem.at>:

2) Sample rate is secondary, and any file recorded at a particular sample rate can be played back at any other rate, but it would be nice to know this, but it is negotiable within the patch.

I don't see it as "negotiable", it's quite important. Yes they can be played at any other sample rate, but that changes de reading speed/pitch, and what if you wanna have control over that? Say you opened a file recorded at 96Khz and you wanna play it at the sample rate that Pd is running which is 44.1Khz. For now, you basically need to know this information before hand.

3) Bit rate - perhaps for saving this might be useful

That's the usefulness I saw in it, and would also help in improving my buffer~ abstraction.

Thoughts?
Ed

I, for one, would like to negotiate the inclusion of as many information as possible, as you may notice, but I know not everyone feels like that and this is quite unlikely. I could be reasonably satisfied with channels and SR info, I'll surely have a smile on my face when that happens...

and since we are talking about externals doing that job, cyclone could have an [info~] object that spits out a LOT of information about a sample... the problem is that it's tied to [buffer~]

https://docs.cycling74.com/max7/maxobject/info~

cheers