[PD] soundfiler alternative?

Jack jack at rybn.org
Tue Feb 28 13:38:29 CET 2017


Le 28/02/2017 à 13:23, José Rafael Subía Valdez a écrit :
> Hello Jack,
> 
> thanks for sharing, it still causes audio drops. Does it work for you? 

Yes it works.
Try to set the last value in [block~] to 512 (instead of 1024).
++

Jack


> 
> cheers?
> 
> On Tue, Feb 28, 2017 at 12:12 PM, Jack <jack at rybn.org
> <mailto:jack at rybn.org>> wrote:
> 
>     I guess Martin was more talking about this solution (see patch
>     attached).
>     ++
> 
>     Jack
> 
> 
> 
>     Le 28/02/2017 à 12:35, Christof Ressi a écrit :
>     > 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
>     <mailto:jsubiavaldez at gmail.com>>
>     > An: Pd-List <pd-list at lists.iem.at <mailto: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>[mailto: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)()]
>     <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>[mailto:zmoelnig at iem.at
>     <mailto:zmoelnig at iem.at>]>
>     >> An: pd-list at lists.iem.at
>     <mailto:pd-list at lists.iem.at>[mailto: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>[mailto: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]
>     <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>[mailto: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]
>     <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>[http://www.jrsv.net
>     <http://www.jrsv.net>]
>     >
>     >
>     >  _______________________________________________
>     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]
>     <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>
>     >
> 
> 
>     _______________________________________________
>     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
> 




More information about the Pd-list mailing list