Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 24 12:37

    jcelerier on master

    [ci] Fix tests on GCC (compare)

  • May 23 10:11

    avilleret on feature

    [ossia-max] fix ditto command [ossia-max] use schedule to out… [ossia-max] fix CSV header (compare)

  • May 21 15:52

    jcelerier on master

    [build] Forgot to add include t… (compare)

  • May 21 15:34

    jcelerier on master

    [exprtk] Add a perlin noise imp… (compare)

  • May 17 12:52

    jcelerier on master

    [core] Refactor everything to u… [deps] Cleanup dependencies a l… [variant] Add some type safety … and 1 more (compare)

  • May 17 11:48

    avilleret on master

    [ossia-max] try to fix signatur… (compare)

  • May 16 19:13

    jcelerier on total_variant_refactor

    Tentative to move back to prope… (compare)

  • May 16 13:49

    avilleret on master

    [ossia-max] use shortest comman… (compare)

  • May 16 12:43

    avilleret on master

    [ossia-max] CI test : remove an… (compare)

  • May 15 14:57

    jcelerier on variant_refactor

    [variant] Add some type safety … (compare)

  • May 15 13:58

    jcelerier on variant_refactor

    [variant] Add some type safety … (compare)

  • May 15 11:42

    jcelerier on variant_refactor

    [deps] Cleanup dependencies a l… (compare)

  • May 15 10:49

    jcelerier on variant_refactor

    [deps] Cleanup dependencies a l… (compare)

  • May 15 09:59

    jcelerier on variant_refactor

    [core] Refactor everything to u… [deps] Cleanup dependencies a l… (compare)

  • May 14 12:21

    jcelerier on master

    add mpark/variant as a git subm… (compare)

  • May 14 12:21
    jcelerier closed #789
  • May 14 12:21
    jcelerier commented #789
  • May 14 12:20
    jcelerier commented #789
  • May 14 11:42
    smoothdeveloper opened #789
  • May 14 08:43

    jcelerier on master

    [curve] Move behavior::apply ou… (compare)

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
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

more schematically:

host:

/a int, get
/b int, set
/c int, bi

means 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);
};
Jean-Michaël Celerier
@jcelerier
(now, my personal take on this is that this is an artefact of the old jamoma j.message, j.parameter, etc etc's workings ; "oop-like" access should not be handled at the protocol level but at the UI level of whatever's using ossia instead, with the access_mode only being a metadata)
Jean-Michaël Celerier
@jcelerier
@avilleret do we still care about 32-bit ?
it seems that MSVC is having an internal compiler error but only on 32-bit :|
max 8 is 64-bit only no ?
and we don't support max 7 anymore, or do we ?
Antoine Villeret
@avilleret
hi @jcelerier, imho we can ditch 32bit builds. Puredata is still available as 32bit on Windows, but who need it ?
Jean-Michaël Celerier
@jcelerier
it's just the max build which is failing
but if you think that 32 bit windows pd is unused then yeah
Antoine Villeret
@avilleret
if it builds fine, then keep it until it fail, concerning Max, I don't care supporting Max7, so we can disable Max 32bit builds
I'll try to port more build to github-action today, without any guarantee though
Alex Norman
@x37v
@jcelerier okay cool, i'll try out this osc factory. Thanks!
Alex Norman
@x37v
@jcelerier not sure if all of these protocols should support multiplex, but i updated my test to use the factory setup: ossia/libossia#735
Alex Norman
@x37v
does the new protocol setup for OSC have an output only UDP configuration?
Alex Norman
@x37v
looks like no, and i'm not entirely sure how i'd add it with the new setup
Jean-Michaël Celerier
@jcelerier
fixing that quickly @x37v
in terms of API i'm just changing the socket_configuration to optionals
so that it's easy to choose between only sender, only receiver, or both
will push as soon as the tests pass
:)
Jean-Michaël Celerier
@jcelerier
thanks for the extensive test, reviewing it
Alex Norman
@x37v
fantastic @jcelerier ! thanks, I was thinking optionals would be nice, though, the container is called bidir or something so i wasn't quite sure :)
will test out this approach in the example in the next few hours
Alex Norman
@x37v
I updated my PR, rebased against the async_protocols branch and fixed up the test, still failing on that SET getting sent out though