> I do not have much time to figure out to solve the problem before having to hand in the score and patch.
 
I see :-). Anyway, it kind of looks more like a problem with your latency settings. in the future you might also experiment with [pd~] to make use of your multi-core processor. this way you can also have different latency settings for different parts of your patch. or work with several instances of Pd.
 
also, working with large ffts can easily lead to drop outs because of CPU spikes (which one doesn't see in CPU meters because the do some averaging), so it's a good idea to put them into another process or instance if there's some other CPU heavy thing going on at the same time.
 
good luck!
 
Gesendet: Dienstag, 28. Februar 2017 um 14:17 Uhr
Von: "José Rafael Subía Valdez" <jsubiavaldez@gmail.com>
An: Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] soundfiler alternative?
Yeah, I tweaked parameters, and actually to follow up on the last message. All of them still cause drops. Some settings more sporadically than others. I have decided to take this process out as I do not have much time to figure out how to solve the problem before having to hand in the score and patch. But I will keep on studying this.
 
once again thank you all for the help.
 
cheers
 
On Tue, Feb 28, 2017 at 1:12 PM, Christof Ressi <christof.ressi@gmx.at> wrote:
> both Christof's and Jack's solution still create audio drops.

did you actually tweek the parameter?? there *must* be a setting where you don't get dropouts but the question is rather if this setting is acceptable for you.
 
 

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

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.ressi@gmx.at[mailto:christof.ressi@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.ressi@gmx.at[mailto:christof.ressi@gmx.at] <mailto:christof.ressi@gmx.at[mailto:christof.ressi@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" <jsubiavaldez@gmail.com[mailto:jsubiavaldez@gmail.com]
    <mailto:jsubiavaldez@gmail.com[mailto:jsubiavaldez@gmail.com]>>
    An: Pd-List <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?

    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@gmx.at[mailto:christof.ressi@gmx.at]

    <mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>[mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]
    <mailto:christof.ressi@gmx.at[mailto:christof.ressi@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)()]]
    <https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29[https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29][https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&ranSiteID=TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g&tduid=%2894e0b4bf83daa242de97c8bfb531e5d9%29%28256380%29%282459594%29%28TnL5HPStwNw-Z6NjEgcaJn8pbbYAema89g%29%28%29[https://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx?ranMID=24542&ranEAID=TnL5HPStwNw&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" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]

    <mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]>[mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]
    <mailto:zmoelnig@iem.at[mailto:zmoelnig@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]>[mailto: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]>[mailto: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.puredata.info/listinfo/pd-list][https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D]
    <https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D[https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.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]>[mailto: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.puredata.info/listinfo/pd-list][https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D]
    <https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D[https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.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]>[http://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] <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.puredata.info/listinfo/pd-list][https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D]
    <https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/listinfo/pd-list%5D[https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.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.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