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 :)
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 +0000, 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
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 +0000, 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
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 +0000, 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
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.
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
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 msp@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
Excellent - nothing to do then. My favorite kind of dolist.
cheers M
On Fri, Jan 28, 2022 at 07:37:04PM +0000, 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 msp@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
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
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 oliver@klingt.org 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
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
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 oliver@klingt.org 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
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 < tremblap@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
-
Alexandre Torres Porres -
Lucas Cordiviola -
Miller Puckette -
oliver -
Pierre Alexandre Tremblay -
William Brent