OSCQuery support in QLC+ ?

[jcelerier]

Hello,

I am the developer of https://github.com/OSSIA/score, a sequencer for OSC and other show control protocols. We have been working with the guys at VDMX, Millumin, MadMapper, and Vezér to provide a protocol (OSCQuery) which allows remote discovery of the OSC endpoints of a software over HTTP & WebSockets.

I'm opening this issue to ask you if you would be interested in the contribution of the protocol implementation into QLC+ ? Basically, it would allow other OSCQuery apps to find automatically which parameters are automatable through OSC, what are their bounds, units, give them a pretty description, control them through a web browser, etc.

Here is a high-level overview of the protocol :

• https://vdmx.vidvox.net/blog/new-vdmx-update-with-oscquery-ndi-and-more

The protocol spec :

• https://github.com/Vidvox/OSCQueryProposal

And the implementation we work on, which depends on C++14 & boost (an API without any use of boost in the public headers and restricted to C++98 is provided, but if you already use boost the more low-level API which uses some boost types is more efficient):

• https://github.com/OSSIA/libossia

The reason why I'm asking for this is simple: some would really like to have a DMX implementation in ossia score, but I think that it would be better to have some synergy between free software used for show control :) (especially when they share a fairly similar technology stack!)

Best,
Jean-Michaël

[mcallegari]

Hello Jean-Michaël, thanks for reaching out.
OSSIA score looks like a neat software, plus it's open source, so it's all cool :)
I'm not sure how it fully works though, maybe you can describe an example scenario where you imagine QLC+ would fit in ?

The "input hooks" situation in QLC+ is this:

• QLC+ 4 and 5 have several input plugins but they're tailored to implement a simple "trigger" usage and don't have any access to the UI. So basically the only thing you can do is: set value X on channel Y
• QLC+ 5 (WIP) on the other hand has a component called "Tardis" which does 2 things: undo/redo and network master/slave mirroring. At the moment, around 100 actions are implemented in Tardis and most likely that's just 50% of the whole work.

Looking at the VDMX video you shared, it seems OSCQuery would better fit in the seconds case, where a network protocol has access to ALL the software features. Right now I'm using a custom network protocol that I invented from scratch and with that I already do what you see in the VDMX video.

Let's discuss this, but please consider the following:

• at the moment I'm busy on a huge architectural rework that will take a few more weeks to end, so I can't commit to anything else right now
• is OSCQuery license compatible with Apache 2.0 ? Linking libraries always raise this topic
• how about security ? My network protocol has a minimum knowledge of authentication and encryption. No security means no go for me, as I won't open my software to an alien network protocol that anyone can use to mess up with someone's work
• QLC+ 4 is C++98 while the QLC+ 5 UI makes use of some C++11 features. To be honest I do not intend to use boost, as Qt is more than enough to deal with all the C++ features.

Cheers for now

[jcelerier]

I'm not sure how it fully works though, maybe you can describe an example scenario where you imagine QLC+ would fit in ?

