Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 23 18:27

    jcelerier on gh-pages

    Deploy code docs to GitHub Page… (compare)

  • Oct 23 17:25

    jcelerier on master

    fix bug in fade-out for sound_m… (compare)

  • Oct 23 16:42
    evanmtp opened #595
  • Oct 23 10:45

    jcelerier on gh-pages

    Deploy code docs to GitHub Page… (compare)

  • Oct 23 10:21

    jcelerier on master

    Try to fix locking-related issu… (compare)

  • Oct 22 09:19

    jcelerier on gh-pages

    Deploy code docs to GitHub Page… (compare)

  • Oct 22 09:16

    jcelerier on master

    Fix incorrect looping for audio… (compare)

  • Oct 21 10:26

    jcelerier on gh-pages

    Deploy code docs to GitHub Page… (compare)

  • Oct 21 10:15

    jcelerier on master

    faust: midi now has audio and m… (compare)

  • Oct 20 22:01

    jcelerier on gh-pages

    Deploy code docs to GitHub Page… (compare)

  • Oct 20 21:54

    jcelerier on master

    use shared_ptr for faust impl (compare)

  • Oct 20 18:32

    jcelerier on gh-pages

    Deploy code docs to GitHub Page… (compare)

  • Oct 20 18:13

    jcelerier on master

    Start preparing stuff for Qt 6 (compare)

  • Oct 20 07:26
    avilleret commented #586
  • Oct 19 20:27
    coveralls commented #585
  • Oct 19 20:03

    jcelerier on gh-pages

    Deploy code docs to GitHub Page… (compare)

  • Oct 19 19:52
    avilleret commented #586
  • Oct 19 19:11
    avilleret labeled #594
  • Oct 19 19:09

    jcelerier on gh-pages

    Deploy code docs to GitHub Page… (compare)

  • Oct 19 19:07
    avilleret closed #594
Jean-Michaël Celerier
@jcelerier
arf, does not seems to have debug symbols
that's strange, the unit tests do that all the time and seem to work...
also strange that you have a ossiax64d.dll which does not seem to have debug symbols --
have some pretty urgent things to finish this week, can you make a bug report and assign it to me ? i'll try to get to it next
you're with MSVC ?
onar3d
@onar3d

you're with MSVC ?

Indeed I am! Version 16.7.6, 2019 toolset v142

