fundamental/rtosc

Realtime Safe OSC packet serialization and dispatch

RtOsc - Realtime safe OSC Messaging

A realtime safe library for handling OSC messages. This library is influenced by liblo and libmapper.

Project Goals

• Provide a simple means of handling OSC messages within an application

• Provide a flexible method of dispatching OSC messages payloads

• Create a C library with C++ wrappers for ease of use

• Allow legacy code to have readable RT safe messaging added on

• Keep networking outside of project scope

Why?

Well if an application is going to receive nice serialized messages in the OSC format, then it would be nice if these messages could be dispatched within a realtime thread. This is not possible with any observed C OSC implementation, so this is an attempt to alleviate this issue without creating an entirely hideous API.

Status

• OSC 1.0 spec consistent implementation of all message types, and bundles

• Lightly tested liblo based implementation verification

• Working C++ based dispatch system

• C++ Serialization System

• C++ Syntax Sugar

Documentation

• To see the guide, you can use asciidoctor Guide.adoc in the doc directory

• To build doxygen docs, use make rtosc-doc in your build directory

Todo

• Increase test coverage over C++ layer

• Provide standard compliant path/pattern matching algorithms

rtosc's Issues

Clarify apropos() in some form of documentation

Clean up the C core

Most stuff from the default-value branches should go into the cpp files, except for the time functions.

fat-message test fails on big-endian architectures

The fat-message test fails on big-endian arches as observed here:
https://buildd.debian.org/status/fetch.php?pkg=zynaddsubfx&arch=mips&ver=2.5.4-1&stamp=1465980124

 7/18 Test  #7: fat-message ......................***Failed    0.01 sec
ok 1 - Generating A Message With All Arg Types...
ok 2 - Checking 'i' Argument...
ok 3 - Checking 'f' Argument...
ok 4 - Checking 's' Argument...
ok 5 - Checking 'b.len' Argument...
ok 6 - Checking 'b.data' Argument...
ok 7 - Checking 'h' Argument...
ok 8 - Checking 't' Argument...
ok 9 - Checking 'd' Argument...
ok 10 - Checking 'S' Argument...
not ok 11 - Checking 'c' Argument...
# Error on line 56
#
# Expected:
#0000000: �[30;1m19�[0m                                       .>....4Vx.......
#
# Observed:
#0000000: �[30;1m00�[0m                                       .........#4E.l).
ok 12 - Checking 'r' Argument...
ok 13 - Checking 'm' Argument...
ok 14 - Checking 'T' Argument...
ok 15 - Checking 'F' Argument...
ok 16 - Checking 'N' Argument...
ok 17 - Checking 'I' Argument...
ok 18 - Verifying Message Is Valid...
#1 test(s) failed out of 18 (currently passing 94.444444% tests)

The problem is that since sizeof(char) == 1, the line CHECK(c,i,8); only compares the first bytes of the operands. On little endian arches this happens to pass, but on big-endian the first byte of a int containing 25 is 0x00 and not 25.

Add Colorized CMake Config Status

Compilation on precise

Mark,

The c++11 flag seems to break compilation on Ubuntu 12.04 Precise per CMakeLists.txt#L19.

Changing this to c++0x seems to remedy this issue.

The reason I bring this up is our Travis environment over at LMMS still runs on Precise, so if we can tackle this upstream, it will help with the 2.5 integration effort. :)

Fl_Osc_View.H: error: invalid user-defined conversion

example/complex/Fl_Osc_View.H:175, no known conversion
from ‘Fl_Osc_View::populate(const rtosc::Ports*)::<lambda(const rtosc::Port*, const char*, void*)>’
to ‘rtosc::port_walker_t’ {aka ‘void ()(const rtosc::Port, const char*, const char*, const rtosc::Ports&, void*, void*)’}
Same issue exists in example/complex/window.cpp:156.
In ports.h, the fifth parameter of rtosc::walk_ports() is "port_walker_t walker".
(using -fpermissive -std=c++17)

Add Non-Parameter Fields To oscdoc output

also, look into the specification of those [0,x] fields. there's an off by one there.

Build warnings

Compiling the latest zynaddsubfx code in carla results in these warnings, all related to rtosc:

In file included from zynaddsubfx-ui.cpp:51:0:
zynaddsubfx/rtosc/dispatch.c: In function ‘bool is_charwise(char)’:
zynaddsubfx/rtosc/dispatch.c:141:24: warning: comparison is always true due to limited range of data type [-Wtype-limits]
     return (c>=0 && c<=0x7f) && c != ' ' && c != '#' &&
                        ^
In file included from zynaddsubfx-ui.cpp:52:0:
zynaddsubfx/rtosc/rtosc.c: In function ‘rtosc_arg_val_t rtosc_itr_next(rtosc_arg_itr_t*)’:
zynaddsubfx/rtosc/rtosc.c:488:32: warning: missing initializer for member ‘rtosc_arg_val_t::val’ [-Wmissing-field-initializers]
     rtosc_arg_val_t result = {0};
                                ^
In file included from zynaddsubfx-ui.cpp:101:0:
zynaddsubfx/UI/MasterUI.cpp: In lambda function:
zynaddsubfx/UI/MasterUI.cpp:2309:9: warning: operation on ‘label’ may be undefined [-Wsequence-point]
       : last_loaded;
         ^
In file included from zynaddsubfx-ui.cpp:51:0:
zynaddsubfx/rtosc/dispatch.c: In function ‘bool rtosc_match_partial(const char*, const char*)’:
zynaddsubfx/rtosc/dispatch.c:242:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

this is using gcc-4.8 with -std=gnu++0x

More optimal behavior for rtosc_message (possible API break)

Proposed difference is in return value for rtosc_message in case of failure.
For now if buffer is too small, it just returns zero length.
Buffer could be reallocated for bigger size, but that needs new call with NULL buffer pointer just to know required size. However, this size could be returned on actual attempt to fill buffer. No even need to null buffer automatically - if buffer is about to be reallocated, than already received data could be preserved during realloc, and remaining data could be received in addition to already received data (well, if OSC allowes).

Of if this is implemented: mattconte/tlsf#21
then reallocation could be done without actual data movement - for case if osc doesn't support partial message pass in a way, described above.

Bug In Rebinding MIDI Mapping After Unlearning

There appears to be a bug in midimapper.
Perhaps some data isn't cleared on unlearning things properly?

<trebmuh> launching Zyn with the advanced UI (FLTK)
<trebmuh> then, middle-click on the "Pan" rotative knob
<trebmuh> then, moving the "Modulation" wheel on my MIDI-USB keyboard
<trebmuh> ok, the Pan is assigned, and works as expected
<trebmuh> now, I shift+middle-click on the Pan knob on the GUI
<trebmuh> the MIDI control is unlearned. Fine.
<trebmuh> then, I middle-click on the Pan knob and move the modulation wheel on my keyboard (in order to re-learn it)
<trebmuh> something is fishy here : if I move the modulation wheel on my keyboard, the Pan knob goes staight to 0

pkg-config definition correctly setup?

While creating a package of the 0.2.0 release for Arch Linux I ran into some oddities:
When looking at the pkg-config configuration file, it looks like it's not possible to setup libdir to be /usr/lib.

When choosing cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_LIBDIR=lib-DPERF_TEST=ON to have make install the libraries below /usr/lib and not /usr/lib64, the pkg-config file still looks like the following:

#
# pkgconfig for rtosc
#

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}
includedir=${prefix}/include

Name: rtosc
Description: rtosc - a realtime safe open sound control serialization and dispatch system
Version: 0.2.0
Libs: -L${libdir} -lrtosc
Cflags: -I${includedir}

Which in turn produces:

pkg-config --libs librtosc
-L/usr -lrtosc 

I believe, that libdir should rather be the composition of ${prefix} and @CMAKE_INSTALL_LIBDIR@.

To speak in terms of the initial file, this all is generated from:
libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@

Add tests for oscdoc output

Add Forwarding Capiabilities

It's possible that an address may be entirely valid and as such there should be a match, but instead of replying to the message it needs to be forwarded to another ports structure more capable of dispatching the message. (e.g. /load/from_disk:s "huge-file.dat" is given to the realtime ports hierarchy).

Some forward(char*reason_dest) method should be added to rtosc::RtData to help with this case.

Make default-value based savefiles work with PADnote

Just a marker for me to keep track of it.

new release, please!

whistle

Create rtosc::ClonePorts

In the case of mixed rt/non-rt ports, it's advantage to be able to clone ports from a master list using different callbacks.
Some class rtosc::ClonePorts which either is a rtosc::Ports object or is able to generate one would be beneficial accepting in the constructor

1. a constant reference to an existing rtosc::Ports
2. a list of rtosc::Port names and new callbacks

Bad usage of strstr (compiler warning)

From zynaddsubfx build logs (which embed rtosc):

zynaddsubfx-3.0.5/rtosc/src/dispatch.c:293:16: warning: argument 2 null where non-null expected [-Wnonnull]

This references this code.

I'm not sure what the intent of the code was, or what it might actually break in practice, but strstr(foo, NULL) is definitely wrong.

Build rtosc as a shared library

To be used as a system library, potentially being used by more than one project, rtosc needs to be build as a shared library (see zynaddsubfx/zyn-fusion-issues#216 and https://sourceforge.net/p/zynaddsubfx/bugs/184/).

Currently I'm helping myself by plainly changing the STATIC keywords to SHARED in CMakeLists.txt.

It would be great to either build both by default or be able to choose which to build according to an option flag.

[Feature Request] - C extension for Ruby

Hi,

I realise this is a dumb thing to put in a Github issue but I couldn't see a way of contacting you specifically about this project, so I apologise in advance...

I'm working on a Ruby/music project called Sonic Pi which is pre-installed on the Raspberry Pi and is widely used in schools to teach music and coding to kids. Because we support the earlier B+ RPi (800MHz chip) we have to be sensitive about performance and one of the main bottlenecks for us is encoding/decoding OSC messages in Ruby to send from a Ruby server, both to/from SuperCollider and to/from the Qt GUI.

We use a lot of OSC messages and whilst we've optimised and benchmarked the pure Ruby version as much as possible (https://github.com/samaaron/sonic-pi/blob/master/app/server/sonicpi/lib/sonicpi/osc/oscencode.rb) it's still a bottleneck on the older RPis.

I had thought about trying to write an OSC library in mRuby and then use that via FFI which led me to your repos (mruby-osc). Given your experience with OSC and Ruby I thought it was worth a shot to see whether you thought that having a Ruby wrapper for this library (rtosc) was

a) possible?
b) desirable?

Even if you don't think it's a good idea I'd be interested to find out why and so on. In the past I've struggled to see how I could handle varargs from Ruby -> C and I was wondering if this library might have a solution for that.

Thanks for your time and your code.

Documentation for timestamp format

Regarding emplace_uint64 I'm having a hard time formatting the input timestamp in such a way as to produce valid output. As I've read it so far, I need to add the magic number to make the Unix timestamp count from 1900, and then pack the seconds and fractions in a double manually before handing it to rtosc_bundle - is that correct? From that point, is emplace then reversing the endianness?

If so it might be useful to provide some kind of helper function that takes a Unix timestamp as a float or something. If that's not desirable, any advice on formatting would be very welcome as I'm struggling to get this working with my Ruby wrapper at the moment.

Write End To End Tutorial To Augment Sparse Docs

Default values issues

A list of things that has to be done on the default values branch:

• Remove the TODO-default-values file in zyn
• Finish the port checker per #34 . Especially, add a file to the instrumentes that uses all ports (if non already exists) and add this to the port checker's description
• Move path-search to rtosc
• Don't save ports to savefile if they have rProp(alias)
• PAD synth is not saved. The reason: it depends on PADenable
• EQ.cpp's filterports are missing default values
• Scales for insefx and sysefx seem to differ => Patch Pvolume inside the effect classes
• For invalid options that are transmitted to option values, maybe check the broadcast values
• Use # for bundles, not a.
• Tests for zyn effect's presets
• rEnabled vs rExists: clarify/rename? Make a clean function?
• Fix all TODOs that arised in this branch
• Security:
  • Make buffer ovflows impossible in the pretty-scanner and the savefile reader (using safe integer structs and safe buffers)
  • Forbid blobs in savefiles
  • Pointers may only be passed in blobs (how to check this?). Reason: blobs are dangerous: parameter->subobject = *(SubObject**)message.blob_data with an invalid pointer

Update README

The existing readme contains some old TODOs and it makes the project look like more of a work in progress than need be.
It might also be a nice place to show off some of the performance information.
e.g.:

Liblo Read Performance: 78.830000 seconds for the test
Liblo Read Performace:  394.150000 ns per message
RTOSC Read Performance: 32.480000 seconds for the test
RTOSC Read Performace:  162.400000 ns per message
Liblo Write Performance: 118.460000 seconds for the test
Liblo Write Performace:  592.300000 ns per message
RTOSC Write Performance: 34.440000 seconds for the test
RTOSC Write Performace:  172.200000 ns per message

Add Clear To MidiMapper

Error on strdup() not available when using c++11

I got this error when building the code:

rtosc/test/path-collapse.cpp: In function ‘int main()’:
rtosc/test/path-collapse.cpp:6:16: error: ‘strdup’ was not declared in this scope; did you mean ‘strcmp’?
    6 |     char *P1 = strdup("/foo/bar/../baz");
      |                ^~~~~~
      |                strcmp

The problem is the -std=c++11 option to the compiler.
If this option is set, then strdup() is not available.
Changing to -std=gnu++11 fixes the issue for the compilers that support this value.

Add An Operator For Packed OSC

Right now reading from a large collection of 'f' arguments takes n calls to rtosc_argument which involves O(n) time each to resolve. For most normal messages the number of arguments (n) is quite small, but for longer sequences the O(n^2) cost pops up somewhat unnecessarily.

Add Path To Integer ID Conversion Routines

For use within the context of plugins a sequential mapping of the domain of osc paths onto the domain of integers needs to be implemented.
This should be a rather direct operation though it may need some tweaks to keep the mapping dense with respect to mappable parameters and any direct implementation will result in the integer ids changing on pretty much any path addition.

Consider Changing Rtosc::Port.cb To Raw Pointer

std::function isn't really used in practice with these members outside of midi learning. They also create some overhead in both compile time and runtime. While I haven't measured the compile time cost the runtime cost can be observed in the performance test which on the current git HEAD takes 219 ns per dispatch and 192 ns per dispatch with raw pointers. That's about 65 cycles out of 525 or 460. Not a huge gain, but it's something to look into.

EDIT: it looks like that was on debug mode. clang in release mode produces 98 and 91 cycles. gcc produces 36 cycles for both. The point about extra compile time overhead might still stand however.

Don't Optimize In Debug Builds

There's currently a permanent -O2 in the CFLAGS

Option to choose gui backend

Hello.
Not that i develop something on top of it, just wrote gentoo ebuild for it.
For now, without such switch, the only right way is to make ntk hard dependency, without ability to build with fltk, since automagical dependencies are unwanted in such distros.

Add Support for /../ In OSC Paths

Even partial support for this would make programming the UI stuff easier

Add CMake Flag To Disable Examples

If possible this should disable examples for cases where rtosc is loaded as a subproject, though I don't entirely know how to do that at the moment.

Add rtosc_valid_message_p(const char *, size_t) To Core API

build issues

Hi, i would like to build rtosc, here is what i did:

ub64@ub64:~/download/rtosc_git/rtosc/build$ cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so 
-- Found FLTK: fltk_images;fltk_forms;fltk_gl;/usr/lib/x86_64-linux-gnu/libGL.so;fltk 
-- checking for module 'ntk'
--   found ntk, version 1.3.0
-- checking for module 'jack'
--   found jack, version 0.124.2
-- checking for module 'liblo'
--   found liblo, version 0.27
-- Found Doxygen: /usr/bin/doxygen 
-- Found PkgConfig
-- Found Liblo...
-- Found JACK...
-- Found NTK...
-- Found FLTK 1.3...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ub64/download/rtosc_git/rtosc/build

ub64@ub64:~/download/rtosc_git/rtosc/build$ make
Scanning dependencies of target rtosc
[  2%] Building C object CMakeFiles/rtosc.dir/src/rtosc.c.o
[  5%] Building C object CMakeFiles/rtosc.dir/src/dispatch.c.o
Linking C shared library librtosc.so
[  5%] Built target rtosc
Scanning dependencies of target bundles
[  7%] Building C object CMakeFiles/bundles.dir/test/bundles.c.o
/home/ub64/download/rtosc_git/rtosc/test/bundles.c: In function main:
/home/ub64/download/rtosc_git/rtosc/test/bundles.c:34:5: warning: format %d expects argument of type int, but argument 2 has type long unsigned int [-Wformat]
/home/ub64/download/rtosc_git/rtosc/test/bundles.c:34:5: warning: format %d expects argument of type int, but argument 3 has type long unsigned int [-Wformat]
/home/ub64/download/rtosc_git/rtosc/test/bundles.c:34:5: warning: format %d expects argument of type int, but argument 4 has type long unsigned int [-Wformat]
/home/ub64/download/rtosc_git/rtosc/test/bundles.c:46:9: warning: format %d expects argument of type int, but argument 2 has type size_t [-Wformat]
/home/ub64/download/rtosc_git/rtosc/test/bundles.c:46:9: warning: format %d expects argument of type int, but argument 3 has type long unsigned int [-Wformat]
Linking C executable bundles
[  7%] Built target bundles
Scanning dependencies of target rtosc-cpp
[ 10%] Building CXX object CMakeFiles/rtosc-cpp.dir/src/cpp/ports.cpp.o
In file included from /home/ub64/download/rtosc_git/rtosc/src/cpp/ports.cpp:1:0:
/home/ub64/download/rtosc_git/rtosc/src/cpp/../../include/rtosc/ports.h: In member function std::vector<rtosc::Port>::iterator rtosc::Ports::begin() const:
/home/ub64/download/rtosc_git/rtosc/src/cpp/../../include/rtosc/ports.h:127:71: error: could not convert ((const rtosc::Ports*)this)->rtosc::Ports::ports.std::vector<_Tp, _Alloc>::begin [with _Tp = rtosc::Port, _Alloc = std::allocator<rtosc::Port>, std::vector<_Tp, _Alloc>::const_iterator = __gnu_cxx::__normal_iterator<const rtosc::Port*, std::vector<rtosc::Port> >, typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::const_pointer = const rtosc::Port*]() from std::vector<rtosc::Port>::const_iterator {aka __gnu_cxx::__normal_iterator<const rtosc::Port*, std::vector<rtosc::Port> >} to std::vector<rtosc::Port>::iterator {aka __gnu_cxx::__normal_iterator<rtosc::Port*, std::vector<rtosc::Port> >}
/home/ub64/download/rtosc_git/rtosc/src/cpp/../../include/rtosc/ports.h: In member function std::vector<rtosc::Port>::iterator rtosc::Ports::end() const:
/home/ub64/download/rtosc_git/rtosc/src/cpp/../../include/rtosc/ports.h:130:65: error: could not convert ((const rtosc::Ports*)this)->rtosc::Ports::ports.std::vector<_Tp, _Alloc>::end [with _Tp = rtosc::Port, _Alloc = std::allocator<rtosc::Port>, std::vector<_Tp, _Alloc>::const_iterator = __gnu_cxx::__normal_iterator<const rtosc::Port*, std::vector<rtosc::Port> >, typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::const_pointer = const rtosc::Port*]() from std::vector<rtosc::Port>::const_iterator {aka __gnu_cxx::__normal_iterator<const rtosc::Port*, std::vector<rtosc::Port> >} to std::vector<rtosc::Port>::iterator {aka __gnu_cxx::__normal_iterator<rtosc::Port*, std::vector<rtosc::Port> >}
/home/ub64/download/rtosc_git/rtosc/src/cpp/../../include/rtosc/ports.h: In member function std::vector<rtosc::Port>::iterator rtosc::Ports::begin() const:
/home/ub64/download/rtosc_git/rtosc/src/cpp/../../include/rtosc/ports.h:127:73: warning: control reaches end of non-void function [-Wreturn-type]
/home/ub64/download/rtosc_git/rtosc/src/cpp/../../include/rtosc/ports.h: In member function std::vector<rtosc::Port>::iterator rtosc::Ports::end() const:
/home/ub64/download/rtosc_git/rtosc/src/cpp/../../include/rtosc/ports.h:130:67: warning: control reaches end of non-void function [-Wreturn-type]
make[2]: *** [CMakeFiles/rtosc-cpp.dir/src/cpp/ports.cpp.o] Error 1
make[1]: *** [CMakeFiles/rtosc-cpp.dir/all] Error 2
make: *** [all] Error 2

Please help

Static port checking

Apps using RtOsc write their own ports and may be interested in verifying those. This should not be in the code of the apps, but in a separate way, like in a tool. It could be integrated in a schema or oscdoc extractor. Things that could be checked:

• Each parameter that has been changed is being broadcast to other listeners
• rAPPLY is present in the callback
• At most one rDefault macro is inside the metadata
• If rDefault is being used, rParameter might be required, too (this might only be a worth hint though)
• If a port contains option values, it should have the arguments ::i:c:s

More points to be added in this feature request.

Add oscdoc export routine to ports.h

Dispatching is About an Order of Magnitude Too Slow

After Doing some profiling on the ZynAddSubFX use of rtosc even with rtosc set to -O2 -march=native it ends up taking up around the compute time of generating two basic adsynth notes in handling 10 events getting dispatched around 6 levels deep. The good new here is that it should not be too hard to create some huge improvements. Currently the matching code is applied to all elements where the first character matches (which gets some basic gains), but this results in the matcher getting called for many many elements were there are not going to be a match. This creates a basic opening for some sort of quick elimination method based upon the first few characters.

If you consider that all possible paths are equally likely (which is not the case, but it should work as a simplifying assumption), then you can calculate which comparisons on the first few characters have the most expected eliminated elements. I would guess 3 comparisons should be able to reduce the search space to around 1/8 th of what it was previously.

Secondly in order to speed up the actual matching a basic opcode based approach akin to precompiled regular expressions should produce a set of huge gains. In this case we could simply use the opcode set [MEMCHR, LEQ, PATH, ARGMEMCHR] or something similar as right now we have port names encode fixed strings, natural numbers, path status, and fixed argument strings.

Fix Examples Build

CMake should complain when missing *required* dependency is not installed

Running "cmake" inside the project result in following output:

-- Could NOT find FLTK (missing: FLTK_LIBRARIES FLTK_FLUID_EXECUTABLE)
-- checking for module 'ntk'
-- package 'ntk' not found
-- checking for module 'jack'
-- found jack, version 0.122.0
-- checking for module 'liblo'
-- package 'liblo' not found
-- Found PkgConfig
-- Did NOT find Liblo...
-- Found JACK...
-- Did NOT find NTK...
-- Did NOT find fltk...
-- Configuring done
-- Generating done

So, ok, it complains about not finding some packages (ntk, jack, liblo) but still complete the generation of the Makefile.

But then, when running the generated Makefile, I have errors such like:

/usr/bin/ld: cannot find -ljack

After installing libjack-dev, the compilation just ends up fine.

So, in my opinion, we should have:

pkg_check_modules(JACK REQUIRED jack)

instead of just:

pkg_check_modules(JACK jack)

inside the CMakeLists.txt. That way, we clearly see what packages are required and those who are not.

What do you think?

Headers missing in 0.2.0 release

When creating a package of the 0.2.0 release for Arch Linux, I found myself in a situation with many missing header files (not being installed to the filesystem).
The following patch fixes this.

diff -ruN a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt	2019-04-16 01:18:21.000000000 +0200
+++ b/CMakeLists.txt	2019-04-16 21:10:10.934681045 +0200
@@ -251,14 +251,24 @@
             DESTINATION "${CMAKE_INSTALL_LIBDIR}/pkgconfig/")
     endif()
     install(FILES include/rtosc/rtosc.h
-        include/rtosc/thread-link.h
-        include/rtosc/ports.h
+        include/rtosc/arg-val-cmp.h
+        include/rtosc/arg-val-math.h
+        include/rtosc/automations.h
+        include/rtosc/bundle-foreach.h
+        include/rtosc/default-value.h
         include/rtosc/miditable.h
         include/rtosc/port-sugar.h
-        include/rtosc/undo-history.h
+        include/rtosc/ports-runtime.h
+        include/rtosc/ports.h
+        include/rtosc/pretty-format.h
+        include/rtosc/rtosc-time.h
+        include/rtosc/rtosc-version.h
+        include/rtosc/savefile.h
         include/rtosc/subtree-serialize.h
+        include/rtosc/thread-link.h
         include/rtosc/typed-message.h
-        include/rtosc/rtosc-version.h
+        include/rtosc/typestring.hh
+        include/rtosc/undo-history.h
         DESTINATION include/rtosc)
     install(TARGETS rtosc rtosc-cpp
         DESTINATION ${CMAKE_INSTALL_LIBDIR})

Setup RTOSC CI

Open issues:

1. Create liblo release
2. Await new vcpkg release which uses it (might not be required)
3. Merge #72 .

Self assigning this in order to have it listed under "My issues".

Ensure correct lib suffix

It looks like the 64 bit libs are put in the wrong place (lib vs lib64), which can cause all sorts of fun. This should be a quick fix.