Bela Gem sample reading
Hello there,
I’m a new owner of a Bela Gem Multi, my aim is to use it for a sound installation requiring multichannel audio played on headphones. For this, I wanted to use RNBO and then export the C++ code to run it on Bela. My actual project is to have a realtime selection of a lot of audio files (more than 500). There are predominantly under 30 seconds and goes to around 5 minutes for the longer ones. Right now, it does not work with this number of files when I build the exported C++ code with the Bela IDE. But it does work when I use less audio files (around 40, WAVE 48-24).
In RNBO, I use a very simple patch (screenshot below), to select the files read by a groove~ which buffer is changed by a multibuffer~. I declare all my audio files with buffer~ objects, they seem to be recognized in the console of the Bela IDE. It seems it’s the working method right now in RNBO to use buffers, even though it’s really painful to name individual files like this.
I had not anticipated this issue and following an answer from the Bela forum, I understand that I need to load a few samples in RAM to play them and load the rest from disk when it's needed. Here I'm going over what the RAM is capable with this size of audio files and reading only from RAM.
Is it possible in RNBO to specify this kind of operation (i.e. allocation between RAM and disk) ?
Thanks a lot for your help !
Unfortunately RNBO doesn't have a good way to do what you're trying to do here internally. All specified buffers are loaded into RAM. Maybe some day we could have a way to stream from disk, but we don't have that now (it would be a major architectural change).
It looks like the Bela integration isn't setup to change dataref mappings at runtime (only load), but support for that would likely be beneficial for others as well. Even with runtime loading support though you'd have to figure out a way to instrument changing the mappings.
Considering the amount of infrastructure you'd need to work on for this, if all you're doing is playing these audio files and switching between them, RNBO is likely not the best choice for you at this time. If you are doing some sort of processing on the audio streamed out of groove~, maybe it is worth the work.
BTW, if you're doing some sort of audio processing on the output of groove~, you could also consider streaming audio into RNBO, using it as an effect for an audio source external to your RNBO patch.
Thank you for your answer Alex !
I think I understand what you're saying. My goal using Bela-RNBO for this particular project, is to create a multichannel interactive-generative sound installation. For now, I'm at an early stage of creation where I want to have a "proof of concept" to see if the fundamentals are working. So this RNBO patch is really simple on purpose (there are more than one of this same patch that interact with each other — in the "big picture" not shown here).
In the future, I planning to add some ways for visitors to interact with the installation and to elaborate on probabilistic-statistical ways of choosing samples in RNBO (made really simple with urn here). I'm interested in novel ways of controlling samples in an installation context. I'm used to work with Max for a long time, RNBO is a way to stay in a familiar environment and to extend my practice to embedded systems like Bela. And RNBO is really smooth to work with — good job !
At the same time, I published a post on Bela forum and they are offering some help to see if there is something we can do. Maybe I'll find a solution there, and I have no problem for you not being able on C74 side to have an answer to every user cases after exporting from RNBO. Seems really reasonable !