Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 14:28

    jcelerier on master

    [perf] Use re2 instead of std::… (compare)

  • 14:13

    jcelerier on master

    [various] Many automated fixes … (compare)

  • 08:30

    jcelerier on master

    [osc] Fix failing multiplex test (compare)

  • 07:50
    jcelerier commented #795
  • 07:50

    jcelerier on master

    add multiplex protocol test, it… break to not invalidate iterato… wrap multiplex_protocol protoco… and 1 more (compare)

  • 07:50
    jcelerier closed #795
  • Aug 01 19:37
    x37v commented #795
  • Aug 01 19:37
    x37v ready_for_review #795
  • Aug 01 18:30
    x37v synchronize #795
  • Aug 01 18:01
    x37v commented #795
  • Jul 31 13:19

    jcelerier on master

    [ci] Fix wiiuse for mingw (compare)

  • Jul 30 15:12

    jcelerier on master

    [cmake] Try to improve the cpp … (compare)

  • Jul 30 15:05

    jcelerier on master

    [mapping] do not crash with non… (compare)

  • Jul 29 21:34

    jcelerier on master

    [dnssd] Fix a small typing issu… [various] Fix various code issu… [cmake] Allow to override c++ s… (compare)

  • Jul 28 21:59

    jcelerier on master

    [wiiuse] Fix soname (compare)

  • Jul 28 08:34
    jcelerier commented #795
  • Jul 28 08:33
    jcelerier commented #795
  • Jul 28 08:33
    jcelerier commented #795
  • Jul 28 08:33
    jcelerier commented #795
  • Jul 27 20:37

    jcelerier on master

    [wiiuse] Update to the latest u… (compare)

Navid
@navid
  1. Adding a namespacebrowser tester to the unit-test/test-patchers
Jean-Michaël Celerier
@jcelerier
this is the one with maybites' analysis of the combination of @mode, @default, and @recall_safe
Navid
@navid
  1. Finding a very simple solution for having messages and returns which never get saved and always remain invisible to all preset systems by default, forever. + documentation of these all within the embedded max-help patches
Navid
@navid
  1. getting ossia-max into the Package manager...
Navid
@navid
  1. Ossia models/modules should have a simple option for users to activate and monitor anything that comes out of them: so that they could, for example, wiggle a slider and see what its OSC structure is called. Evan demonstrated a strategic use of "ossia.remote //*" wild cards, which should be added to ossia.remote's help patch
Navid
@navid
  1. Unit-Tester for saving/recalling big hybrid osc strings: for example an entire OSC state of spat. Currently this is not possible easily. @evanmtp Evan can articulate exactly what is buggy or needdedd.
Evan Montpellier
@evanmtp
Hey @jcelerier! I'm going to take a look at #764 and #760. Just wanted to mention that I loaded some objects from 1.2.8 and got an error showing that they haven't been signed and/or notarized.
Screen Shot 2022-03-12 at 9.28.13 AM.png
(on macOS 11.4)
Jean-Michaël Celerier
@jcelerier
hey :)
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