<div dir="ltr">Hey Oliver,<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Joe</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 May 2018 at 14:38, oliver <span dir="ltr"><<a href="mailto:oliver@klingt.org" target="_blank">oliver@klingt.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-05-24 15:03, Joe White wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Oliver,<br>
<br>
This is a neat trick, however for my purposes [soundfle_info] was<br>
being used to extract both the sample rate and sample length to<br>
calculate the duration of the file.<br>
<br>
Looks like in order to switch to [soundfiler] I'd have to load the<br>
whole file to memory regardless, as the `-skip 1` flag means the left<br>
outlet (sample length) of [soundfiler] only outputs '1'.<br>
</blockquote>
<br>
have a look again.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
i send the patch again to illustrate what i mean (unless i misunderstood something)<br>
<br>
best<br>
<br>
oliver<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Joe<br>
<br>
On 12 May 2018 at 19:37, Alexandre Torres Porres <<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a new flag for [soundfiler] will make this easier without the need<br>
of a dummy buffer<br>
<br>
see <a href="https://github.com/pure-data/pure-data/pull/193" rel="noreferrer" target="_blank">https://github.com/pure-data/p<wbr>ure-data/pull/193</a> [1]<br>
<br>
2018-05-12 14:06 GMT-03:00 oliver <<a href="mailto:oliver@klingt.org" target="_blank">oliver@klingt.org</a>>:<br>
<br>
Joe White wrote:<br>
Hi all,<br>
<br>
I recently spent a bit of time tracking down why a patch wasn't<br>
loading a couple of externals in a windows application that embeds<br>
libpd.<br>
<br>
The patch was using /vbap/ [0] and /soundfile_info/ from iemlib [1].<br>
<br>
hi,<br>
<br>
just the other night i was hacking together a [sound_file] info<br>
alternative with purely vanilla objects WITHOUT loading an entire<br>
file into RAM.<br>
<br>
the method is basically to use [soundfiler] to load 1 sample of a<br>
file into a table with a -skip message, and recalculate the skip<br>
position until [soundfiler]'s left outlet outputs 1 (instead of 0).<br>
<br>
all of [soundfile_info]'s other values are also output from<br>
[soundfiler]'s right outlet as of PD version 0.48.<br>
<br>
it takes a tad longer than [soundfile_info] to output the<br>
soundfile's length, but it's acceptable imho. plus you can use .aiff<br>
too !<br>
<br>
best<br>
<br>
oliver<br>
<br>
______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -><br>
<a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/li<wbr>stinfo/pd-list</a> [2]<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -><br>
<a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/li<wbr>stinfo/pd-list</a> [2]<br>
<br>
<br>
<br>
Links:<br>
------<br>
[1] <a href="https://github.com/pure-data/pure-data/pull/193" rel="noreferrer" target="_blank">https://github.com/pure-data/p<wbr>ure-data/pull/193</a><br>
[2] <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/li<wbr>stinfo/pd-list</a><br>
</blockquote>
<br>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
<br></blockquote></div><br></div>