Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:00
    matcham closed #808
  • 15:00
    matcham commented #808
  • Nov 25 20:41
    jcelerier commented #808
  • Nov 25 20:38

    jcelerier on ossia.cue

    [max] Fix repetition filter eve… (compare)

  • Nov 24 14:20
    matcham commented #808
  • Nov 24 13:59
    jcelerier closed #809
  • Nov 24 13:59
    jcelerier commented #809
  • Nov 24 13:59
    jcelerier commented #808
  • Nov 24 13:58
    jcelerier commented #808
  • Nov 24 10:50
    matcham pinned #791
  • Nov 24 10:48
    matcham commented #808
  • Nov 24 09:54
    matcham commented #786
  • Nov 24 09:49
    matcham commented #808
  • Nov 24 09:47
    matcham commented #808
  • Nov 23 21:49
    jcelerier labeled #809
  • Nov 23 21:49
    jcelerier labeled #809
  • Nov 23 21:49
    jcelerier opened #809
  • Nov 23 20:42
    jcelerier commented #786
  • Nov 23 20:42
    jcelerier assigned #808
  • Nov 23 19:11
    jln- commented #808
Vincent Goudard
@vincentgoudard
hey there, I am currently writing an "extended asbtract" (as they say), to present the AIM-package (my libossia ersatz)... I looked for a paper on libossia but could not find one... is there any ?
and if not, what differences do you see between the features in Jamoma (as presented in http://www.jamoma.org/publications/attachments/jamoma-icmc2006.pdf) and the current libossia ?
Vincent Goudard
@vincentgoudard
for instance, I guess that brace-expansion, although a bit implicit in j.parameter_array was not as much supported as it is in libossia, right ?
Jean-Michaël Celerier
@jcelerier
hey !
hummmmm
not sure there ever was a paper on libossia proper indeed
Evan Montpellier
@evanmtp
sorry for the non-reply, @jcelerier ! need to set Gitter up on my phone. anyway, things are generally good, and you've seen the emails/issues about the... issues
Jean-Michaël Celerier
@jcelerier
@evanmtp you around ?
Alex Norman
@x37v
@jcelerier I wonder how you suggest that one uses multiplex protocol? I see that a device moves a unique pointer into it, you can get a reference of the protocol from the device but its type is erased..
I've hacked around it by grabbing a raw pointer before moving the protocol in the device, which works for adding.. but removing doesn't seem to be thread safe (something I mentioned a long time ago and am now revisiting)
https://github.com/Cycling74/libossia/blob/d7bbc9658d5ccfbb1f7eb3072a9bb6e87c5e98b9/tests/Network/MultiplexTest.cpp#L143-L227
this segfaults when pushing a value and removing a protocol at the same time.. I wasn't expecting to need a mutex on updating parameters
is this a bug that I should submit an issue for or should I try another approach first?
Jean-Michaël Celerier
@jcelerier
hi @x37v ! sorry, I had these mutexes issues in the back of my mind for some time
1 reply

I wasn't expecting to need a mutex on updating parameters

so, what is already mutex-protected is set_value / push_value

this can be called from any thread
hmm but this assumes that the structure of the device is indeed not modified in the meantime
alright pack it up folks, we migratin' to rust :p
Alex Norman
@x37v
I'd like everything to be in rust by my employer isn't ready :)
Jean-Michaël Celerier
@jcelerier
I think it'd be useful to think how it would be done there. problem is that the lifetime of the protocol has to be preserved long enough ; when things occurs across threads I assume that Arc has to be used there. But in libossia at the beginning we also used std::shared_ptr to keep the parameter objects alive
but this was way too slow in large patches (5K+ parameters) thus moving back to non-shared ownership and the condition of "the structure does not change during execution"
Alex Norman
@x37v
I actually wrote an OSCQuery implementation in Rust.. but its been a while since I looked at it
and, haven't profiled it really
Jean-Michaël Celerier
@jcelerier
how do things happen across threads ? is data shared, or do you exchange messages that get serialized or copied ?
the first oscq implementation I did used one big hash map and stored values but that was also too slow for various reasons
Alex Norman
@x37v
trying to remind myself, i think i use messages
looks like i used reader writer locks and messages.. again, i haven't used this in anything "production" so I'm not sure if it would hold up.. https://github.com/x37v/oscquery-rs
Jean-Michaël Celerier
@jcelerier
still it's interesting to see a design in rust ! thanks !
regarding the issue I think that what we could do is, in stop_expose_to / expose_to, to push the object to be deleted in the async queue
and change push_value so that instead of accessing the device directly, it pushes an async event on the queue too, in order to serialize things
but that's quite a performance hit for the "usual" use case where the tree is created at the beginning and does not change afterwards
Alex Norman
@x37v
okay yeah, i was gonna say, i believe I get the crash on push_value .. while multiplex protocol iterates its protocols, so it seems that the push_value part is key
Jean-Michaël Celerier
@jcelerier
yes, push_value calls protocol->push
Alex Norman
@x37v
could you make the behavior opt in only maybe?
Jean-Michaël Celerier
@jcelerier
yes, I think that what could be done
is provide another implementation of the parameter class
could you make an issue (unless there's already one, I don't remember) ? I have some time to spend on libossia these days so I'll try to come up with something to test
Alex Norman
@x37v
I'll do that! I could also try to work on it if you wanna give me some more guidance, but if you think you'd be able to get to it then I am happy to not do it too :)
Jean-Michaël Celerier
@jcelerier
cool thanks ! i'll try to flesh out something on the issue and we can see if that solve your issue, and if you want to do it it would be great ! I think it's mostly about making sure that the parameters get an io_context in which they can push events
or maybe we could add a push_async instead... there's likely multiple possible designs
Alex Norman
@x37v
yeah.. I think the different parameter class makes more sense to me? it keeps the same API but just offers some different guarantees about the safety?

