New to sonic pi but have been following a few tutorials on how to get things going…
Currently, I have rigged a few MPR121 cap touch sensors to use OSC in the sonic pi environment which works great! My intent is to use these sensors to trigger “random” samples from a folder.
This folder however is in sync with google drive making it possible for me to send audio samples from anywhere, is it possible to have the samples be updated automatically without stopping/restarting sonic pi?
Any guidance is much appreciated and by chance if it isn’t possible, an alternative solution/software for the raspberry pi?
Can you elaborate what you mean by this? When you ask to play a sample, Sonic Pi will already automatically load the sample into memory if it is not already cached, just before playing it.
Hmm, no, sorry. It does look like changing the samples in a folder while Sonic Pi is running and then asking sample to play a random sample from that folder means the existing cached samples from that folder are still all that you get. @samaaron - is recognising changes to a folder of samples while Sonic Pi is running something that could go on the wishlist?
Apologies for the lack of clarity there, so i basically want to access my samples in the same way described in the sonic pi tutorial by using a folder directory to get samples from as opposed to locating individual files, by using:
sample "/path/to/samples"
The directory in my case would lead to a folder on Google drive (which has been mounted to the PI using rclone) which is constantly being sent new audio files whilst Sonic Pi is running, which then the MPR121 modules would be randomly selecting from using OSC functions.
Im still writing the code but found this thread along the way:
which states that I would have to reboot:
“…put reboot in a buffer and hit the run button - it will restart the audio server and also refresh all the caches :-)”
But my only worry/ problem is, would I have to hit run continually in order for the folder files to be refreshed? I was wondering if I could incorporate it somehow but apparently, once run gets hit all functions stop…
Hence why I’m investigating if there is a seamless way for me to have an automatic/continual update of a sample folder whilst a programme is running in Sonic pi without having to restart or stop any functions.
Ah, I had forgotten about reboot. (It’s not a documented function for one, so may change without notice.)
You could make the code call reboot whenever you trigger a random sample, but that’s obviously not going to be very practical…
When you hit Run, all it does is start a new run. (aka a new job that runs whatever code was on screen at the time). Unless I’m misunderstanding what you’re getting at…
As for an efficient/seamless way to do what you’re after, I’m not too sure at the moment, perhaps Sam will have more to say.
Hi @Gogosavag3 - we cache the contents of a folder so that subsequent lookups don’t require any (occasionally very costly in the case of certain deep traversals) disk access for calls to sample which may be put in very tight loops (especially for short percussive samples).
Not using this cache would make Sonic Pi much less efficient and introduce many timing issues for large cohort of users. Therefore, removing it is something I’m very reluctant to consider.
However, would a reset_sample_cache like function work for you here? This could be something you could call when necessary in order to reset this cache. This would mean that all subsequent calls to sample would again require disk IO and therefore pick up any new changes to the folder listings.
Just thinking… another option could be to give sample an option to refresh the cache for that particular folder, then you wouldn’t have to lose the cache for other folders that might not be likely to change. Something like:
live_loop :foo do
sample "/path/to/unchanging/samples", 3
sample "/path/to/changing/samples", 42, refresh_cache: true
sleep 1
end
Oook! From what you explained, yes we don’t want to make this software inefficient haha too cool for that!
Thank you so much for the guidance here! Indeed something like reset_sample_cache Would be awesome as I could work it into the live loop/play code somehow I’m guessing … I’m thinking maybe if there’s a certain interval of time that there has been no touch impulse , it’s then the reset_sample_cache Would/cloud be called!?
I doubt attaching a reset_sample_cache For every trigger would be efficient but who knows , can try
Is reset_sample_cache An available function right now?
Really greatfull for your response and contribution to the global family… I’ve been in this cave for days haha
Niiiiice!! Dude I’m not even using another folder so this might actually be a another form of solution
I’m going to try implementing this in the code and see how it works out! I’m still working on getting Mpr121 to fully calibrate with this current project but will try your solution on an example from somewhere!!
I should just clarify that my idea was about any changes that might be made to Sonic Pi itself in a future version - it won’t work with Sonic Pi at the moment (unless you modify Sonic Pi’s source code yourself to implement it of course).
