native OSC interface

[dvzrv]

I conceived a native OSC interface in the course of my thesis.
It uses UDP (as TCP seemed unnecessary overhead) and has a certain notion of a client/server architecture, which allows clients to be subscribed to server instances, while receiving their messages according to certain message levels.
Most of this is still best explained in my thesis itself, as I haven't gotten around writing the manual for the interface (for the official ssr documentation) yet.
However, the interface relies on liblo 0.29 (released last month) and you can try it the following way:

git clone https://github.com/dvzrv/ssr
cd ssr
git merge --no-edit \
  origin/networking-with-osc \
  origin/configuration-client-server \
  origin/sclang-workflows \
  origin/tests-osc \
  origin/fix-orient-source-toward-reference \
  origin/fix-ip-interface-for-gcc7 \
  origin/configure-qt4-patch \
  origin/reproduction-with-hostnames \
  origin/alien-loudspeaker 
export PATH=/usr/lib/qt4/bin:$PATH # select wherever you have moc-qt4 (or however it is called on your distribution)
autoreconf -vfi
export QT_SELECT=4 # Arch specific
export CPPFLAGS="${CPPFLAGS} -D_REENTRANT" # fixed in #92

./configure --prefix=/usr
make

The build steps are Arch Linux specific (especially the Qt4 stuff and the things relating to gcc > 7.0), but should be fairly translatable to other Linuxes.
All test cases are done using SuperCollider.

Anyways... as I'm finished, I'll start some form of code cleanup and documentation for the manual and would be happy to see this be merged eventually.

Enjoy

[mgeier]

Thanks a lot @dvzrv!

I currently don't have the time to check this out, and the next few weeks I'll be away on holidays ...

I'm always interested in the TCP vs UDP discussion ... do you have some further insights or did you just assume the TCP overhead is bad?
And what's the worst case that can happen if a message is lost or the order of some messages is scrambled?
Or can we assume that this never happens on LANs?

Anyway, I think it would be good to make a new SSR release first and then concentrate on adding new features.

Is there any part of your many branches that should be merged before making a new release?

If yes, it would be great if you could make separate PRs for that!

[dvzrv]

@mgeier you're welcome! Hope it will be useful. It was very useful to me already (have been using it for the creation of pieces for quadrophony, etc.).
Enjoy your holidays!

UDP is the standard used, when working with the liblo library, although it can also facilitate TCP. The former being pretty much the standard used in all other implementations I looked at (e.g. python-osc, SuperCollider). However, some also offer the possibility to use the latter, but that usually seemed more complicated.
I disregarded TCP (for now) because of the overhead in setting it up in other implementations.
Additionally, I don't have the feeling one can experience package loss, when in a closed environment and working with Gigabit NICs. This of course should be tested with large scale setups, with many many clients. I just didn't have the possibility for such a testcase sadly.

Anyway, I think it would be good to make a new SSR release first and then concentrate on adding new features.

I agree. Qt5 should be the first thing to merge!

Is there any part of your many branches that should be merged before making a new release?

Definitely the ones I have made a pull request for already, but probably also one, that is not part of the ones above, which extends the current install/build documtation, makes it a little more generic and adds information for Arch Linux.
I stopped working on it, as I didn't have much time, but it would probably be a great addition for a new SSR version release!
I will create a pull request for it asap, but it might still need some fixing.

As liblo 0.29 was just released, it might take some time to arrive in more conservative distributions, such as Debian. Even Arch might take some time, although I already provided a new install script to the maintainer. Therefore it might be wise to wait for a little bit... which also gives me some more time to clean up things and maybe merge some of the branches.

Regarding the different branches: networking-with-osc and configuration-client-server are providing the new functionality. tests-osc and sclang-workflows provide SuperCollider scripts for workflow examples and tests (they are additionals and provide good examples, but I have not added them to the build system yet). reproduction-with-hostnames and alien-loudspeaker work on some concepts discussed in #72, therefore they are not needed (yet).

[dvzrv]

It seems, that this builds just fine on Ubuntu Studio LTS 16.04 (just tested at the Electronic Studio at TU).
I cleaned up the above instructions a little, as they had some useless stuff in there (taken from my PKGBUILD install script).