[PD] soundfiler alternative?

Tue Feb 28 13:23:15 CET 2017

Hello Jack,

thanks for sharing, it still causes audio drops. Does it work for you?

cheers?

On Tue, Feb 28, 2017 at 12:12 PM, Jack <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>
> > 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]
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 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
>
>

-- 
José Rafael Subía Valdez
www.jrsv.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170228/c34ad408/attachment-0001.html>