Wait - this is embarrassing, it seems that the left outlet still spits out the 
number of samples when there are no destination arrays so I should be golden…

I probably need a weekend. Sorry for the Friday night noise.

> On 28 Jan 2022, at 19:35, Miller Puckette <m...@ucsd.edu> wrote:
> 
> Yep, I can think of other reasons you'd want to know the size of a soundfile
> in a Pd patch without having to read the whole thing in.
> 
> cheers
> M
> 
> On Fri, Jan 28, 2022 at 07:32:02PM +0000, Pierre Alexandre Tremblay wrote:
>>> I forgot is even simpler (no need for an array)
>> 
>> Oh la la this is embarrassing. I didn’t know one could not supply an array… 
>> but that way I don’t get the size of the file in frames.
>> 
>>> Are you doing stuff that "soundfiler" doesn't?  If so, it would be better 
>>> to add to the soundfiler object than to add a new object with its own name.
>> 
>> 
>> Indeed Miller I’ll do a PR to add it at the end then. I get everything else 
>> with soundfiler
>> 
>> For info, I need the size of the sum of my sound files in frames and in 
>> channels to allocate the right size once. I do that in Max and SC doing 2 
>> passes, once to read the headers and accumulate what I need in both 
>> dimensions (and capture the SR at the same time) then I assign then I read 
>> and copy. For large corpora, this is useful.
>> 
>> So the proposal is not so big and bold as my first email… but still a needed 
>> feature.
> 
> 
> 
>> _______________________________________________
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to