I can’t say for sure whether it is the whole issue, but the loop that is halting has one thing that is likely a problem - a short loop time combined with a :reverb fx. The :reverb fx is fairly resource intensive when running on SuperCollider, (Sonic Pi’s sound engine), and when one is placed in a tight loop, multiple reverbs get created because each one does not have time to complete before the next is created. The offending loop here, :synth, has a :reverb fx in it, and a total duration of 1 beat.
In general, the solutions here would be to either increase the time between each :reverb being created, remove them altogether from this loop, or move the reverb fx so that it wraps the entire :synth live_loop. (though that solution comes with a few side-effects of its own).
Have a go at changing the use of that reverb fx, and see if it improves things
Why should I remove anything when I have CPU capacity? CPU usage of 5% remained at 95%. The essence of a music editing program is not to close barriers, but to give freedom. I have resources, I just can’t use them … The solution is not to take them out …
Questions / problems:
How to boost Sonic Pi more CPU usage?
How to on / off AVX FPU ability?
How to disable timing error?
Ruby space there is no other Sonic Pi frame system that would have better performance?
This is an excellent question and one that’s wroth answering fully.
The problem is that your CPU capacity actually means a few things thrown together. Firstly, it’s going to be the aggregated sum of all your CPUs. Sonic Pi has a number of different components all which can run independently on different CPUs. However the sound synthesiser which generates the audio can only run on one of them. Therefore, if you have 8 CPUs offering 16 logical threads, then the max that the synthesis part of Sonic Pi can use is 100 / 16 = 6.25% of your capacity.
Sadly, things get even more tricky than this.
Typically that 6.25% maxing out is with respect to fully throughput. If the work was a stream, it would be about how much water flows through per unit of time. However, music is not about throughput, it’s about timing. If the CPU gets stuck for a small amount of time working on a burst of work, then that delay typically doesn’t matter too much to you. However, for music that means that the next bit of work (e.g. playing a drum) will be late and out of time.
This means that if a sudden chunk of CPU work blocks the program from working for a bit this can cause timing issues. Note that this chunk of activity might not even register much on a CPU monitor because it might have been in a fairly small period of time - yet still long enough to interfere with timing.
Also, different CPUs and firmware options can be very aggressive about saving energy. This is often achieved by switching CPUs on and off and doing short bursts of work. This might be fine for achieving a decent throughput of activity but doesn’t play well at all with sensitive timing systems like Sonic Pi. This affects laptop users particularly and we’ve noticed people getting better results by disabling any energy saving preferences whilst using the app.
Bios, and windows speed step, speed shift OFF. Maximum performance. Overclocking. My CPU and configuration maximum performance. Another music editor (fruity, reason) highest sample level per second with high precission multiple effect and VST plugins same time!
My CPU FP capacity is high. Normal and AVX computing…
Check benchmark first comment.