I’ve compiled sonic-pi from git on ubuntu 16.04. This was relatively straightforward, although it needed a few outcomments. I’ll post about that later and probably in another category.
Currently I’m trying to get OSC reception working. So far it worked sometimes within spi (not very reliably) and never when sent from an external Python3 program on localhost. That external program (using python lilblo) successfully sends OSC back and forth between other OSC programs.
Sending OSC from sonic-pi to an external Python3 program works like a charm.
I’ve tried changing ports, switching OSC server on/off, switching the ‘Receive remote OSC messages’ option on/off.
Anyone got any hints as to what else I could try?
spi-code:
live_loop :foo do
use_real_time
data = sync "/osc/trigger/prophet"
synth :prophet, note: 70, cutoff: 100
end
Do you see any incoming messages in the cue window? You shouldn’t need to write a single line of code to verify that messages are being correctly received
Yes, OSC messages from external programs on localhost (Python, C++) give cues, e.g. like this:
/osc:127.0.0.1:4560/trigger/prophet [70]
I tried putting a single int in a message, or a blob with a single int or char or a blob containing multiple numbers and though I see the cues, they don’t seem to trigger the sync in the live_loop. Could be a matter of formatting… I know OSC is quite picky when it comes to getting the address and parameters right.
My expectations may be incorrect. Given the code above, would you expect the osc message “/trigger/prophet”,70 sent from within sonic-pi trigger the sync in the live_loop? That doesn’t even work in my case, even though I see cues of the exact same format as when they are received from external programs.
I’ve done a pull request for a suggested update of the documentation for version 3.2dev onwards so that others aren’t caught out by this. Sam made this (breaking) change earlier in the year, I think so that he could differentiate osc messages coming from different ports on the same IP address. It adds additional filtering, though most users probably won’t need (or use) this. The bottom line is use /osc* rather than /osc (as in the previous documentation) and this will work for both 3.1 and 3.2dev onwards.
@marcg sorry for any confusion with the docs, but my advice is definitely to build a tagged release rather than master to avoid this kind of confusion in the future. Things are often in a state of flux in development and the documentation can easily get out of sync
I’d be very grateful for that 'cause currently I am also working with Ubuntu 16.04 (Mint). I recently tried to compile but had some issues (I can’t remember exactly, what it was).
actually building from source was quite straightforward, but it failed towards the end of the build script when it started complaining about missing a scintilla shared lib and somewhat later compilation broke on some aubio functions.
The scintilla problem was due to a duplicate mention of libqt5scintilla2-dev, I think this has already been fixed upstream.
The most prominent changes I made were outcommenting some lines in ‘app/server/ruby/vendor/ruby-aubio-prerelease/lib/aubio/api.rb’:
as compilation failed on these. It didn’t seem to have negative effects so far…
I also removed the ‘-y’ switch from apt-get in ‘build-ubuntu-app’ to keep control of things. I made sure all dependencies were met and checked some shared libs.
I’ve made a snapshot of the code that works for me: https://www.dinkum.nl/martin_sho5Rae7Af8kae3i
and left out the folders etc, bin and .git to save space. You can try cloning the sonic-pi repository again, copy my folders over it and see if it builds on your system, or don’t rebuild and just use the app/gui/qt/sonic-pi executable.
No problem Sam, I appreciate your help. I’ll use a tagged release next time or dig into the code.
After Martin Butz’s presentation last week at Sonoj Convention I’ve been playing with sonic-pi quite a bit.
I’m impressed and seriously consider using it for some of my programming classes in the near future.
ok, after installing a few missing programs (such as samplerate) and 2 more compilations the build-ubuntu-app-started compilation complains about lqscintilla:
/usr/bin/ld: cannot find -lqscintilla2_qt5
collect2: error: ld returned 1 exit status
Makefile:232: die Regel für Ziel „sonic-pi“ scheiterte
build-ubuntu-app says:
### IF YOU HAVE PROBLEMS WITH qscintilla2
#cd $SP_APP_SRC/../../../../
#wget 'http://sourceforge.net/projects/pyqt/files/QScintilla2/QScintilla-2.9.2/QScintilla_gpl-2.9.2.tar.gz'
#tar -xf QScintilla_gpl-2.9.2.tar.gz
#cd QScintilla_gpl-2.9.2/Qt4Qt5/
#/usr/lib/x86_64-linux-gnu/qt5/bin/qmake qscintilla.pro
#make
#sudo make install
But I am not sure if this is what I do. Probably a symbolic link would do it, because it seems to me I have qscintilly installed. Do you have any recommendations at this point (if I can bother you with that)?
Have a look in the Makefile Martin, there is a line with LIBS. In the version I had, the libscintilla library was mentioned twice under slightly different names. I removed -lqscintilla2_qt5 and kept -lqt5scintilla2, resulting in:
