This is another maintenance and bugfix release - primarily addressing a critical issue with configuring external sound cards for audio input. This was accidentally introduced in v4.2. An issue with the auto-indentation preference in the GUI has also been addressed.
The GUI is now restricted to having one instance open at any one time. Having multiple instances of Sonic Pi running simultaneously can cause conflicts. This is now no longer possible, which should reduce any issues users may have observed when accidentally opening the app multiple times in quick succession. Now, only the first instance will open and all the subsequent others will exit before starting if they detect another instance already running.
GUI
Restrict running instances to only allow one instance of Sonic Pi to be running at any one time on a given machine.
Translations
Improvements to the Dutch, Estonian, Japanese and Polish translations.
Bugfixes
The behaviour of external audio card configuration should now be as it was in v4.1.
The auto-indent preference in the GUI now works as expected. Unchecking will stop the GUI from automatically reformatting the code.
Hi Sam,
Great joy about v.4 and the new feature of the Remote OSC!
But how does it work? I mean, if all devices/computers are on the same network and sending OSC messages, why don’t they appear in the cue log? Did i miss anything? Do I have to write any extra line in the editor in order to listen to and sync them? Happy for any advice.
I’m really excited about v4 too - although I fear I haven’t done a good enough job yet of explaining what it does!
To be clear, v4 has no major changes to the OSC functionality. I’m not quite sure where you might have heard of “Remote OSC” but it’s definitely not a feature I’ve been working on or talking about. OSC is already remote in that it allows you to send a message to any remote computer if you know the IP address.
Instead, the headline feature of v4 is the new Link integration which effectively is a complete rewrite of the internal timing system to work seemlessly with Ableton’s open source Link technology. You can read more about this in the v4 release notes here: Release Link · sonic-pi-net/sonic-pi (github.com)
In this release, the internal timing algorithms have been completely refactored to enable them to link to a new global metronome. The GUI now features a new metronome panel which will let you dynamically change the BPM of your code whilst it is running . You can also use the new “Tap Tempo” button to click out a tempo and Sonic Pi will automatically shift to play in time with your taps. Additionally, you can link the metronome with other versions of Sonic Pi running on other computers connected to the same network (wifi or ethernet). This means it is now possible to gather some laptops together to form an ensemble or turn a whole classroom of computers into an orchestra of live coders - and for everyone to be in time with each other. You can even dynamically change the BPM for everyone on the network whilst code is running on everyone’s computers independently and everything maintains synchronised and in time . It’s a real jam.
In a nutshell, v4 includes a whole new timing engine which defaults to the new Link mode which is set to 60 bpm by default - so it behaves just like v3. Most people using v4 probably don’t even know they’re using a whole new timing engine
However, unlike v3 you can now change the bpm globally for all threads in link bpm mode using the new GUI metronome. You can also press the ‘Link’ button to enter network mode which will sync the BPM with everyone on the network. Finally, you can start your code with the link function which will act like sync where it will block the current thread until the next down beat. This lets you sync the beat phase as well as the BPM!
Sam has answered this for you. If you are interested in commands being sent simultaneously to several computers all running Sonic Pi on the same local network this can be done with the aid of an additional python script. You can see this code here and I used it in a major project to enable a Broadcast Sonic Pi Orchestra
You can also use the link features in the latest Sonic Pi versions to sync different Sonic Pi instances together.
Thank u both for your quick reply. Oh well, so i kind of missunderstood the naming
But yes, I remember @samaaron ! We used it for bpm-link in our session here in Dresden and thats a really fantastic feature for collective jam. Exactly @robin.newman, it needs additional pythonscript to broadcast osc-messages from my sensors in SP. Works well!
I published our work of broadcasting OSC-Data here: neueraeume / phronesis · GitLab
Yes, indeed - we used a very early prototype of the Link functionality in Dresden. v4 is effectively includes a fully polished version of that functionality
Another feature of note is this bug fix:
Fixed encoding issues when saving/loading files containing non-ascii characters on Windows.
This was the issue you observed in Dresden when trying to save a file with umlauts in it.
Out of interest, would it be possible to describe what a “Remote OSC” feature might look like? What would you like it to be able to do and how would you interact with it?
I held a workshop on data sonification with SP the other day. For the computer scientists among the participants, it was no problem to install python-osc via the console. But the musicians, amateurs and artists often did not succeed. The hurdle was too high. Remote-osc was a clumsy expression, of course I meant osc broadcast to make this possible without an additional python script in SP would be great, but I have already read in some of your replys on the subject that SP is not actually designed for data sonification.
Definitely feels like something worth discussing a bit more. Could you describe in more detail what you’re actually doing? Would it also be possible to “sketch” the kind of code you’d like to be able to write and what it would do?
Took a while to figure out… My ESP32 sends OSC messages to the host running SonicPi. Those messages are not picked up by SonicPi. This Python script will capture these messages and forward them locally: osc-server/osc-relay.py · master · neueraeume / phronesis · GitLab
Probably for security reasons, Sonic Pi seems to ignore OSC messages from other computers? Is this an intended behaviour?
So basically i don’t want to rely on this Python script. Instead SP should be able to receive the OSC messages. If you don’t want to implement a general „allow all“ policy, something like a list of allowed IP would be a viable solution too.
Yes, absolutely. By default Sonic Pi does not listen to any OSC comms from other machines. To do this, you need to explicitly enable it in the IO tab of the preferences:
