Hello everyone! My first post here so be kind.
I’m really enjoying this piece of software, and wanted to have a go at combining it with another favorite of mine, processing. I’ve been able to send OSC messages to sonic pi from processing, but I’m having a hard time sending messages from sonic pi to processing.
I’ve tried different variations of “localhost”, my local IP and the good old 127.0.0.1 but none of them seem to do the trick.
My installation is from the official Arch repositories.
I’m really new to the whole OSC thing, so it’s most likely me messing something up, but I was wondering if someone had some simple working code examples they would be willing to share with me.
I’m approaching tearing out hair level.
What platform/OS are you working on? Is your processing sketch on the same machine as Sonic Pi?
I’ll try a few experiments here, and check out if my code is still OK .
Tried on another computer running windows, your code worked fine, so there’s something weird going on with my linux laptop, I’m no networking wizard but I’m guessing the problem may be there, have to investigate further.
I’ve experimented using the oscdump utility from the liblo package, and nothing shows up there either. Could there be something going with the Sonic-Pi that’s in the arch repositories?
Try running this test code. It sends data via OSC from Sonic Pi back to itself
use_osc "localhost",4559
live_loop :sendtest do
d=[0.2,0.4].choose
osc "/play",rrand_i(48,84),d
sleep d
end
live_loop :receivetest do
n,d = sync "/osc*/play"
play n,release: d
end
That should check if OSC messages are being sent and received.
can you see any osc cues in the cue log?
IF not try clicking the tick beside enable OSC server in the prefs IO section.
Turn it off then on again and rerun the program.
IF it was Off already then that is probably the problem.
If the program doesn’t work looks like there is something wrong with your SP
I’ve tried turning it off and on again
Maybe I’ll have a go at compiling the whole thing from source and see if that helps, I’m no linux wizard, but I’ll try!
Thanks again for trying to help me out!
IF you build latest 3.2dev then beware of several changes to port allocation, and also there IS a bug there still to be sorted where you DO have to turn OSC server off then on again before OSC messages work, by clicking the box in the IO preferences.
Also Sonic Pi receives messages on port 4560 not 4559 as in version 3.1
Also received cues coming in to sonic pi contain additional info
if you send “/play”,60 the cue you receive in the cue log looks like /osc:127.0.0.1:4561/play [60]
To sync this you can use
n = sync "osc*/play"
n=sync "osc/play" will NOT match
The * matches all the extra stuff which you don’t normally need.
A final change is that some other ports are dynamically allocated, including the server Listen port which receives osc commands from the gui to Sonic Pi. The actual value allocated is shown in the server-output.log Since this port is used by programs like the sonic-pi-cli command they will be broken.
I discussed this, and the post of an updated version here
This whole compiling business is way above my level of computer wizardry, been hacking away at error messages and finally got to the point where I’m going to issue the final make command, but it fails with some deprecated declaration.
Think I need a pause from this to keep the few bits of sanity I have left.
I am really sympathising with your last post. I sometimes also just need a break. Technology can be very frustrating and tiring - sometimes… then again joyful bliss about things that finally work …
The problem is I haven’t built the version I’m running myself, it’s installed from the arch repositories. I’m guessing the compilation of the erlang files would only have effect if I compiled it from source myself?
Follow the build instructions in …/osmid-master/INSTALL.md
Copy files m2o and o2m to [SonicPiInstallation]/app/server/native/linux/osmid] (you will have to check were these files lie in your current installation; I am not sure that this information is still right)
This might be worth a try … once you’ll have paused a bit
I can sympathise with how you feel. Recently I spent several weeks trying to debug my build of 3.2dev on a Mac. Very frustrating, but I got there in the end. Turned out that the boost library I was using had been upgraded! Once I adjusted it to be the same as the one used in SuperCollider all was well again.
One word of caution about doing your own build on the latest 3.2dev source. recently there has been a revision of the layout of files in the gui/qt folder. Make sure you base your build on a recipe which is up to date. The post I did recently about building on a Raspberry Pi4 gives an indication of what is involved, although it would have to be tweaked for archlinux.