so, the idea I had for it was : making available the UI surfaces created in the virtual console and the functions in "simple desk" through OSCQuery (I don't know QLC+ enough to say if other places would be interesting or useful to remotely control).

QLC+ 4 and 5 have several input plugins but they're tailored to implement a simple "trigger" usage and don't have any access to the UI. So basically the only thing you can do is: set value X on channel Y

that's the plug-ins in the Inputs/Outputs tab right ? I actually think that it would be a very good first step to have it there since the original point is that it should be able to be used as a drop-in replacement of OSC.

I don't think that OSCQuery is very well tailored to distributed document editing over multiple replicas though - it's really meant to control floats and stuff like this.

at the moment I'm busy on a huge architectural rework that will take a few more weeks to end, so I can't commit to anything else right now

indeed, I am proposing to write the code !

is OSCQuery license compatible with Apache 2.0 ? Linking libraries always raise this topic

heh, that's the hard point. OSCQuery itself is just a protocol which uses http / websocket so any WS lib works. But the implementation I work in is under LGPL, is it compatible with Apache 2 ? Though if it's loaded as a plug-in I'd wager that it's not a problem at all considering that you can have proprietary software with LGPL plugins.

how about security ? My network protocol has a minimum knowledge of authentication and encryption. No security means no go for me, as I won't open my software to an alien network protocol that anyone can use to mess up with someone's work

the implementation I work on (libossia) does not support this yet, but since it's websockets, SSL certificates can be used. The reason why it does not supports auth as of today is because I don't want to go through the pain of linking OpenSSL on mac / windows / linux right now, but it may very well come at some point :p

QLC+ 4 is C++98 while the QLC+ 5 UI makes use of some C++11 features. To be honest I do not intend to use boost, as Qt is more than enough to deal with all the C++ features.

indeed, so I really think that the plug-in approach which does not disturb your code base would be for the better.
In order to do it properly, here's the information which would be useful to have from the plug-in interface :

• the name of the controlled object (e.g. the name of the slider)
• the type of the value (float, int, RGBA color, bool (for toggles), "impulse" (for push buttons))
• the range (e.g. [0 ; 127] for instance)

would these be hard to add ?

[mcallegari]

at the moment I'm busy on a huge architectural rework that will take a few more weeks to end, so I can't commit to anything else right now

indeed, I am proposing to write the code !

Good to know !

is OSCQuery license compatible with Apache 2.0 ? Linking libraries always raise this topic

heh, that's the hard point. OSCQuery itself is just a protocol which uses http / websocket so any WS lib works. But the implementation I work in is under LGPL, is it compatible with Apache 2 ? Though if it's loaded as a plug-in I'd wager that it's not a problem at all considering that you can have proprietary software with LGPL plugins.

Funny/sad thing. Apache 2.0 is compatible with GPL, but GPL is not compatible with Apache 2.0.
Plugins do not resolve that, since (I've been told) once delivered in binary form, a software must not be "contamined" with mixed licenses. The (only) real solution would be to distribute QLC+ as it is, and leave to users the option to install a separate OSCQuery plugin. So they'd be in charge of mixing licenses and eventually destroy their computers...(that's what happens right ? 😆 )

QLC+ 4 is C++98 while the QLC+ 5 UI makes use of some C++11 features. To be honest I do not intend to use boost, as Qt is more than enough to deal with all the C++ features.

indeed, so I really think that the plug-in approach which does not disturb your code base would be for the better.
In order to do it properly, here's the information which would be useful to have from the plug-in interface :
would these be hard to add ?

Not feasible. As I said, I/O plugins are tied to the QLC+ engine and know nothing about upper layers, e.g. Virtual Console and Simple Desk. That's why I thought about a UI-level approach for QLC+ 5, and in this case security becomes quite a concern.

[jcelerier]

Funny/sad thing. Apache 2.0 is compatible with GPL, but GPL is not compatible with Apache 2.0.

hmm, I don't really understand: you are using Qt which is also LGPLv3 or GPLv3, how is it different ?

The (only) real solution would be to distribute QLC+ as it is, and leave to users the option to install a separate OSCQuery plugin.

well, that would be a good starter which would not break anyone's machine !

I think that the best course of action is to let you finish QLC+ 5.0 without disturbance - in the meantime I'll start looking at the plug-in API. The thing can certainly be useful as a plug-in for some time, and if at some point you feel that it would be a nice feature to have in other parts of the software, well, it will always be possible to look at a deeper integration

[mcallegari]

Funny/sad thing. Apache 2.0 is compatible with GPL, but GPL is not compatible with Apache 2.0.

hmm, I don't really understand: you are using Qt which is also LGPLv3 or GPLv3, how is it different ?

True, but please let me refine my statement: a Linux package in binary form cannot enter distros repositories (already seen on Fedora) if they include mixed licenses. In fact the QLC+ Linux Debian package doesn't include Qt, but it includes plugins cause they're part of the QLC+ source tree.
On Windows and macOS I bundle Qt as well, and yes, there might be a license mix.
However, Qt itself includes Apache 2.0 components: https://doc.qt.io/qt-5.11/licenses-used-in-qt.html
I'm not a license expert and probably never will, but licenses is a very foggy and confusing world.