Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 29 21:04

    jcelerier on ossia.cue.2

    [max] More work on ossia.cue [max] clang-format [max] More ossia.cue work and 1 more (compare)

  • Jan 29 17:02
    evanmtp labeled #820
  • Jan 29 17:02
    evanmtp assigned #820
  • Jan 29 17:02
    evanmtp opened #820
  • Jan 24 03:55

    jcelerier on ossia.cue.2

    [max] Improvmeents and bugfix t… [ossia.router] handle list inpu… [max] attribute autoregister and 4 more (compare)

  • Jan 24 03:55

    jcelerier on ossia.cue.2

    [max] attribute autoregister [max] Do not accidentally creat… [max] Router: allow to choose w… and 2 more (compare)

  • Jan 23 02:22

    jcelerier on master

    [util] Add an useful algorithm (compare)

  • Jan 21 01:26
    evanmtp edited #819
  • Jan 21 01:26
    evanmtp edited #819
  • Jan 21 01:23
    evanmtp edited #819
  • Jan 21 01:23
    evanmtp opened #819
  • Jan 20 22:41
    jcelerier commented #802
  • Jan 13 20:55

    jcelerier on ossia.cue.2

    [ossia.router] handle list inpu… (compare)

  • Jan 13 17:53
    bltzr edited #818
  • Jan 13 17:51
    bltzr opened #818
  • Jan 13 17:49
    vincentgoudard edited as member
  • Jan 12 21:30
    jcelerier commented #802
  • Jan 12 20:51
    navid commented #802
  • Jan 12 20:10
    jcelerier commented #802
  • Jan 11 21:24

    jcelerier on master

    [dmx] Allow 512 channels for dm… (compare)

Alex Norman
@x37v
seems like maybe there is some locking from parent -> child and maybe updating child -> parent causes a deadlock
Alex Norman
@x37v
looks like i've resolved the issue by adding mutual exclusion around updating one node from another
.. preventing feedback basically
Jean-Michaël Celerier
@jcelerier

hmm. looks like it actually works if i don't make the callback methods reference eachother..

ah, adding a callback is indeed protected by a mutex, I guess this is what locks

e.g. you have /param and /param/normalized
and you want to update /param/normalized when /param receives a value
Alex Norman
@x37v
it seems like its not adding the callbacks but executing them that has been problematic.. but i've resolved my issue with a mutex inside those callbacks
the issue seemed to be /param/normalized callback -> update /param but maybe it ended up being /param/normalized -> /param -> /param/normalized
Alex Ramos
@alex-calamar
Hello again... What are we supposed to store or change on the value of an "impulse" type parameter to activate it?
Alex Ramos
@alex-calamar
To send to it that "impulse"... I tried boolean or integer values but the parameter seems not to get any change nor "impulse"... Any clues?
Jean-Michaël Celerier
@jcelerier
hm that on the other hand is strange @x37v, do you have a small code example ?
hi @alex-calamar
impulse is basically like bang in max / pd
iirc you can send it any value
but there is a specific ossia::impulse type
I think which is translated to Impulse in python ?
Alex Norman
@x37v
before I go modifying the library, is it currently possible to add an OSC destination without a new local port?
I'm using OSCQuery which already provides a UDP port, but I want clients to identify remote endpoints that should OSC messages when parameters change and there is no need for an additional local port
it looked like the osc_protocol tries to setup both and will throw an error if the receive fails.. but maybe something else exists
Alex Norman
@x37v
oh, and BTW, i submitted a test and bug fix about a month ago: ossia/libossia#720
Alex Norman
@x37v

hm that on the other hand is strange @x37v, do you have a small code example ?

I can try putting something together

Alex Norman
@x37v
on another topic. it looks like i'm going to want to move from ossia-cpp (the "safe" bindings) to the "fast" c++ bindings so i can take advantage of the multi protocol protocol. I'm not seeing a way to build the dylib and package those headers. do most projects simply include libossia as a submodule and build the c++ directly in or am I just not seeing a cmake configuration option for the fast c++ ?
Alex Norman
@x37v
ahh okay, looks like i got it, don't use the CPP_ONLY flag.. the include dir get splatted with a bunch of other stuff but that's not a big deal as i don't actually install it anyway
Jean-Michaël Celerier
@jcelerier

