Hey Christof and Jean-Yves Gratius Thanks, I am opening them up just now. Christof, your patch gives me these errors when I try it out:
soundfiler_read: truncated to 44100 elements -> this one is repeated by the amount of blocks it will take to completely load the sound file resize failed any idea why?? (before I start dismantling it?) Cheers Guys, much appreciated. On Tue, Feb 28, 2017 at 11:35 AM, Christof Ressi <christof.re...@gmx.at> wrote: > 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" <jsubiaval...@gmail.com> > An: Pd-List <pd-list@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.re...@gmx.at > [mailto:christof.re...@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=TnL5HPS > twNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e > 0b4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw- > Z6NjEgcaJn8pbbYAema89g)()[https://msdn.microsoft.com/en-us/ > library/aa366778(VS.85).aspx?ranMID=24542&ranEAID=TnL5HPStw > Nw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=(94e0b > 4bf83daa242de97c8bfb531e5d9)(256380)(2459594)(TnL5HPStwNw-Z > 6NjEgcaJn8pbbYAema89g)()] > > > 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" <zmoel...@iem.at[mailto:zmoel...@iem.at]> > > An: pd-list@lists.iem.at[mailto:pd-list@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@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/li > stinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] > > > > _______________________________________________ > Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/li > stinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] > -- > > José Rafael Subía Valdez > www.jrsv.net[http://www.jrsv.net] > > > _______________________________________________ Pd-list@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
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
