[PD] soundfiler alternative?

Tue Feb 28 12:35:06 CET 2017

José, I think I have a solution which might work for you. see my attached patch. it's not a clean abstraction but rather demonstrates the principle.

basically, I spread the loading of the soundfile over several DSP blocks and you can adjust how many samples to load in one block. 44100 samples, for example, works fine for me (no dropouts), which means I can load 1 second of audio in 1.5 ms or 10 minutes in 900 ms! 

note that it needs soundfile_info from iemlib.

[soundfiler] will vomit at you in the Pd console but you can simply ignore it by setting the log level to 0. 

Anyway, I'm really thinking of turning it into an external because there some inefficiencies I could get rid off. Most notably, I have to use an intermediate buffer plus |read -resize -maxsize ...( to prevent [soundfiler] from reading the file always till the end because it doesn't have -nframes as an read option (which is unfortunate).

Hope that helps!

Christof 

Gesendet: Dienstag, 28. Februar 2017 um 07:42 Uhr
Von: "José Rafael Subía Valdez" <jsubiavaldez at gmail.com>
An: Pd-List <pd-list at lists.iem.at>
Betreff: Re: [PD] soundfiler alternative?

Thank you all..

but I am developing patches that are handed to performers and should work out of the box, I can't depend on the expensive machines and RAM-DISK settings because I can not tell my performers - you need to do all of this and invest in your computer first before you play my music. Why? because this is something I am doing for my PhD. Yes..saying "buy a fancy computer with lots of RAM" is easier in Europe or the US than in other places of the world and that is not my aim. I am trying to squeeze the best solutions on any type of machine and to provide people that are not necessary computer music users with the friendliest setup I can think of.

the computer I am programming this is a iMac from 2007 with 4 gb of RAM. I have many processes including FFT, but thanks to switch~ I am able to optimize the patch. I just have this problem that causes audio drops when loading each sample. So not really wanna discuss finances.

Thanks again

On Mon, Feb 27, 2017 at 11:35 PM, Christof Ressi <christof.ressi at gmx.at[mailto:christof.ressi at gmx.at]> wrote:> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.

Actually, the average Windows user will have more 32-bit apps than 64-bit apps running on their 64-bit OS ;-).
And most Pd users on 64-bit Windows will have a 32-bit Pd  because Miller doesn't offer 64-bit binaries yet and building from source is still impossible (at least with MinGW).

> decent OSs should be able to manage more than a total 4GB of RAM even
> when the entire OS is 32bit (a single application will not be able to
> address more than 2^32 bytes though; but it should get you closer to
> really having 4GB, rather than 2GB)

on 32-bit Windows you usually get 2 GB per process - or 3 GB with some tricks*. on 64-bit Windows it's 2 GB for 32-bit processes unless you compile with IMAGE_FILE_LARGE_ADDRESS_AWARE set, then you get 4 GB.

here are the boring details: https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()[https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()]

I actually I didn't know about IMAGE_FILE_LARGE_ADDRESS_AWARE until now. Miller could actually use it in his 32-bit Windows builds, which currently only allow 2 GB**. It won't do any harm on 32-bit systems and doubles the available memory on 64-bit systems.

> fun fact: on linux, you can use 64bit Pd for >10 years with virtually
> all external libraries working.

:-o. time to finally get my dual boot. I weren't so lazy...

Christof

* IMAGE_FILE_LARGE_ADDRESS_AWARE set + 4GT enabled (risky)
** I tested this with latest vanilla 32-bit binaries on Windows 7 64-bit (with 16 GB of RAM installed). I get a warning when I try to exceed 2 GB.

> Gesendet: Montag, 27. Februar 2017 um 22:58 Uhr
> Von: "IOhannes m zmölnig" <zmoelnig at iem.at[mailto:zmoelnig at iem.at]>
> An: pd-list at lists.iem.at[mailto:pd-list at lists.iem.at]
> Betreff: Re: [PD] soundfiler alternative?
>

> On 02/27/2017 10:45 PM, Christof Ressi wrote:
> >> well, [table] stores the samples as floating point (taking 4 bytes per
> >> sample; and 8 byte on 64bit systems),
> > It depends on your Pd (32-bit or 64-bit), not on the system.
>
> well yes, true.
> i keep forgetting of abominations like running a 32-bit Pd on a 64-bit OS.
>
> >
> >> however, there is a simple solution at hand: get youself plenty of RAM
> >> and pre-load everything into tables.
> >> 32GB cost about 250,-€ and will allow you to load approx. 24h of raw
> >> audio, which is probably enough.
> > Unfortunately, this is only true for 64-bit processes. A single 32-bit process can't handle more than 2^32 bytes (~4 GB). In reality, it's even less, usually 2 GB, which is a bit more than 1,5 hours of stereo audio @44100 Hz. Pd will give you a warning when you try to exceed this limit ("pd: resizebytes() failed - out of memory").
>
> how much RAM does that machine have?
> decent OSs should be able to manage more than a total 4GB of RAM even
> when the entire OS is 32bit (a single application will not be able to
> address more than 2^32 bytes though; but it should get you closer to
> really having 4GB, rather than 2GB)
>
> but yes, in order to make use of 32GB of memory you need a native 64bit
> application (running on a 64bit OS).
>
> fun fact: on linux, you can use 64bit Pd for >10 years with virtually
> all external libraries working.
>
> gmsr
> IOhannes
>
>
>

> _______________________________________________
> Pd-list at lists.iem.at[mailto:Pd-list at lists.iem.at] mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>

_______________________________________________
Pd-list at lists.iem.at[mailto:Pd-list at lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] 
 --

José Rafael Subía Valdez
www.jrsv.net[http://www.jrsv.net]

 _______________________________________________ Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: load-soundfile.pd
Type: application/octet-stream
Size: 2858 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170228/1a543f52/attachment.obj>