before I go modifying the library, is it currently possible to add an OSC destination without a new local port?

I think that for this one would have to make another implementation of the "osc" class. In the branch i've been working on the last few months it should not be very hard:

the osc class looks like https://github.com/ossia/libossia/blob/feature/async_protocols/src/ossia/protocols/osc/osc_generic_protocol.hpp

and is parametrized like https://github.com/ossia/libossia/blob/feature/async_protocols/src/ossia/protocols/osc/osc_factory.cpp

so to send to multiple clients, what I'd do is :

  • change that template to have different socket types for sending & receiving
  • putting the multiplexing in the "sending" socket type, e.g. instead of udp_socket it'd be something like
    class multiple_sockets {
       std::vector<upd_socket> m_sockets;
      void open() { for(auto& socket : m_sockets) { socket.open(); } }
      void write(const char* data, std::size_t sz) { for(auto& socket : m_sockets) { socket.write(data, sz); } }
    };

am I just not seeing a cmake configuration option for the fast c++ ?

well, "fast C++" is basically the default API that it builds when nothing is specified

Alex Norman
@x37v
@jcelerier is this new branch ready to use do you think?
I was thinking I would just use the mutli protocol thing and then just make port 0 mean 'no receiver' for the receiver port and then add/remove outgoing protocols at runtime
Jean-Michaël Celerier
@jcelerier
hm, so I've been using it in score for ~2 months and haven't noticed issues there
but there hasn't been more testing than that
(and it's missing a port of the oscquery server protocol)
likely the api is going to change a bit more, for instance with that multi-client thing, that would be a very useful feature and I want to make sure that it works
(or at least that it's very easy for an user of the lib to make it work by combining a few building blocks)
Alex Norman
@x37v
ahh, the oscquery part is the most important part for my application
Alex Norman
@x37v
@jcelerier it looks like the multi_protocol setup isn't actually going to solve my problem because if one of its children is oscquery, and another is osc, I don't get the echos (set_echo(true)) i need from oscquery -> osc, the UDP osc protocol only gets the changes that are triggered via local operators, push_value
I'm wondering if you have any advice? I'm trying to get both oscquery AND a list of outbound UDP, all echoing incoming changes as well as local changes.
I see that the oscquery client has this thing open_osc_sender which looks like it might actually do what i'm talking about.. but i don't actually see how to initiate it.
the json_query_parser parses a message StartOscStreaming that looks like maybe it initiates it? So maybe there is a WS data command I can send that actually achieves what i'm trying to do already? Or, am I on the wrong path?
i'm forked from a recent master FYI
djiamnot
@djiamnot:matrix.org
[m]
hey all. So tried to dive into https://github.com/OSSIA/ossia-sclang but hit a wall quite quickly with WebSocketServer not found.
I cannot locate such class and no official quark turns up anything similar.
any clue?
Thibaud Keller
@thibaudk
Hi @djiamnot:matrix.org
to use oscquerry you will need a spescial build
but the sclang quarck also suports plain osc
simply replace exposeOSCQueryServer() by exposeOSC()
if you are interested in the build that includes both HTTP and Websocket primitives, you can find it here
djiamnot
@djiamnot:matrix.org
[m]
I think I was interested in the OSCQuery, but will try exposeOSC() first
djiamnot
@djiamnot:matrix.org
[m]
😱, that's a customised SC3
Thibaud Keller
@thibaudk
yes
djiamnot
@djiamnot:matrix.org
[m]
wow. That's hardcore!
Thibaud Keller
@thibaudk
it's @pchdev 's handy work
we have discussed it on the supercollider page
but i am starting to wonder if merging it is feasible in the near future
djiamnot
@djiamnot:matrix.org
[m]
oh, interesting! Some good points raised there, it's true