# RPI 3 B +
# Version from repository does not do this
for i in 0..3
play 84, release: 0.1
sleep 0.6
end
loop do
synth :fm, note: 48
sleep 0.3
endI’ve had a play with this on a Pi 3B+ and you can solve the timing in the first 4 notes by slightly increasing the sched ahead time
use_sched_ahead_time 0.7 worked for me. (as the first line)
SP does tax a 3B more than a Pi4 that’s for sure. At present all RPi have the same default sched_ahead_time which is currently at 0.5
You may have to set it higher for certain programs.
You can reset the default also using for example set_sched_ahead_time! 0.7
Alternatively a short sleep at the start of the program works eg sleep 0.2
Is that due to the ’ .3 ’ or the ’ .deb ’ ?
I’m not sure what you mean by this.
The deb is just a way of packaging a build of Sonic Pi 3.3 It is as if you build it from source yourself and move the installation folder to /opt/sonic-pi It doesn’t of itself affect the running of Sonic Pi.
Not sure what you man by the .3 Is that the version number 3.3?
It is a different version of Sonic Pi, but the main changes affect the use of midi and not so much a program like yours. What is different is the audio path as the Foundation have switched to setting up the Audio System to use pulseaudio, and this requires different routing so that the output of the jack system Sonic Pi relies on can be routed to pulseaudio. This does affect the latency a bit. It is possible to switch back to just using Jack with the help of the program QjackCtl. I hope to produce some articles for power users to show how the sound can be reconfigured in this way in the next few weeks. However you will get much better performance with a Pi4. Having said that, the Pi3B+ will play the example programs supplied with Sonic Pi OK.
In all programs there is some setup time at the start of a run, where the code is sent from the buffer to be parsed then run. Your program has a very short time interval between the first tow sounding notes and I think this is where the timing problem occurs. Using the long schedule ahead time (or an initial small sleep allows it to proceed satisfactorily.
Other things that can help give better performance, are switching of the log and cues log, and switching off the scope (which uses a fair bit of cpu load on the Pi3B+)
EDIT what version and raspberry pi OS were you using with the program before?
What version and raspberry pi OS were you using
with the program before?
I ’ ve been using Stretch ( with 3.0.1 ? )
( And may continue )
For reasons other than SPi , I would like to go to
Buster ( Hence trying your . deb one more time )
3.0.1 comes with Buster , but with attendent problems .
( I …! SO !.. wish You would use Your talent and
knowledge to fix that situation .
I also now see that the graphic issue I mentioned
before is part of 3.3 , and not just Your .deb
( The Windows version is identical )
the main changes affect the use of midi and not so
much a program like yours .
Are there any type repositories of past versions ?
SPi means so much to me , but it appears to be
( for my purposes ) , degrading .
@robin.newman I believe he was still
using 3.1 on Raspbian Stretch.
Sans the big graphic flash as 3.3 opens … Yuk !
rant 
3.01? Oooh, even earlier than I thought!
What do you mean by big graphic flash?
As mentioned previously you are likely going to be out of luck with any updates to earlier versions - re the Raspberry Pi version, I can’t speak for Robin on this, but he may well be kept busy supporting current and future development, let alone backporting anything.
Besides the new graphical UI theme, was there anything with the latest version of Sonic Pi that you were holding off upgrading over? There’s probably much more chance of having updates made to current versions as opposed to previous ones.
What do you mean by big graphic flash?
As 3.3 opens there is a moment of ???
on the screen … Someone mentioned before
it was when " ??? kicks in " ( some sort of graphic enhancement )
was there anything with the latest version of Sonic Pi
that you were holding off upgrading over?
There wasn ’ t , but now the timing issue …
SLEEP at the beginning works , but an obvious kludge .
I am reminded of the evolution of Windows …
As it became bloated and slower it was advised to
buy faster P . C . s …
I probably need to devote a SD ( maybe even a work station )
to Stretch w / SPi ( and hope the Raspbian repository remains
intact )
I have Stretch on a USB stick , but for some reason it seems
to degrade after a few uses …
Or sadly go to Midi myself ( Then I would not need SPi ) …
BUT my sound has become dependent on SPi …
Life Is So Complicated …
hi @hitsware
sometimes a screenshot is worth than words 
(How to take a screenshot on Raspberry Pi | iMore) to share what you see.
Cheers
IIRC he was talking about the slight jitter when Compton kicks in to provide transparency (though I might be wrong)
Yes there is a screen jitter as Compton starts up. This program which is unique to the raspberry pi version is needed so that the transparency option will work. On other platforms it works witout this. If you don’t want to use the transparency option you can remove the Compton package using.
sudo apt remove compton
SP will still run but you will get a warning in the logs saying that Compton is needed to run the transparency. (You can of course reinstall it at any time)
For what its worth, I’ve just tried your original progarm on a Raspberry Pi 2B, and it runs OK, but I do have to set the sched_ahead_time to 2. It will run all the example programs as well with this same setting. However, although SP runs on the machine it is not a very smooth experience, and you are best cutting down on resources like the scope and the log displays.
To put this into context, running the chrome browser on a Pi2 is also very slow, although it will load a page eventually.
Also, Sonic Pi 3.3 exploits the features of such machines as the latst Mac or Windows 10 machines, so it is actually pretty amazing that the same program will run on a lowly Pi2 with 1Gb of ram. at the same time as chrome browser and vncserver!
2 Likes