This video illustrates the excellent work done recently by Luis Lloret and Sam Aaron to bring Ableton Live link technology to the development version of Sonic Pi. It is planned that this exciting development will be further refined and included in the next release version.
In this video I use copies of the latest development built on my Mac and also on a Raspberry Pi 4 (from the github link branch), and use Ableton Live 10 to control them while they play the Bach example program included with Sonic Pi. This is modified by adding two lines to the Mac version sync "/link/start" and use_bpm :link the second line replacing the use_bpm 60.
The Raspberry Pi version has the same two lines added, plus a third one set_audio_latency! -200 to the Raspberry Pi one, this last line adjusting for the longer latency in the Raspberry Pi so that its audio plays in sync with that of the Mac.
On Ableton I used an empty midi track, but recorded on the master track a varying tempo line, that started at 60bpm and rose linearly after 2 bars up to 120bpm at 12 bars then decayed again in two ramps back down to 60bpm. You can hear the smooth transitions of tempo as the two Sonic Pi instances play together.
This is great! Do you know if it is possible to use this without Ableton? So instead of the “/link/start” message coming from Ableton, it comes from another instance of Sonic Pi? How would the code differ?
Of course, this also means you can take advantage of the new support for Link with multiple instances of Sonic Pi connected to the same network in addition to any other compatible app or gear.
I’m currently working on a GUI metronome interface which will enable you to send link start and stop messages (there’ll also be equivalent API function calls to do the same from code).
I’m openly developing this stuff through the beta program. Beta1 just really represents a technical preview of the Link support. I definitely recognise that there’s plenty more work to be done before this is really polished and ready for a full release.
We did some initial preliminary testing of this feature. No Ableton used, just one Sonic Pi networked with an MPC, an Organelle, some other stuff. The Sonic Pi code used use_bpm :link, no link start/stop.
The good news is, it sort of works. It kept in sync using a metronome live_loop to keep the beat and was usable like that. Real-time bpm changes were erratic; at one point it seemed to respond to them, then it looked like it was not (without having to stop and start); still not sure what the deal is. But, other than that, it was working.
The bpm changes were dictated by other machines on the network. The Sonic Pi log correctly shows /link/tempo-change cues.
Here is a little test I ran just now with the following, rather minimal, example:
use_bpm :link
loop do
sample :bd_haus
sleep 1
end
and another machine on a LAN running Bitwig.
Experiment 1: start Sonic Pi and Bitwig. Run the program. It starts drumming at 120 bpm. BPM changes in Bitwig are super glitchy: increases cause Sonic Pi to think it is thousands of seconds behind, decreases freeze it up (thousands of seconds ahead?)
Restart Sonic Pi… interesting; now tempo is changing as expected. Seems like a temporary issue/glitch with the operating system time or link clock?
However, now
use_bpm :link
live_loop :foo do
puts 'BPM is ' + current_bpm.to_s
sleep 1
end
live_loop :hmm, sync: :foo do
sample :bd_haus
sleep 4
end
does not respond to bpm changes. That is, it will print “BPM is 300.0” or whatever, but keep playing at the same tempo. That is what we were experiencing the other night. Paring it down to
use_bpm :link
live_loop :hmm do
sample :bd_haus
sleep 4
end
is OK again. Putting foo back in while running still OK, then stopping+starting makes it unresponsive again.
Interesting, this definitely needs a bit more investigation. I don’t currently have Bitwig - I’ve just tried things with Ableton Live, Resolume Avenue and some iPhone apps.
I have two main questions at this stage:
Could you try changing the BPM from a copy of Sonic Pi with set_link_bpm! and see if that has the same behaviour.
You mention “BPM changes in Bitwig are super glitchy” - is this something you also observe when Sonic Pi isn’t connected to the LAN? I’m wondering whether it’s possible that Bitwig is doing something unusual under the hood.
Removing the sync does seem to fix it (i.e., changing the bpm works), but does that not defeat the purpose? After all, the metronome loop is not really going to just sleep 1 every time, more like
live_loop :foo do
diff = @tau_api.link_current_time_and_beat(false)[1] % 1.0
latency = 50.0
x = ((1-diff) + 0 - rt(latency/1000.0))
sleepytime = (x > 0.001) ? x : 1
sleep sleepytime
end
In your case, the sync_bpm opt to the live loop isn’t actually needed. This is because all the live loops will start at the same time the first time you hit run, and also given you declared the bpm via use_bpm outside of the live loops, that bpm will be inherited as they start.
Hi, trying to enable remote control of this v4 ableton link version over the internet to allow people outside the room to jam within an ableton link session.
The idea is to use ssh, vim and a VPN to allow this, with the use of sonic-py-tool.
Unfortunately, the ./sonic-py-tool.py start-server command gets stuck on the init phase and then quits. Supercollider never gets started. Also tried setting the ports with --osc-part, --cmd-port.
This is the log output:
The time is 2021-10-02 19:38:14 +0300Warning, you have an older init.rb file in /home/user/.sonic-pi/init.rb which is now being ignored as your newer config/init.rb file is being used instead. Consider deleting your old init.rb (perhaps copying anything useful across first).Using primary protocol: udpDetecting port numbers...
Ports: {:server_port=>4557, :gui_port=>4558, :scsynth_port=>4556, :scsynth_send_port=>4556, :osc_cues_port=>4560, :tau_port=>4561, :listen_to_tau_port=>4562, :websocket_port=>4563}
Opening UDP Server to listen to GUI on port: 4557
Spider - Pulling in modules...
Spider - Starting Runtime Server
studio - initSonic Pi server has now quit(base) user@eight:~/VIM_SONIC_P
What is the difference in how the server is initialized between v3 and v4?
Any experience using v4 with sonic-pi-tool?
Are there better/better supported approaches to control a Sonic Pi instance over internet, eg. can the Sonic Pi GUI be rerouted to communicate with the remote instance?
As for the exact differences in how the server is started since that point, that might be a question for @samaaron, but I can say that we have made significant changes under the hood recently. This includes things like shifting and adding new code into the erlang server, and replacing the entire MIDI subsystem back in v3.3.0. It would not surprise me if the ports have changed in some way since that time also.
v4.0 is still very much in development, and you may already be aware of this, but Ableton link support is only partially complete - there might still be bugs to iron out, and things like phase-syncing are yet to be built
Regarding controlling Sonic Pi remotely - if you’re talking about more than just syncing with or changing the BPM of a remote Sonic Pi instance with Ableton Link, then I could be wrong, but my understanding is that it is not yet possible. There’s a ways to go before we have the code in place to allow remote network control. We have made small steps towards this by separating out much of the API code (for initialising the server, sending commands to the sound engine, etc) from the GUI, to allow flexibility of many types of client programs to connect to the core API and tell the sound engine to make sounds.
Hi @domj As Ethen says there are a lot of changes going on in the internal structure of Sonic Pi in the development versions of SP 4.0
Using command line input has never been documented and is not officially supported, although it can be utilised to a certain extent your own risk. Programs like the Ruby gem sonic-pi-cli and (I think) sonic-pi-tool.py have already had updates applied to change from the earliest version of Sonic Pi which used port 4557 for command input to version 3 which used a dynamically allocated port which could be determined from one of the log files. This should also be possible with upcoming versions, although the location of the dynamically allocated port is in a different location in a different log file now! I have a test setup working at home using this, but have not yet published it, and it can achieve the same as the existing utilities mentioned above. As Ethan says, there is some way to go to allow to full supported remote network control.
I’m not sure exactly which is the latest version of Sonic Pi that sonic-pi-tool still works with, but something like 3.2.2 sounds likely.
I haven’t had time to update it for the more recent versions, and as there still seem to be quite a few changes going on in that area, I’ll probably wait until things stabilise a bit before trying to update it again.
Thanks for all the clarifications, very cool developments, I am glad to see that sonic pi’s architecture is getting more mature. It will open up a lot of integration possibilities once it settles a bit
The ableton link integration might be still wip but it already enabled a couple nice jams over here.
