- 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
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?
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 ?
@jcelerier so i have 2 protocols, oscquery and OSC UDP (output only) .. when I update a
GETonly param from software, I don't see an output on OSC (but via HTTP i can see the change), but when I change it toBIorSETi 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
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
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
more schematically:
host:
/a int, get
/b int, set
/c int, bimeans that the OSC clients to that host should be able to write the following class:
class host {
int get_a();
void set_b(int);
int get_c();
void set_c(int);
};