I've restarted both computers now (was connecting from win to vdmx on mac os), no other change, and tried again, the crash no longer happens :/
I'll try to reproduce it again, and will report a bug with how when/if I have.
Evan Montpellier
@evanmtp
Hey folks, I'm still trying to understand if there's a way to have ossia.remote not output a value when a model loads. I'd like to use an ossia.remote to pass a bang into a model when the user clicks on a GUI button. It's important that the bang only be passed in when the button is clicked, and not when the model initializes. I've tried setting @recall_safe 1 and @mode SET, but no luck.
Julien Rabin
@jln-
mm… I dont think it can be done as remotes work now. But maybe a hack could be not to set an address to the remote (or mute/disable it?) and setting the address only when user click or hover the button or something like this ?
Evan Montpellier
@evanmtp
I tried doing that, but in order to get the appropriate address from the model back to the view, I wound up using a slightly freaky workaround. It involved creating a message in the model containing a #0 local address variable, and then passing this back to a forward object in the view. It's in the new namespacebrowser widget, if you're curious. Unfortunately, it doesn't seem to scale very well - I have ten instances of this inside a larger model, and it adds about ~10 seconds of load time.
Julien Rabin
@jln-
Yes, I see. I remember spending quite some time on this for the Jamoma version
In your case, the browser model is added 10 times ? For the Jamoma version, I know that the point it was that only the view was added in the patcher, and the model was only loaded and closed dynamically when needed. But still, 10 seconds of load time seems pretty big
Evan Montpellier
@evanmtp
Yes - in fact, in this case the namespacebrowser is built into another module that does a bit of conditioning and scaling, and there are ten instances of that running inside of a granulator to modulate its parameters.
Julien Rabin
@jln-
Yes - in fact, in this case the namespacebrowser is built into another module
Ok, so you mean the model is builtin, right ? If so, yes I can imagine it adds if in a big patcher with dense namespace.
Evan Montpellier
@evanmtp
Yes, that's correct, all ten instances are incorporated into the granulator model. I'll keep trying to isolate the section that's causing the slowdown. Thanks!
Julien Rabin
@jln-
Franckly, if I were to buid again the namespace_browser for Jamoma, I think I’d do with with simple Max send and receive. Because, at the end, I know that I spent far too much work on this for something that was only used in Max, was very specific and used so little of the Jamoma features...
But for sure it was a very educationnal exercice :-)
Evan Montpellier
@evanmtp
That's basically where I got stuck - figuring out a way to use vanilla Max send/receive pairs to get data back and forth between an individual model and the corresponding view without having to resort to passing addresses back and forth via ossia.parameter/ossia.remote. I suppose it could be done by prefixing the send/receive names with the #1 variable, and making sure each instance of namespacebrowser has a unique name... it's just a bit messy in terms of the structure of this particular patch.
It's a really useful widget, so I'm hoping to get it working smoothly!
Evan Montpellier
@evanmtp
Also, here's a real silly question - is it the case that ossia.parameter @mode SET is the equivalent of j.message, while ossia.parameter @mode GET is the equivalent of j.return?
Evan Montpellier
@evanmtp
I've been doing a bit of stress testing related to this, and it seems as if registering ossia.remotes is generally pretty expensive. I'm attaching an example - two versions of a patch with 6 models, each containing 100 parameters. paramtest_withviews.maxpat has a view for each model, and on my machine it takes a good 12 seconds to load. paramtest_noviews.maxpat doesn't have any views, just models, and loads pretty much instantly. Is there any way around this? Given that individual models can get quite complex, it's easy to wind up making patches with hundreds of parameters (and remotes).
Evan Montpellier
@evanmtp
Adding to the weirdness, I just tested creating the views from scratch while the patcher was open, and they don't take any appreciable time to load. The slowdown really seems to be related to opening a saved patch that already has both models and views in it.
Evan Montpellier
@evanmtp
^^^ saved-patch.mov shows what happens when I load a patch containing a model with 358 nodes and a corresponding view. The screening recording doesn't show the beachball, but Max is hanging until the last second, when the values show up in the view UI objects.
^^^ in from_scratch.mov , I'm creating the same model and view in a blank patcher, and there's no appreciable load/hang time.
Any insights would be greatly appreciated! This has pretty major implications for building larger patches with complex models and views.
Antoine Villeret
@avilleret

Hey folks, I'm still trying to understand if there's a way to have ossia.remote not output a value when a model loads. I'd like to use an ossia.remote to pass a bang into a model when the user clicks on a GUI button. It's important that the bang only be passed in when the button is clicked, and not when the model initializes. I've tried setting @recall_safe 1 and @mode SET, but no luck.

then your parameter's type should be impulse and those parameter shouldn't fire a bang on loadbang and thus binded remote shouldn't fire a bang too. If that not the case, this is definitely a bug

Antoine Villeret
@avilleret

Also, here's a real silly question - is it the case that ossia.parameter @mode SET is the equivalent of j.message, while ossia.parameter @mode GET is the equivalent of j.return?

Kind of. We had that in mind when we work on those modes. But it's only a hint for the remote. It's up to the device designer to implement them or not. That means, with a parameter in mode get you can still set its value from a remote but it might have no effect depending on how the device is designed. Same applies to set mode, you can still retrieve its value from a remote but the value might not change unless another remote changed it.

regarding the loading slowdown, I'm currently busy at refactoring the ossia objects registration routine and that might improve that but it's a big mess and it takes lot of time.
I'll keep you posted with any update on that
In any case, thanks a lot for all those tests, we really need them to improve ossia-max !
Julien Rabin
@jln-
HI @evanmtp . Here is the kind of approach I was thinking of. Looks simple enough (although I may miss something - still having my morning coffee :-)
Pia Baltazar
@bltzr

