Hello! There’s one thing I need to understand about Sonic Pi.
It works okay as long as I keep it simple with sounds, for instance playing one line of sample. But as soon as I put more elaborate and complex sounds, the application starts to lag, the sound falls behind in timing, a a thread death results from this somewhere, and Sonic Pi doesn’t play even the simplest sound if I stop the sound. I press the “Run”, but nothing starts. Moreover, the app’s sound starts to run on its own, taking out of the sound some of the commands on the buffer (e.g. leaving only percussions, drums or the :bd-haus sample), slowing the tempo. When I stop the sound, Sonic Pi doesn’t even run the simplest sound, I press “Run” but the program stays silent.
I took the complex sounds from one of the tutorials that can be found in this forum, which I leave below:
For your information, I have the portable version of Sonic Pi on my computer and my laptop’s system runs on Windows and I have around 60 tabs in Google open. This might help you figure out what’s wrong, let me know if you need further details.
Can anyone help me? I’d be grateful for that. I hope my explanation of the issue is clear enough. Thank you in advance to anyone who will lend a hand. Have a nice day.
As Eli noted …
PLUS
I had the same problem with your code
until I turned the reverb in the last loop
off . Reverb is notorious for sucking up
resources …
Hey Bryan - I’ll jump in, since I’m around right now The situation that @Eli was referring to is described in Sonic Pi’s tutorial - see https://sonic-pi.net/tutorial#section-6-2 for example.
It’s not always so much as what line should you avoid, as what order you might need to write some things in.
Several of Sonic Pi’s FX can be quite resource intensive if used in certain ways, with :reverb being a common one. As such, we often want to avoid putting a :reverb FX inside a live_loop (or normal loop for that matter) if the loop has a small time span, such as in your example, since a new reverb is created every time around the loop.
It’s described in more detail in the tutorial linked above, but one of the most common solutions is instead to wrap the live_loop in the FX, instead of the other way around.