Okay, update with all the solutions everyone has chipped in. (THANKS AGAIN)
both Christof's and Jack's solution still create audio drops. Now I am testing Jean-Yves's patch and seems to do the trick. again, thank you all. If anyone has another idea, I will be interested in looking at other solutions (just for the heck of it). ps. Thanks Jack, I will try changing the [block] cheers On Tue, Feb 28, 2017 at 12:28 PM, Christof Ressi <christof.re...@gmx.at> wrote: > That's what I meant with: > > > [soundfiler] will vomit at you in the Pd console but you can simply > ignore it by setting the log level to 0. > > I know why it happens but it doesn't really matter. Despite its flashy > read appearance it's just a warning which can be safely ignored. > > The patch itself should work. Tweek the amount of samples per DSP block to > find a setting which works for you without dropouts. > > > > On 28.02.2017 12:54, José Rafael Subía Valdez wrote: > >> 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 >> <mailto: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 >> <mailto:jsubiaval...@gmail.com>> >> An: Pd-List <pd-list@lists.iem.at <mailto: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>[mailto: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).asp >> x?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6N >> jEgcaJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9) >> (256380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()[http >> s://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx?ra >> nMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgc >> aJn8pbbYAema89g&tduid=(94e0b4bf83daa242de97c8bfb531e5d9)(256 >> 380)(2459594)(TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g)()] >> <https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%2 >> 9.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwN >> w-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb5 >> 31e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8 >> pbbYAema89g%29%28%29[https://msdn.microsoft.com/en-us/ >> library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5 >> HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=% >> 2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594% >> 29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29]> >> >> >> 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>[mailto:zmoel...@iem.at >> <mailto:zmoel...@iem.at>]> >> > An: pd-list@lists.iem.at >> <mailto:pd-list@lists.iem.at>[mailto: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>[mailto:Pd-list@lists.iem.at >> <mailto:Pd-list@lists.iem.at>] mailing list >> > UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list[https://lists.p >> uredata.info/listinfo/pd-list] >> <https://lists.puredata.info/listinfo/pd-list%5Bhttps://list >> s.puredata.info/listinfo/pd-list%5D> >> > >> >> _______________________________________________ >> Pd-list@lists.iem.at >> <mailto:Pd-list@lists.iem.at>[mailto:Pd-list@lists.iem.at >> <mailto:Pd-list@lists.iem.at>] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list[https://lists.p >> uredata.info/listinfo/pd-list] >> <https://lists.puredata.info/listinfo/pd-list%5Bhttps://list >> s.puredata.info/listinfo/pd-list%5D> >> >> -- >> >> José Rafael Subía Valdez >> www.jrsv.net <http://www.jrsv.net>[http://www.jrsv.net >> <http://www.jrsv.net>] >> >> >> _______________________________________________ >> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list[https://lists.p >> uredata.info/listinfo/pd-list] >> <https://lists.puredata.info/listinfo/pd-list%5Bhttps://list >> s.puredata.info/listinfo/pd-list%5D> >> >> >> >> >> -- >> 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/li >> stinfo/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