cool thanks ! i'll try to flesh out something on the issue and we can see if that solve your issue, and if you want to do it it would be great ! I think it's mostly about making sure that the parameters get an io_context in which they can push events

great!

Alex Norman
@x37v
@jcelerier hey, you never ended up adding any guidance to the issue, I'd love to get on this if possible..
Jean-Michaël Celerier
@jcelerier
Hi ! Sorry, these last few months have been super busy with conferences.. I'm still at icmc, I'll try to do it when I'm back
(But iirc it should mainly be about inheriting from ossia::net::parameter_base or generic_parameter to protect the whole thing with mutexes ?)
Jean-Michaël Celerier
@jcelerier
back !
Alex Norman
@x37v
@jcelerier here's the test and a mutex wrapped multiplex protocol that resolves the problem: ossia/libossia#795
i made it a Draft just cuz I thought you might have some other ideas as it is a lot different than what we talked about above..
Alex Norman
@x37v

I'm trying to build libossia for raspi.. I've done it a number of times in the past but now i'm running into an assembler error:

/home/pi/local/src/libossia/src/ossia/network/oscquery/oscquery_server.hpp:50:8: warning:   by ‘virtual bool ossia::oscquery::oscquery_server_protocol::push(const ossia::net::parameter_base&, const ossia::value&)’ [-Woverloaded-virtual]
   bool push(const net::parameter_base&, const ossia::value& v) override;
        ^~~~
{standard input}: Assembler messages:
{standard input}:605: Error: selected processor does not support `yield' in ARM mode

I'm doing websearches to try to resolve it (maybe some cmake flags I can augment) but figured I'd check in to see if someone here has a quick solution

7 replies
Jean-Michaël Celerier
@jcelerier
@x37v while looking for solutions, I found this interesting thing re. thread safety: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
2 replies
the good thing is that the code can be annotated incrementally
Jean-Michaël Celerier
@jcelerier
I also fixed the failing multiplex test, but I think that I'm going to add some flags somewhere in the OSC protocol definitions so that people can define the behaviour they want more precisely, because the behaviour of "doing nothing when pushing from a SET parameter locally from C++ code on the server-side" is in multiple cases not what is wanted - whenever this came up I remember people saying that it was important to still see e.g. the value change in a remote UI when it is observed, just that this value change should not give a "deeper" notification and trigger actual events, etc. But the OSC message still has to go through to keep remote visualisation of live values up-to-date
1 reply
Jean-Michaël Celerier
@jcelerier
oh these thread-safety annotations are incredible..
annotate.png