Hey Oliver,
I will admit to not fully digesting your patch, but from skim reading it I'm assuming it loops over the sample data by incrementing the -skip argument until you reach the end of the file. For my purposes memory usage isn't really an issue, so I'd imagine it would be far quicker to just load the whole sample into the table.
What would be nice is if [soundfiler] additionally read the data chunk size property in the wav header for the number of samples. I imagine that's why [soundfile_info] was created in the first place.
Cheers, Joe
On 24 May 2018 at 14:38, oliver oliver@klingt.org wrote:
On 2018-05-24 15:03, Joe White wrote:
Hey Oliver,
This is a neat trick, however for my purposes [soundfle_info] was being used to extract both the sample rate and sample length to calculate the duration of the file.
Looks like in order to switch to [soundfiler] I'd have to load the whole file to memory regardless, as the
-skip 1
flag means the left outlet (sample length) of [soundfiler] only outputs '1'.have a look again.
in the middle of the patch, i use soundfiler's right outlet (available since PD 0.48, so make sure you are using this !) to get the file's samplerate, even though it is just reading 1 sample of it. so, no need to load the whole thing.
the left part of the patch gives you the file's length in samples, which you can then re-calculate (using the file's samplerate) to ms or whatever you need.
yes, the left outlet always only puts out 1 or 0, which i use to narrow down the last valid sample position, which is then the file's length in samples (endpoint).
i send the patch again to illustrate what i mean (unless i misunderstood something)
best
oliver
Cheers, Joe
On 12 May 2018 at 19:37, Alexandre Torres Porres porres@gmail.com wrote:
a new flag for [soundfiler] will make this easier without the need
of a dummy buffer
see https://github.com/pure-data/pure-data/pull/193 [1]
2018-05-12 14:06 GMT-03:00 oliver oliver@klingt.org:
Joe White wrote: Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using /vbap/ [0] and /soundfile_info/ from iemlib [1].
hi,
just the other night i was hacking together a [sound_file] info alternative with purely vanilla objects WITHOUT loading an entire file into RAM.
the method is basically to use [soundfiler] to load 1 sample of a file into a table with a -skip message, and recalculate the skip position until [soundfiler]'s left outlet outputs 1 (instead of 0).
all of [soundfile_info]'s other values are also output from [soundfiler]'s right outlet as of PD version 0.48.
it takes a tad longer than [soundfile_info] to output the soundfile's length, but it's acceptable imho. plus you can use .aiff too !
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list [2]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list [2]
Links:
[1] https://github.com/pure-data/pure-data/pull/193 [2] 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