[PD] [soundfile_info] made with vanilla

[Joe White]

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 at 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 at 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 at 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 at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list [2]
>>>
>>
>> _______________________________________________
>> Pd-list at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180524/9344b556/attachment.html>