Pure Data and audio file loading

hugo

Hello,

I have been using Bela with Pure Data for a few years. I have made some really nice projects with it. Thank you all for this beautiful software+hardware !
I am coming back to it now because I want to design a performance instrument for my live shows.
Basically I need something to play long audio tracks simultaneously, but the puredata [readsf~] won't do because I need:
1) real-time pitch variation (like a turntable pitch)
2) looping

I will run into the RAM limitation of the Bela if I try to load everything in arrays on startup (with [soundfiler]).
And using [soundfiler] while playing causes mode switches and drops in the audio.

So I am thinking of two solutions right now, and I like neither of them.

The first one would be to use [readsf~] to play audio to a [tabwrite~] to record the next audio files to play in some arrays while the previous audiofiles keep playing from another set of arrays. This works but it seems a bit circumvoluted.

The other approach would be to write an external based on readsf~ code, but implementing variable rates of play and some basic looping. I have a strong experience writing externals but this one I would rather avoid, as it deals with a lot of low-level file access. Actually just quickly reading through readsf~ source code it makes my first solution look like a joyride.

So before I dig into either of these, I kindly ask this forum if someone else has another idea.
Perhaps an already existing pd external ?
A magical tweak to bela settings that avoids mode switches if loading small enough files (one can dream) ?

Please save me from ultimate pcm streaming nerdiness.

giuliomoro

hugo A magical tweak to bela settings that avoids mode switches if loading small enough files (one can dream) ?

If you are well versed in C++, then this can be done from the C++ side of the Pd-Bela integration, which uses libpd. You can access array pointers through the libpd API and then populate them using e.g.: AudioFileReader.

giuliomoro

I don't have any secret method here ... the [readsf~] in the background is the one is the one I have worked with in the past. Someone on the Pd list had suggested running readsf+tabwrite in an oversampled subpatch so it could load the file faster.

A threaded soundfiler is all you'd need really. There was an early attempt to do that here https://github.com/pure-data/pure-data/pull/655 but it didn't go nowhere. It should be much easier to do something based on Christof's worker thread API: https://github.com/pure-data/pure-data/pull/1357 . This would also make for a great use case to encourage pushing that PR towards inclusion in mainline Pd.

hugo

Thank you very much for the quick answer. I do feel safer now.
I'll look at the links you provided and post a reply here if I achieve anything fancier than the [readsf~] -> [tabwrite~] method.

hugo

So I've been doing the reading, thought it was way too complicated.
And realized that this simple patch was doing the job perfectly.

I've been experimenting with varying the blocksize in [switch], bela blocksize and the oversampling factor.
It turns out that it is better to work with small [switch] blocksizes, but bela can handle very high oversampling without underruns or glitches.
I have tried as high as an oversampling factor of 256 (so 256 times faster, basically flushing the audiofile into the buffer, and for files of a few minutes it feels like instant loading) and no glitches in bela, even with a blocksize as low as 32 (bela settings).

I'm impressed.

I don't think loading audio files while playing audio will be a problem anymore.

Remork

trying to wrap my head around this, as it seems interesting.
you're basically playing the soundfile you want to load with [readsf~], but playing it back at a ridiculous speed?
so how do you determine the ratios between blocksize, no. of blocks and oversampling factor?

hugo

you're basically playing the soundfile you want to load with [readsf~], but playing it back at a ridiculous speed?

That's the idea

Let's say you want to load 3min of sound at 44100 Hz. You have to play 44100 * 60 * 3 = 7.938.000 samples.
On the Bela taking small blocksize peform better so for example let's say the blocksize is 128, you have to play at least 7.938.000 / 128 = 62015,625 blocks, so round that up to 62016 so you don't lose audio.

The oversampling factor doesnt matter, it's just the speed at which it is played

giuliomoro

It surprises me that you don't get any underrun at arbitrarily high oversampling ... the read speed from disk is not unlimited, it's probably around 5MB/s, and the normal behaviour of readsf~ is that if the audio is not ready to play when it should, it blocks the audio thread until it has read enough samples.

hugo

abritrarily was a strong word, I didn't go higher than 256