OSSIA/libossia

feel free to ask us here about libossia

Alex Norman

@x37v

great!

Alex Norman

@x37v

BTW, i thought part of this refactor was being able to expose a poll method or something that controlled what thread the callbacks/processing happened in? is there an example of that?

Jean-Michaël Celerier

@jcelerier

Yep, the protocols now take a network_context argument

Which can then be polled / run / ...

https://github.com/ossia/libossia/blob/feature/async_protocols/src/ossia/network/context_functions.hpp

It uses asio behind the hood

Alex Norman

@x37v

great!

Alex Norman

@x37v

@jcelerier have you all considered conan for managing dependencies? I put together a basic recipe and pushed a branch, it uses conan to get/build boost there are a number of other libossia deps that could go this way too..
here is an example cmake file that shows the usage of a version of libossia i packaged with conan: https://github.com/Cycling74/libossia/blob/xnor/conan/examples/Conan/CMakeLists.txt
the branch https://github.com/Cycling74/libossia/tree/xnor/conan

Jean-Michaël Celerier

@jcelerier

hi ! yes, and I had opted out against it when I tried for the following reasons (my notes are from 2019 so it could be time to revisit though):

not possible to parallelize the download of dependencies (when I had tried to port ossia it took something like 10x longer than git clone --recursive -j16 which is really not good for CI)
multi-configuration builds seemed complicated
made it hard to "just" clone the repo, open the CMakeLists.txt in the IDE we use (QtCreator) and be ready to go, in particular I quite often have students doing internships, group projects, etc... on the code and from experience every additional step makes it much harde for them to get started with the actual work. Though https://docs.conan.io/en/latest/howtos/cmake_launch.html could alleviate that a bit.

Jean-Michaël Celerier

@jcelerier

packaging libossia itself would be very nice, likely we can reuse your example. Do you think it'd be easy to update the conan repo automatically from, say, GH actions ?

Alex Norman

@x37v

yeah, packaging is as easy as conan create . user/channel the issue is publishing though. you need to have a conan repo you can write to.
We're planning to make a public repo for our shared work, which is where i was planning to put libossia when I create the package.. but you'd need to get your own or access to some other public one for automating publishing for your organization

jfrog provides a free tier for conan repos.. i'm using that right now, but they require activity every 2 weeks or so, download or upload, which sometimes is unreasonable, if you don't release often you mostly just used cached installs

but, publishing is also easy once you have a place to put your packages

Alex Norman

@x37v

yeah, my example build doesn't require a user do anything other than mkdir build && cd build && cmake .. && make but they do have to have both cmake and conan installed.. so that is an additional hurdle.

I do get the multi-config thing too, i'm not sure how to delay the conan download/build/install until after a configuration is selected.. so maybe migrating more deps to conan doesn't make sense for this project, but boost (as I already did) considering its a requirement for all the builds, might.

once nice thing on that though, conan downloads binaries if there are binaries for your configuration already published (for instance, static boost library for clang8 macos), and the packages are cached in their own place so you take a hit the first time you do a build but after that, if you don't change versions or configurations, things move pretty fast

Alex Norman

@x37v

on another note, so far that feature/async_protocols echo is working great! need to get some others to test on it but I believe this has solved the thing I wanted with OSC out.
I will have a small PR enabling a no local input OSC protocol

Alex Norman

@x37v

ossia/libossia#726

Jean-Michaël Celerier

@jcelerier

super, thanks !

@avilleret do you think we could :

