I have recently stumbled upon this great piece of software called Score Im sure some of you have heard about it. They just had a huge update (audio and midi support, LFOs, step seq… all kinds of good stuff) its all still very alpha like but I think they have some super smart Ideas, and solutions. This kind of sequencer could really have fun with vvvv.
Now… OSCQuery is also in there, can we make vvvv also talk with it? did someone already try that? is it some how related to ctrl+k ?
I had a talk with them today (the score people) and they referred me to these 2 links
libossia
and
ossia
i dont think its related to cntrl+k.
And you just need to know the protocol and you can patch your interface.
receiving should be as easy as using OSCdecoder
@tekcor what do you mean by knowing the protocol?
I know vvvv pretty well but in c++ Im a ignorant redneck… did you look at the links I posted ?
he meant the OSC paths, check out the help patch of OSCDecoder/OSCEncoder. Unfortunately there’s no high level object hierarchy abstraction as with ossia if I understood well. But you don’t need a C++ library for that kind of thing though
@microdee I know OSC, but the advantage of OSCquery is that it automatically discovers all exposed osc addresses. are you saying their method is all about the correct naming of the paths?
ah I thought OSCQuery is a reflection method implemented inside OSC (which tbh would make more sense, why introduce another socket) but it seems to be a HTTP server which you can easily interact with the HTTPGet node, after that you need to parse the OSCQuery message apparently it comes via json so AsElement (json) can help you processing it.
Here’s the OSCQuery protocol: https://github.com/mrRay/OSCQueryProposal/blob/master/README.md
have fun!
1 Like
@microdee ok, I think I understand what you write. but still many things are not clear to me. (I am not really a developer, more of a connect boxes type guy…) I could use some help with this. if there are more people interested in score thats great if not I understand…
Hi people, ossia score dev here,
Parsing JSON data from an HTTP request in a dataflow environment is not something that I’d wish on my enemies :)
I think that the better way overall would be to have a proper integration of ossia in vvvv like we do in Max, Pd and other languages, which can be relatively easy to do if there’s a proper C++ plug-in API - seems like there’s one. From past experience it’s a few days of work to get the first objects to say “hi”, and an additional year to sort out all the additional edge cases :p.
@microdee “ah I thought OSCQuery is a reflection method implemented inside OSC (which tbh would make more sense, why introduce another socket)”
Well actually a previous protocol we used was just that (https://github.com/Minuit/minuit) but we ran into a lot of limitations, the biggest being that since OSC is most of the time sent through UDP, you have a hard limit on how many bytes you can put in a single message - in some braindead routers, this limit being sometime as low as 800 bytes - hence the protocol has to chunk the discovery in a lot of small messages which makes the whole stuff an order of magnitude slower than just sending a single JSON message over TCP.
In addition, being based on WebSockets, the discovery protocol can be used to work directly through a web browser which isn’t possible with raw OSC ; you always have to have an additional translating process that converts WS messages from the browser into OSC messages.
3 Likes
Hi jcelerier and welcome!
Can you post an extreme case of how your JSON would look like?
VVVV and VL is not comperable with other dataflow environments when it comes to handling all kind of input data, so it might be much less of an headage to solve it with a patch then you think actually :)
i found this unity implementation which can be a blueprint for a vl nodeset.
and of course there’s the possibility to create some kind of adapter to RabbitControl…
@jcelerier, hi! thanks for the insight, yeah message size limitation-wise tcp makes much more sense. Parsing JSON data in vvvv is actually surprisingly easy (read: devvvvs created a node which deals with deserializing json strings into usable objects (in this very case converting it to XML dom and using linq XElement in vvvv)) and actually a lot of things like that has been taken care of for vvvv so ain’t so bad but I hear you ;)
It’s true you can write a vvvv plugin in C++ but only with the C++/CLI variant for .NET which is fine but then it might make more sense to create Ossia bindings for C#. However in C# there’s already a very handy OSC interpreter inside VVVV.Utils, a helper library for vvvv plugin development and the only real advantage of Ossia in this situation would be handling the object hierarchy and the OSCQuery server afaiu. Please correct me if I’m wrong because Ossia seems to be an interesting stuff for me.
I’m actually playing with the idea of a CLR object OSC (de)serializer using .NET reflection and interfaces for manual serialization. Implementing OSCQuery HTTP server seems to be pretty straightforward with C# too, is there anything more convoluted required to communicate with ossia/score to their full extent?
Ossia uses websockets instead of http for OSCQuery? or how that comes to the picture?
Hi!
@tekcor: the json in itself is fairly simple but can be nested to arbitrary depths. Basically, a server that exposes multiple OSC addresses such as :
/foo/bar int float
/baz string
would provide (more-or-less) the following JSON upon the HTTP GET request “/”
{
"FULL_PATH": "/",
"ACCESS": 0, // this node has no particular value to read / write
"CONTENTS":
[
{
"FULL_PATH": "/foo",
"NAME": "foo",
"ACCESS": 0, // neither does this one
"CONTENTS":
[
{
"FULL_PATH": "/foo/bar",
"NAME": "bar",
"TYPE": "f", // An OSC type tag
"VALUE": 3.141, //matching value
"ACCESS": 1, // read-only
"RANGE": [
{
"MIN": 0,
"MAX": 100.
}
]
}
]
},
{
"FULL_PATH": "/baz",
"NAME": "baz",
"TYPE": "s",
"VALUE": "pear",
"ACCESS": 2, // read-write
"RANGE": [
{
// The acceptable values
"VALUES": {"apple", "pear", "banana"}
}
]
}
]
}
Further addresses just add additional objects to this tree
However, the approach we’ve taken in Max, Pd, etc… is to recreate this tree through objects.
e.g. for instance the following Max object hierarchy would create a server that exposes the aforementioned tree :
While the following patch could be used to access them :
which is relatively simple for end-users
1 Like
I’ve used cppwinrt (GitHub - microsoft/cppwinrt: C++/WinRT) to interact with .net objects from pure standard C++ code, maybe that could be a solution ?
As other found out, there are already such bindings. However I would rather use directly the C++ lib for performance reasons: the C# binding is based on the C API, which has to do some additional memory allocations. But well, it’s already here and it more-or-less works, so that’s certainly the easiest path forward.
yup, that’s the point of the ossia lib : create your OSC object hierarchy for you
No, that’s all that is needed :)
Both are possible. Using websockets however additionally allows to enable / disable listening of updates on particular objects from the client side (that is, the server will send an OSC message to the client every time the value changes).
Unfortunately vvvv plugins rely heavily on class composition and attribute annotations. I can imagine coping with this with pure WinRT would be a colossal pain in the ass. C++/CLI works with modern C++ versions and more importantly supports Attribute decoration. So statically linking the optimized Ossia in it would be a breeze. The only boilerplate would come from the vvvv plugin-interfaces you can read the basics of it here: Dynamic Plugins Reference | vvvv which is for dynamic plugins but the same works when developing in an external IDE (which is highly recommended tbh). This is in C# but the attributes work in the same way in C++/CLI.
in that case it might be healthier for vvvv if we stick to a pure .NET object hierarchy instead of using a C++ library for that. Of course it wouldn’t be as fast and as memory efficient but that won’t be the hardest thing on performance in vvvv ;)
@ofersmi regarding your initial question: “is it related to ctrl+k?” the answer is: yes, partly.
the idea of exposing parameters (or a whole object model as libossia puts it) has two ends:
- the server that exposes the parameters
- the client that is interested in controling those parameters
so the way this concerns ctrl+k is via the first part: exposing an IOBox by selecting it and pressing ctrl+k could “expose” the parameter via libossia . i assume this would be a rather simple plugin to write, as it would be starting from the Server (VVVV) node which already does exactly that, except it is not using the oscquery protocol (since that didn’t exist back then). like that you could already use score with ioboxes exposed from vvvv.
the second part is probably a bit more special-interest as it would allow you to read the object-model exposed by some other libossia-device and build a UI for those exposed parameters in vvvv/vl or of course simply send data to it.
therefore i guess the quickest way to get to a useful result (at least for the first part) would be using the c#-wrapper @jcelerier do you really think memory/performance issues should worry us here? as i understand this will not be about any realtime data, right? the object model is built and exposed once. then only some changing parameters will be sent?!
and then indeed this is in many ways similar to what we’re working on with RabbitControl which is still in pre-alpha but i guess it could be another protocol for ossia to support. or for score to implement directly. will be interesting to work out the exact similartities and differences… @jcelerier (and everyone) feel free to join us on riot for a chat
1 Like
@joreg so yes, the ctrl+k server is the “easiest” part just showing which IOBox you want to control, and I understand there is the hierarchy or model, but from what I see in the max implementation a “parameter” in oscquery also carries different attributes such as type, range, unit etc… those can maybe be set in inspektor of a ossia parameter? or can IObox already transmit some of those (since an IObox already has type and range…)
Is there anything I can do to help make this happen?
Rabbitcontrol (like rabbithole?) also looks super interesting, and very related to score!
exactly that is the point and very much possible. just needs a c# coder and some hours of free time to get this rollin…
Hi there !
I’m also part of the ossia team, and have been following this discussion with interest, since we discussed it with @ofersmi
I have recently begun working on a openframeworks addon that is somehow similar to this:
GitHub - bltzr/ofxOscQuery: ofx Addon for OSCQuery support (the release is a little old, I should do a new one in the next few days, I think)
which binds to ofParameter, which seems to be the same kind of beast that you’re mentioning here (IOBox) in this that it knows about the type and range of the parameter it’s holding.
Then it’s quite easy to add up some more ossia-specific attributes (like clipping, units, and such) that ossia helps to expose to OSCQuery, but whose processing it also actually implements (like actually clipping the incoming values, in the way defined by the bounding_mode attribute).
So, maybe looking into this might be interesting to anyone wanting to give a try at implementing libossia in vvvv ?
This addon uses the ossia-cpp (aka safeC++, i.e. C++98) binding, which makes it quite easy to implement - I know vvvv is coded with C#, but maybe that could help ? (in particular because we’ve been doing a quite thorough documenting of this API with doxygen, so most of the basic methods are there)
Also, ossia | Open Software System for Interactive Applications might be of interest to you guys - it was written more specifically for Unity, but it’s way more succinct than the C++98 doc.
Anyhow, we’ll be more than happy to help if someone wants to dive in!
Cheers!
Oh, and also, I don’t think that was mentioned, but more and more creative softwares are implementing OSCQuery. AFAIR, there’s at least Vezer (and Mitti), MadMapper, Millumin, and VDMX is on its way. So having vvvv on the list would be a great addition!!!
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.