Re: [PD] [sfinfo~]
Tested on Windows. Works fantastic. thanks! Mensaje telepatico asistido por maquinas. On 1/28/2022 8:29 PM, Dan Wilcox wrote: Ok, here is a fix. Please test: https://github.com/pure-data/pure-data/pull/1566 On Jan 28, 2022, at 11:04 PM, Dan Wilcox wrote: It's a bug, the failure is here: https://github.com/pure-data/pure-data/blob/master/src/d_soundfile.c#L1307 The intent as previously stated is that not supplying a table name should use the value read from the header. However, for raw files there is no header so we *have* to try reading the length of the file. This logic is not working and I will try to fix it now. Previously, I had a an "info" message which did this separately from "read" when I was overhauling sound file handling, but Miller's suggestion to check for the array name was more elegant. On Jan 28, 2022, at 9:55 PM, pd-list-requ...@lists.iem.at wrote: Message: 3 Date: Fri, 28 Jan 2022 20:55:43 + From: Pierre Alexandre Tremblay To: Lucas Cordiviola Cc:pd-list@lists.iem.at Subject: Re: [PD] [sfinfo~] Message-ID: Content-Type: text/plain; charset="utf-8" In d_soundfile.c around line 1207 we could see if there is only 1 arg left as a else if. If that?s the case, we could just bail down to done: and bob?s your uncle... Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
Ok, here is a fix. Please test: https://github.com/pure-data/pure-data/pull/1566 <https://github.com/pure-data/pure-data/pull/1566> > On Jan 28, 2022, at 11:04 PM, Dan Wilcox wrote: > > It's a bug, the failure is here: > https://github.com/pure-data/pure-data/blob/master/src/d_soundfile.c#L1307 > <https://github.com/pure-data/pure-data/blob/master/src/d_soundfile.c#L1307> > > The intent as previously stated is that not supplying a table name should use > the value read from the header. However, for raw files there is no header so > we *have* to try reading the length of the file. This logic is not working > and I will try to fix it now. > > Previously, I had a an "info" message which did this separately from "read" > when I was overhauling sound file handling, but Miller's suggestion to check > for the array name was more elegant. > >> On Jan 28, 2022, at 9:55 PM, pd-list-requ...@lists.iem.at >> <mailto:pd-list-requ...@lists.iem.at> wrote: >> >> Message: 3 >> Date: Fri, 28 Jan 2022 20:55:43 + >> From: Pierre Alexandre Tremblay > <mailto:tremb...@gmail.com>> >> To: Lucas Cordiviola mailto:lucard...@hotmail.com>> >> Cc: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> >> Subject: Re: [PD] [sfinfo~] >> Message-ID: > <mailto:ad2ab664-9f51-478e-b643-706bc254d...@gmail.com>> >> Content-Type: text/plain; charset="utf-8" >> >> In d_soundfile.c around line 1207 we could see if there is only 1 arg left >> as a else if. If that?s the case, we could just bail down to done: and bob?s >> your uncle... > > > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
It's a bug, the failure is here: https://github.com/pure-data/pure-data/blob/master/src/d_soundfile.c#L1307 <https://github.com/pure-data/pure-data/blob/master/src/d_soundfile.c#L1307> The intent as previously stated is that not supplying a table name should use the value read from the header. However, for raw files there is no header so we *have* to try reading the length of the file. This logic is not working and I will try to fix it now. Previously, I had a an "info" message which did this separately from "read" when I was overhauling sound file handling, but Miller's suggestion to check for the array name was more elegant. > On Jan 28, 2022, at 9:55 PM, pd-list-requ...@lists.iem.at wrote: > > Message: 3 > Date: Fri, 28 Jan 2022 20:55:43 + > From: Pierre Alexandre Tremblay <mailto:tremb...@gmail.com>> > To: Lucas Cordiviola mailto:lucard...@hotmail.com>> > Cc: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] [sfinfo~] > Message-ID: <mailto:ad2ab664-9f51-478e-b643-706bc254d...@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > In d_soundfile.c around line 1207 we could see if there is only 1 arg left as > a else if. If that?s the case, we could just bail down to done: and bob?s > your uncle... Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
In d_soundfile.c around line 1207 we could see if there is only 1 arg left as a else if. If that’s the case, we could just bail down to done: and bob’s your uncle... > On 28 Jan 2022, at 20:30, Lucas Cordiviola wrote: > > @Oliver > > The only problem I know with [soundfile_info] is that it counts as samples > any metadata in the file. Is not common to find metadata in wav files but > there might be some. > > It would be really nice if [soundfiler] just extracts n of samples only by > reading the header. > > @Dan: > > Oliver's patch shows that [soundfiler] does not just "read the header". > > > > -- > > Mensaje telepatico asistido por maquinas. > > On 1/28/2022 5:19 PM, Dan Wilcox wrote: >> Don't pass an array name when calling open and it reports the info without >> reading any samples, ie. just reads the header info then closes the file. >> >>> On Jan 28, 2022, at 8:37 PM, pd-list-requ...@lists.iem.at wrote: >>> >>> Message: 1 >>> Date: Fri, 28 Jan 2022 20:29:44 +0100 >>> From: oliver >>> Cc: Pd-List >>> Subject: Re: [PD] [sfinfo~] >>> Message-ID: <32ea001b-5109-cb72-2397-cb820d930...@klingt.org> >>> Content-Type: text/plain; charset=UTF-8; format=flowed >>> >>> Miller Puckette via Pd-list wrote: >>>> Hi PA - >>>> >>>> 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. >>> >>> The one thing that [soundfiler] can not do, is to report the length of a >>> soundfile WITHOUT fully loading it into an array. >>> >>> That would be a great feature to have for [soundfiler]'s right outlet, >>> especially in the case of big files. >>> >>> You can get all the other information (channels, samplerate etc.) by >>> loading just a small sniplet of the source file (even 1 sample is >>> sufficient IIRC) into a buffer, but not the length. you would need to >>> add "-resize" to the load flags, which is not useful for (very) long files >>> >>> i still use IEMLIB's [soundfile_info] for that purpose. >>> >>> >>> >>> best >>> >>> oliver >> >> >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika> >> danomatika.com <http://danomatika.com> >> robotcowboy.com <http://robotcowboy.com> >> >> >> >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list 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
Re: [PD] [sfinfo~]
@Oliver The only problem I know with [soundfile_info] is that it counts as samples any metadata in the file. Is not common to find metadata in wav files but there might be some. It would be really nice if [soundfiler] just extracts n of samples only by reading the header. @Dan: Oliver's patch shows that [soundfiler] does not just "read the header". -- Mensaje telepatico asistido por maquinas. On 1/28/2022 5:19 PM, Dan Wilcox wrote: Don't pass an array name when calling open and it reports the info without reading any samples, ie. just reads the header info then closes the file. On Jan 28, 2022, at 8:37 PM, pd-list-requ...@lists.iem.at wrote: Message: 1 Date: Fri, 28 Jan 2022 20:29:44 +0100 From: oliver Cc: Pd-List Subject: Re: [PD] [sfinfo~] Message-ID: <32ea001b-5109-cb72-2397-cb820d930...@klingt.org> Content-Type: text/plain; charset=UTF-8; format=flowed Miller Puckette via Pd-list wrote: Hi PA - 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. The one thing that [soundfiler] can not do, is to report the length of a soundfile WITHOUT fully loading it into an array. That would be a great feature to have for [soundfiler]'s right outlet, especially in the case of big files. You can get all the other information (channels, samplerate etc.) by loading just a small sniplet of the source file (even 1 sample is sufficient IIRC) into a buffer, but not the length. you would need to add "-resize" to the load flags, which is not useful for (very) long files i still use IEMLIB's [soundfile_info] for that purpose. best oliver Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
I chose a small file and could see how soundfile_info is faster (btw, why are you using -stdlib?) So, shall we open a feature request on github? Em sex., 28 de jan. de 2022 às 17:05, oliver escreveu: > Miller Puckette via Pd-list wrote: > > Excellent - nothing to do then. My favorite kind of dolist. > > > Well, not quite ... > > Lucas' method of using [soundfiler] to get a (really long) soundfile's > length still loads the complete file into RAM, as it would into an > array. (i'm talking a 60 minute long audio file here) > > This has 3 drawbacks: > > 1.) audio dropout while loading, depending on the file's length > 2.) can use huge amounts of RAM > 3.) takes much longer than [soundfile_info] > > attached is an example patch that illustrates both approaches. > > (use the same long soundfile for each method to see what i mean) > > > > then again: since i use IEMLIB regularly it's not that much of a hassle. > it's just not plain vanilla, that's all ... > > > best > > oliver > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
Ah, sorry, I meant "read" not "open." If calling read without an array takes the same amount of time as reading into an array, please open a bug report. > On Jan 28, 2022, at 9:19 PM, Dan Wilcox wrote: > > Don't pass an array name when calling open and it reports the info without > reading any samples, ie. just reads the header info then closes the file. > >> On Jan 28, 2022, at 8:37 PM, pd-list-requ...@lists.iem.at >> <mailto:pd-list-requ...@lists.iem.at> wrote: >> >> Message: 1 >> Date: Fri, 28 Jan 2022 20:29:44 +0100 >> From: oliver mailto:oli...@klingt.org>> >> Cc: Pd-List mailto:pd-list@lists.iem.at>> >> Subject: Re: [PD] [sfinfo~] >> Message-ID: <32ea001b-5109-cb72-2397-cb820d930...@klingt.org >> <mailto:32ea001b-5109-cb72-2397-cb820d930...@klingt.org>> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Miller Puckette via Pd-list wrote: >>> Hi PA - >>> >>> 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. >> >> The one thing that [soundfiler] can not do, is to report the length of a >> soundfile WITHOUT fully loading it into an array. >> >> That would be a great feature to have for [soundfiler]'s right outlet, >> especially in the case of big files. >> >> You can get all the other information (channels, samplerate etc.) by >> loading just a small sniplet of the source file (even 1 sample is >> sufficient IIRC) into a buffer, but not the length. you would need to >> add "-resize" to the load flags, which is not useful for (very) long files >> >> i still use IEMLIB's [soundfile_info] for that purpose. >> >> >> >> best >> >> oliver > > > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
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 +, 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
Don't pass an array name when calling open and it reports the info without reading any samples, ie. just reads the header info then closes the file. > On Jan 28, 2022, at 8:37 PM, pd-list-requ...@lists.iem.at wrote: > > Message: 1 > Date: Fri, 28 Jan 2022 20:29:44 +0100 > From: oliver mailto:oli...@klingt.org>> > Cc: Pd-List mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] [sfinfo~] > Message-ID: <32ea001b-5109-cb72-2397-cb820d930...@klingt.org > <mailto:32ea001b-5109-cb72-2397-cb820d930...@klingt.org>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Miller Puckette via Pd-list wrote: >> Hi PA - >> >> 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. > > The one thing that [soundfiler] can not do, is to report the length of a > soundfile WITHOUT fully loading it into an array. > > That would be a great feature to have for [soundfiler]'s right outlet, > especially in the case of big files. > > You can get all the other information (channels, samplerate etc.) by > loading just a small sniplet of the source file (even 1 sample is > sufficient IIRC) into a buffer, but not the length. you would need to > add "-resize" to the load flags, which is not useful for (very) long files > > i still use IEMLIB's [soundfile_info] for that purpose. > > > > best > > oliver Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
Miller Puckette via Pd-list wrote: Excellent - nothing to do then. My favorite kind of dolist. Well, not quite ... Lucas' method of using [soundfiler] to get a (really long) soundfile's length still loads the complete file into RAM, as it would into an array. (i'm talking a 60 minute long audio file here) This has 3 drawbacks: 1.) audio dropout while loading, depending on the file's length 2.) can use huge amounts of RAM 3.) takes much longer than [soundfile_info] attached is an example patch that illustrates both approaches. (use the same long soundfile for each method to see what i mean) then again: since i use IEMLIB regularly it's not that much of a hassle. it's just not plain vanilla, that's all ... best oliver #N canvas 806 80 350 355 10; #X declare -stdlib iemlib; #X obj 47 227 soundfiler; #X msg 196 205 read \$1; #X obj 196 161 openpanel; #X obj 196 138 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 19 16 declare -stdlib iemlib; #X obj 196 229 soundfile_info; #X obj 47 248 print A; #X obj 196 250 print B; #X obj 196 182 t s b; #X obj 281 14 osc~ 440; #X obj 281 35 *~ 0.2; #X obj 269 92 dac~; #X msg 47 205 read \$1; #X obj 47 161 openpanel; #X obj 47 139 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 47 182 t s b; #X text 45 104 select a long soundfile; #X obj 74 297 realtime; #X msg 119 276 bang; #X floatatom 74 318 0 0 0 0 - - -; #X obj 223 297 realtime; #X msg 268 276 bang; #X floatatom 223 318 0 0 0 0 - - -; #X obj 281 67 *~ 0; #X obj 253 37 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 68 137 A: ARRAY METHOD; #X text 214 137 A: WITH IEMLIB; #X text 195 15 also note audio drop-out, f 11; #X connect 0 0 6 0; #X connect 0 0 18 0; #X connect 1 0 5 0; #X connect 2 0 8 0; #X connect 3 0 2 0; #X connect 5 0 7 0; #X connect 5 0 21 0; #X connect 8 0 1 0; #X connect 8 1 20 0; #X connect 9 0 10 0; #X connect 10 0 23 0; #X connect 12 0 0 0; #X connect 13 0 15 0; #X connect 14 0 13 0; #X connect 15 0 12 0; #X connect 15 1 17 0; #X connect 17 0 19 0; #X connect 18 0 17 1; #X connect 20 0 22 0; #X connect 21 0 20 1; #X connect 23 0 11 0; #X connect 23 0 11 1; #X connect 24 0 23 1; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
Excellent - nothing to do then. My favorite kind of dolist. cheers M On Fri, Jan 28, 2022 at 07:37:04PM +, Pierre Alexandre Tremblay wrote: > 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 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 +, 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 > > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
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 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 +, 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 > 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
Re: [PD] [sfinfo~]
Email crossing, I literally apologised for my dumbness and noticed that single difference - we’re on the same page here :) > On 28 Jan 2022, at 19:29, oliver wrote: > > Miller Puckette via Pd-list wrote: >> Hi PA - >> 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. > > The one thing that [soundfiler] can not do, is to report the length of a > soundfile WITHOUT fully loading it into an array. > > That would be a great feature to have for [soundfiler]'s right outlet, > especially in the case of big files. > > You can get all the other information (channels, samplerate etc.) by loading > just a small sniplet of the source file (even 1 sample is sufficient IIRC) > into a buffer, but not the length. you would need to add "-resize" to the > load flags, which is not useful for (very) long files > > i still use IEMLIB's [soundfile_info] for that purpose. > > > > best > > oliver > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list 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
Re: [PD] [sfinfo~]
> 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. 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
Re: [PD] [sfinfo~]
Miller Puckette via Pd-list wrote: Hi PA - 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. The one thing that [soundfiler] can not do, is to report the length of a soundfile WITHOUT fully loading it into an array. That would be a great feature to have for [soundfiler]'s right outlet, especially in the case of big files. You can get all the other information (channels, samplerate etc.) by loading just a small sniplet of the source file (even 1 sample is sufficient IIRC) into a buffer, but not the length. you would need to add "-resize" to the load flags, which is not useful for (very) long files i still use IEMLIB's [soundfile_info] for that purpose. best oliver ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
You can get that info with [soundfiler] [array define myarray] [foo.wav( | [read -resize $1 myarray( | | [soundfiler] | | | [print stuff] | [print n of samples] -- Mensaje telepatico asistido por maquinas. On 1/28/2022 3:31 PM, Miller Puckette via Pd-list wrote: Hi PA - 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. cheers Miller On Fri, Jan 28, 2022 at 06:17:21PM +, Pierre Alexandre Tremblay wrote: Hello again So I was missing an object that is quite useful when dealing with audio files in batches. Attached is the ugly file in progress to read (with [file]) the header of audio files and demingle it to get the number of channels and number of frames and sampling rate… what the Max object [sfinfo~] does. Now I notices that the pd API offers me the headers to recode it in C - so I have 2 options here - I don’t bother anyone and I coder it as fluid.sfinfo - I code it as [sfinfo~] and make a PR and pray that the dev gods pick on it and in the meantime I just include my PR version. I looked in decken and couldn’t find that string (soundfile, sound file, etc) so I’m pretty sure it is not there. In all cases this is a very useful object to have. I offer my pd attempt in sacrifice to the people who want to have a laugh. It kind of works… but that ‘extended’ format (80 bit float anyone?) is a pain to detangle :) ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
I forgot is even simpler (no need for an array) [read foo.wav( | [soundfiler] | | | [print stuff] | [print n of samples] -- Mensaje telepatico asistido por maquinas. On 1/28/2022 3:36 PM, Lucas Cordiviola wrote: You can get that info with [soundfiler] [array define myarray] [foo.wav( | [read -resize $1 myarray( | | [soundfiler] | | | [print stuff] | [print n of samples] -- Mensaje telepatico asistido por maquinas. On 1/28/2022 3:31 PM, Miller Puckette via Pd-list wrote: Hi PA - 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. cheers Miller On Fri, Jan 28, 2022 at 06:17:21PM +, Pierre Alexandre Tremblay wrote: Hello again So I was missing an object that is quite useful when dealing with audio files in batches. Attached is the ugly file in progress to read (with [file]) the header of audio files and demingle it to get the number of channels and number of frames and sampling rate… what the Max object [sfinfo~] does. Now I notices that the pd API offers me the headers to recode it in C - so I have 2 options here - I don’t bother anyone and I coder it as fluid.sfinfo - I code it as [sfinfo~] and make a PR and pray that the dev gods pick on it and in the meantime I just include my PR version. I looked in decken and couldn’t find that string (soundfile, sound file, etc) so I’m pretty sure it is not there. In all cases this is a very useful object to have. I offer my pd attempt in sacrifice to the people who want to have a laugh. It kind of works… but that ‘extended’ format (80 bit float anyone?) is a pain to detangle :) ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
If you're after the number of channels and sampling rate, the list coming out of the right outlet of [soundfiler] gives you that. And the left outlet gives you the number of frames/samples, but beware that it actually reports the number of samples loaded to the target array. So if you don't use the -resize flag it won't necessarily report the number of samples in the file. On Fri, Jan 28, 2022 at 1:19 PM Pierre Alexandre Tremblay < tremb...@gmail.com> wrote: > Hello again > > So I was missing an object that is quite useful when dealing with audio > files in batches. Attached is the ugly file in progress to read (with > [file]) the header of audio files and demingle it to get the number of > channels and number of frames and sampling rate… what the Max object > [sfinfo~] does. > > Now I notices that the pd API offers me the headers to recode it in C - so > I have 2 options here > > - I don’t bother anyone and I coder it as fluid.sfinfo > - I code it as [sfinfo~] and make a PR and pray that the dev gods pick on > it and in the meantime I just include my PR version. > > I looked in decken and couldn’t find that string (soundfile, sound file, > etc) so I’m pretty sure it is not there. > > In all cases this is a very useful object to have. I offer my pd attempt > in sacrifice to the people who want to have a laugh. It kind of works… but > that ‘extended’ format (80 bit float anyone?) is a pain to detangle :) > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > -- William Brent “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sfinfo~]
Hi PA - 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. cheers Miller On Fri, Jan 28, 2022 at 06:17:21PM +, Pierre Alexandre Tremblay wrote: > Hello again > > So I was missing an object that is quite useful when dealing with audio files > in batches. Attached is the ugly file in progress to read (with [file]) the > header of audio files and demingle it to get the number of channels and > number of frames and sampling rate… what the Max object [sfinfo~] does. > > Now I notices that the pd API offers me the headers to recode it in C - so I > have 2 options here > > - I don’t bother anyone and I coder it as fluid.sfinfo > - I code it as [sfinfo~] and make a PR and pray that the dev gods pick on it > and in the meantime I just include my PR version. > > I looked in decken and couldn’t find that string (soundfile, sound file, etc) > so I’m pretty sure it is not there. > > In all cases this is a very useful object to have. I offer my pd attempt in > sacrifice to the people who want to have a laugh. It kind of works… but that > ‘extended’ format (80 bit float anyone?) is a pain to detangle :) > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