That means, with a parameter in mode get you can still set its value from a remote but it might have no effect depending on how the device is designed. Same applies to set mode, you can still retrieve its value from a remote but the value might not change unless another remote changed it.

That as also the case in Jamoma

Evan Montpellier
@evanmtp

HI @evanmtp . Here is the kind of approach I was thinking of. Looks simple enough (although I may miss something - still having my morning coffee :-)

This looks great! Thanks Julien. When I have a chance I'll integrate it into our router-scaler-mapper model and see if it speeds up the performance.

then your parameter's type should be impulse and those parameter shouldn't fire a bang on loadbang and thus binded remote shouldn't fire a bang too. If that not the case, this is definitely a bug

Thanks Antoine, I'll test this out now and report back.

Also, here's a real silly question - is it the case that ossia.parameter @mode SET is the equivalent of j.message, while ossia.parameter @mode GET is the equivalent of j.return?

Kind of. We had that in mind when we work on those modes. But it's only a hint for the remote. It's up to the device designer to implement them or not. That means, with a parameter in mode get you can still set its value from a remote but it might have no effect depending on how the device is designed. Same applies to set mode, you can still retrieve its value from a remote but the value might not change unless another remote changed it.

So as I understand it, setting @mode SET and GET don't actually change the behaviour of ossia.parameter, but rather they're essentially tags to indicate whether the parameter is at the start of a chain of objects, passing in input data (SET) or at the end of a chain, collecting and distributing output data (GET) - is that correct?

It would be good to clarify this in the help patch. I'm happy to work on that, but just want to make sure I understand how it's actually working.
Evan Montpellier
@evanmtp

regarding the loading slowdown, I'm currently busy at refactoring the ossia objects registration routine and that might improve that but it's a big mess and it takes lot of time.

Cool, please keep me posted! I wish there was something I could do to help on the development side, but I'm very available to do any testing or other user-level stuff.

Evan Montpellier
@evanmtp

then your parameter's type should be impulse and those parameter shouldn't fire a bang on loadbang and thus binded remote shouldn't fire a bang too. If that not the case, this is definitely a bug

Thanks Antoine, I'll test this out now and report back.

OK, just tested this, and it does seem like ossia.remotes fire on load, even if the related parameter is set to @type impulse, no matter whether @mode SET or @recall_safe 1 are on.

Made an issue: ossia/libossia#595
Navid
@navid
Question: A lot of our systems rely on outputting a shit ton of "return" parameters that never need to be seen by preset systems. For example imagine 20 sensors running through many cooking processes that return at all times various states of the data: cooked, scaled, interpolated, delta, trigger, etc... This is a standard way of cooking data: keeping its uncooked versions available at all times. What is the best way to do this? It is super important for preset objects not to see these return parameters or else preset changes might result in unintended former data to sound stuff during a concert.
A similar question regarding messages: How can we have a shit ton of "message" parameters that are invisible to the preset system.
Configuring preset objects to "unsee" individual parameters is not a realistic solution in big projects and patches.
Also: while exploring data spaces for interaction design purposes it is super useful to group return parameters together to quickly identify useful data instead of attributes.
Antoine Villeret
@avilleret
thanks evan for the issue, I'll take a look at it once registration refactoring is done
Evan Montpellier
@evanmtp

thanks evan for the issue, I'll take a look at it once registration refactoring is done

Awesome, thanks Antoine!

Evan Montpellier
@evanmtp

browser-test.zip

This is a great solution, but in the end I think I'm going to keep namespacebrowser as a model, if only because part of the point for me is to be able to store and recall the selected address in presets. I did replace the parameters that were handling the bang to open the patch and the coords to offset it with standard Max send/receives, though, so the only remaining parameter is the one storing the address. I'll make another PR for this version once I test it a bit more.