(on macOS 11.4)
hmmmm this is weird, notarization seems to have happened correctly from the git log..
regarding these two issues, I think that I understand the real deep issue: you want to be able to see which parameters were loaded when loading a preset right ?
right now the preset is applied, that is, the values are sent to every ossia.parameter
but I'm not sure there's an easy way to get this list of changes from a centralized place
The main thing for the TML use case is really to guarantee that, for example bangs from some
ossia.parameter @type impulse that's being used to get user input (e.g. mouse clicks) from an ossia.view don't fire every time a preset switches
or likewise that data that should be ephemeral (e.g. values from an accelerometer) being passed through an
ossia.parameter @mode get aren't stored in presets
and this seems to be already in fact the way things are working as of 1.2.8, at least if you use "preset load/save" messages to [ossia.device]
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
also it's nice that you can store multiple presets in a single [dict], since sometimes in the course of working on a project you can wind up creating tons of presets for a device and having loads of individual text files would be unwieldy
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
@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
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"
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