Greetings!
I am trying to create a sampler-synth with Bela, using the phase vocoder technique.
So i attempted to create a mechanism to my existing patch so the user can change samples in real time using buttons on the digital i/os.
Even though i am running on the lowest possible sampling rate , Block size is set to 128, and window size is set to 512, every time i change a sample i get these :
"Underrun detected: 4 blocks dropped
490 mode switches detected on the audio thread".
I also noticed than when i include more than 4-5 sound samples on the pd project folder the output signal becomes distorted or i get no sound at all.
In this attachment you can see what i do inside the patch when reading samples :
alt text
Are there any limitations when it comes to reading samples or any technique to avoid that?

    phevosSo Are there any limitations when it comes to reading samples or any technique to avoid that?

    [soundfiler] is not meant to be used to load samples while processing audio. When you send a[read( message to [soundfiler], it stops everything and tries to load the whole file (or the specified range) into an array. While it does this, no audio can be processed, and that's why you get the "drops blocked" message.

    If you want to use [soundfiler], you should have it so that all the files you will need are read each into a separate array, so that at runtime you just need to switch the array you read from. Unless you have hundreds of megabytes of audio in your samples, this approach is the easiest.
    At the other end of the spectrum, there is [readsf~]. Once you send it the [open( message, it starts buffering the file from disk into memory, in a real-time friendly fashion (that is: the loading takes place in a separate thread, so it does not affect the audio performance). However, with [readsf~] you need to send [open( before you actually need to play back the audio from the file (exactly for the reason that the buffering from disk into memory is done in a real-time friendly way). From the help file of [readsf~]:

    You must open the soundfile in advance (a couple of seconds before you'll need it)

    Also, if you want to play the sound from the beginning again, you will need to send the [open( message again, and wait again.

    So:
    - if your samples all fit in memory, you should use [soundfiler] and load them all at the beginning.
    - if you have a large number of samples, but can tolerate waiting between [open( and the start of playback, use [readsf~]. To make re-triggering easier, you can store the output of [readsf~] in a pre-allocated (again, resizing arrays at run time will cause an audio glitch) temporary array .
    - if you have a large number of samples, that will not all fit in arrays in memory, but still you want to be able to play them all with zero notice, then the trick is to"
    - store just the beginning of the file in an array at startup (using [soundfiler]). This could be between 0.5 and 2 seconds, but the exact number of samples needs to be a multiple of Pd's blocksize.
    - when the sample is played, start playing immediately from the array and send an [open( message to [readsf~].
    - when you finished reading the array, hopefully [readsf~] will have read enough data from disk into memory and will be ready to play, so send it [1( to start playback
    - I actually have an implementation of this here: https://github.com/giuliomoro/dynamic-load-files-Pd Note that the Pd GUI seems to freeze sometimes (I think it's a bug), but it actually runs fine on Bela

      Thank you very much Giulio for your in depth explanation! I think i am going to stick with the soundfiler and do as you suggested.

      5 years later

      This above, I’m not getting more than one readsf~ playing at the same time.

      Is there a limit to how many can play with vanilla PD

      I have played over 20 at once on Bela I think. Though remember that you need to wait a few milliseconds between sending [open ...( to [readsf~] and starting playback.