Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 30 21:37

    jcelerier on master

    Fix left over typos (incl. sour… (compare)

  • Sep 30 21:37
    jcelerier closed #798
  • Sep 30 21:37
    jcelerier commented #798
  • Sep 30 17:33
    jcelerier opened #799
  • Sep 30 15:36
    luzpaz opened #798
  • Sep 30 15:21

    jcelerier on master

    Fix follow-up typos Follow-up … (compare)

  • Sep 30 15:21
    jcelerier closed #797
  • Sep 30 12:21
    luzpaz synchronize #797
  • Sep 30 12:20
    luzpaz synchronize #797
  • Sep 30 12:18
    luzpaz opened #797
  • Sep 29 20:55

    jcelerier on master

    [exec] Fix that position change… (compare)

  • Sep 29 03:48

    jcelerier on master

    [install] Add unordered_dense (compare)

  • Sep 29 03:40

    jcelerier on master

    Fix typos in src/ subdir Found… (compare)

  • Sep 29 03:40
    jcelerier closed #796
  • Sep 29 03:40
    jcelerier commented #796
  • Sep 29 03:24
    luzpaz opened #796
  • Sep 28 23:40

    jcelerier on master

    [install] Fix missing headers i… (compare)

  • Sep 27 03:34

    jcelerier on master

    [expr] Add a 'contains' operator (compare)

  • Sep 21 16:47

    jcelerier on master

    [scenario] Fix that play from h… (compare)

  • Sep 13 06:50
    avilleret commented #785
Jean-Michaël Celerier
@jcelerier
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
Evan Montpellier
@evanmtp
Hey! Actually I'd say it's less about keeping track of which params changed, and more about being able to control which ones are stored
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]
Evan Montpellier
@evanmtp
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
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!
Jean-Michaël Celerier
@jcelerier
I wonder if storing the presets in dicts is something we could do directly from the c++ code as that'd likely be faster and simpler
(and seems like a nice feature for everyone to have)
Jean-Michaël Celerier
@jcelerier
@evanmtp everything going fine in the black box ?
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 :)