merge the github-actions branch
rebase async_protocols on it (I'll do it)
merge that one into master (I just have a couple commits to push before that but it should be done soon)

tag a new major version :D

.. but you'd need to get your own or access to some other public one for automating publishing for your organization

yep, I used to have a jfrog one but it seems it has been deleted with their recent change heh

hosting one should not be a problem though

Alex Norman

@x37v

yeah, they ditched bintray but have another conan thing you can do.. its all a little confusing to me but seems like hosting is the best route considering those limitations anyway

Jean-Michaël Celerier

@jcelerier

@x37v just in case : the latest commit may break api depending on which classes you were using if you're on feature/async_protocols

Alex Norman

@x37v

okay, i'm working on my own forked branch but i'd like to keep up with your branch so i'll try to merge soon and check, thanks for the heads up @jcelerier

Jean-Michaël Celerier

@jcelerier

alright, keep in mind that I'm also rebasing it on master so if you have some work, the easiest would be to go on origin/feature/async_protocols, cherry-pick your new commits and set your work branch to that

but I think that it should soon be mergeable which will simplify that

Alex Norman

@x37v

great!

yeah, i basically just merge my conan stuff in so i could make a conan package.. so i could just ditch my branch, create a new one and then merge again it keep conan alive

and in fact, i don't exactly need the conan file to be part of the repo anyway

oh, but i guess i did modify how boost is included. anyway, shouldn't be a problem

Jean-Michaël Celerier

@jcelerier

almost there, the osc implementation is now able to use a wide array of transport protocols (with a fair amount of configurations): https://github.com/ossia/libossia/blob/feature/async_protocols/src/ossia/protocols/osc/osc_factory.hpp

the last step for that feature branch is to allow the oscquery protocols to use that

instead of the hardcoded osc over udp they have right now

this also clarifies some implicit assumptions that were encoded in the previous osc_protocol, such as what kind of osc messages are sent / received, and the interaction between two machines

i'm also going to migrate from websocketpp to boost.beast for WS, it has been part of boost for the last ten versions or something and is much more maintained... so that will reduce dependencies a bit

Alex Norman

@x37v

should i expect to be able to add a node in the "fast c++" API that has slashes and have libossia manage creating the appropriate path (this worked earlier but i was using the "safe" interface)

Jean-Michaël Celerier

@jcelerier

yes, there's a create_parameter function which does that

see ossia::net::create_node here: https://github.com/ossia/libossia/blob/d8699824ad1adc54ff95f3f7e1ed5e6bf509cb9a/tests/Network/OSCTest.cpp

Alex Norman

@x37v

okay, i'm getting underscores where i should be seeing slashes in the name but I'll verify that its not my end

@jcelerier so i have 2 protocols, oscquery and OSC UDP (output only) .. when I update a GET only param from software, I don't see an output on OSC (but via HTTP i can see the change), but when I change it to BI or SET i do get an OSC UDP message out..
I'm trying to hunt it down but maybe you can give me a hint for where to look?

seems like the logic is inverted there

Alex Norman

@x37v

see ossia::net::create_node here: https://github.com/ossia/libossia/blob/d8699824ad1adc54ff95f3f7e1ed5e6bf509cb9a/tests/Network/OSCTest.cpp

ahh, i'm using parent->add_child as I might not know the base address.. but I guess I can get that from parent->osc_address ?

Alex Norman

@x37v

@jcelerier so i have 2 protocols, oscquery and OSC UDP (output only) .. when I update a GET only param from software, I don't see an output on OSC (but via HTTP i can see the change), but when I change it to BI or SET i do get an OSC UDP message out..
I'm trying to hunt it down but maybe you can give me a hint for where to look?

looks like osc_protocol::push .. it filters out GET but I think it should filter out SET

Alex Norman

@x37v

@jcelerier ossia/libossia#732

Jean-Michaël Celerier

@jcelerier

agh

ossia/libossia#504 strikes again :)

so, regarding that get / set thing

Jean-Michaël Celerier

@jcelerier

in the feature async/protocols, which is likely getting merged by the end of the week-end as I just have a couple remaining CI failures, you'll find

https://github.com/ossia/libossia/blob/feature/async_protocols/src/ossia/protocols/osc/osc_factory.hpp

which allows to create more configurable instantiations of the OSC protocols; right now there are two options (host / mirror) which controls how the get/set thing is handled ; "host" can do everything (as it's, in the mental model of the thing, where the "actual" parameters are, e.g. it's a synth or something like that, while "mirror" is just a controller (which is what the original osc_protocol class is) ; as such, a controller can send messages to nodes that the host advertises as "set" (from the point of view of the controller, those methods are setters) and cannot send messages to nodes that the host advertises as "get" as those are, well, getters

Where communities thrive

People

Repo info

Activity