As for #771, I was just trying to think of what would be needed to replicate this same behaviour with the "namespace" messages to [ossia.device]. This seems preferable for TML since (1) the roll-your-own preset system we're using (heavily derived from the example in the OSSIA overview patcher) is based around using this message and storing the output in a [dict],
and (2) being to be able to store the preset data in a [dict] and saving it with the patcher is a bit tidier than storing presets in external txt files
and (2) being to be able to store the preset data in a [dict] and saving it with the patcher is a bit tidier than storing presets in external txt files
hope that clarifies the idea!
(and seems like a nice feature for everyone to have)
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 ?
hummmmm
not sure there ever was a paper on libossia proper indeed
@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
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?
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
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
and, haven't profiled it really
the first oscq implementation I did used one big hash map and stored values but that was also too slow for various reasons
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
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
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
or maybe we could add a push_async instead... there's likely multiple possible designs
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!