[ossia-max] Request: make ossia.parameter @mode SET or @mode GET not output values on load or preset recall

[evanmtp]

I think it would be helpful if ossia.parameter @mode SET and @mode GET did not output their values when a patcher loads or when a model is instantiated. My rationale for this is that I'm coming to think of both GET and SET parameters as ways of passing "momentary" data that should not be considered part of model state.

I'm using GET parameters exclusively to return varying output from a model - e.g., the output of a pitch detector, an accelerometer value or rotation vector from an IMU, etc. These values should never be stored in a preset, since they are the output of real-time processes.

I'm treating SET parameters as messages that are passed in to the model, but are not meant to be stored as state. Examples would include sending a bang to open a pop-up menu, sending a "clear" message to clear a buffer~, etc. As with the uses of GET parameters, storing values in these parameters is not only unnecessary but also potentially will have undesirable consequences.

I'm currently dealing with a small-scale version of this issue in terms of GET params with #595. I think that addressing this at a general level with GET/SET parameters would take care of this, and also potentially be a nice feature in general in terms of giving more granular control over how values are stored and recalled.

I'm also curious about whether doing this would have implications for CPU efficiency and load times. As an example, I'm currently making some models that break out data from IMUs. I'm attaching one for the x-IO NGIMU:

ngimu.zip

ossia.ngimu.model.maxpat contains quite a few ossia.parameters - 145, to be precise. Of these, 87 are @mode GET, and are being used to return measurement values from the sensor. These values should never be stored in presets, nor should they fire on load/instantiation. It's likely that I'll want to run six instances of this model simultaneously in a single patch, so I anticipate that having all of the parameters output their values when the patch loads may significantly increase load time.

I'm wondering whether doing this would go against the spec or cause problems. There's a good discussion of SET and GET params at #504 , but it's more concerned with addressing these params remotely as opposed to the question of whether they should be stored or not.

[evanmtp]

Tagging @avilleret , @bltzr , @maybites , @jln- , @petervanhaaften, @navid, @jcelerier

[maybites]

I have the feeling @mode gets overloaded with functionality and this makes it confusing. maybe @mode should just be about

Defines the way the value of ossia.parameter will be accessible : when set at GET, the value can only be retrieved, when at SET, it can only be set, and when at BI, it can be both set and retrieved. However, when @mode is set as SET, it is possible to retrieve the last value it has received, without any guarantee this will reflect the system's current/actual state.

and another attribute defines if the parameter should be 'realtime only' or 'storable'.

[evanmtp]

That would work for me to, provided that this attribute affects both preset recall and initial loading/instantiation of models - i.e., a "realtime only" parameter would not output its value when the model is loaded.

Given that @mode SET and GET already seems to be causing a certain amount of confusion, I'm inclined to agree with @maybites that perhaps it should not be made any more complicated/overloaded than it already is. It's tempting for me to advocate making the feature I'm requesting part of the SET/GET behaviour, just in terms of minimizing the number of attributes one has to deal with. I imagine not everyone will want to work with them this way, though, and maybe it's better to leave this up to the user.

I'm very curious about what others think, and whether there are specific cases where you can imagine this being helpful or problematic. @bltzr, in terms of the example that you brought up in #504, do you feel like having this separate "realtime only"/"storable" attribute would help?

[bltzr]

I really don't know if I'm the best person to state on this, since I'm heavily biased by having been implied (or even somehow central) in defining those specs, both in Jamoma AND ossia, so maybe we need a fresh look on that, from someone not so immersed in those cases and habits.

again, this is something we should discuss in a real-life workshop, if those can happen again in some not-so-distant future...
we could maybe start with a remote workshop online to get started with the topic ? What do you think ?

this said, and at first sight, adding an attribute that would be explicitly and specifically dedicated to this seems like the best option.
It could maybe even be set by default to true or false when @modeis GET or SET or @type is set to Impulse (just thinking out loud)

[maybites]

I just discovered the [ossia.parameter] attribute @recall_save which seems to intend to do something similar. though it is not documented yet.

[avilleret]

ossia.parameter without a default won't output anything on load hopefully, if it's not the case, please open an issue about that.
recall_safe attribute avoid a parameter's value to be modified by loading a preset
it won't avoid saving the value

to exclude a parameter from a preset I'll introduce a new exclude attribute which will be set to true for parameter with GET or SET access mode.
I hope this fit everyone's needs

[maybites]

I guess we need to find a solution that also works with the cue_manager approach. But I am not sure anymore how that beast is truly working. It is based on the preset_manager from the overview patch, so I assume it queries the [ossia.deivce] with the 'namespace' message.

just to be sure: if @exclude is set, [ossia.deivce] would not output the parameter when queried with the 'namespace' message? or how else would you make sure the parameter is not saved?

[avilleret]

When I speak about preset, I'm speaking about ossia-max preset system, not the output of the namespace message.
There is ossia.explorer which allow you to query some nodes based on some kind of filter, and we could easily add the new exclude attribute to that filter.

If you're building your own preset system on top of ossia-max, then it's your responsibility to filter what you want to put in a preset or not. in that case, I can only give you the ability to filter out nodes based on their attribute and you already have filter to do so : you can filter nodes with ossia.explorer based on their @mode.

It was working when I made it last month. Unfortunately it's seems broken. I'll fix it and post a small patcher here to demonstrate how to do so.

[avilleret]

here is a patcher that demonstrates this feature with access mode :

----------begin_max5_patcher----------
867.3ocwXtsbaCBDF9Z6mBFcU6LtoBPmbupu.8InSmLXYhMYjDp.J0dxj28B
Kx1swmH1NJ2HMfWyx2xxOK54wihlIWw0Qnug9IZznmGOZDzkqiQ8sGEUyVUV
wzfYQkx5ZdiIZh+2L7UFn+e2wUqQZ9SbEqBUKmaG1daZ5pkclJtAFg39dEyg
+mb1ieAmrwzVlobonYw8JdowOsn3r6hmfRvT2KbZr6Ew9D8qciunYyvic88x
3wtGSBjoZtVyVv2iIGEVjLnYhsSPEWawmYDxl6qDM7RYWCXM4fzh2mV5lwxa
lYcK2SZTzVjNPbfPStKcabHGCgAxwBCjacXXWH3r.hIWHg3oNBoE.gouCD1v
+icBtGfRsVvtqkoX0bCWglIknueRpIGfZ7wodxYHOMdpG1BHGOO6znie+Puc
K5179fYe5UiNdpGc+Z+GB5OrE8EuAzStdzy5QO91i94T1BdOcZxEtmNFTsno
98zECrp0h2Bh3KCQbArLRII.hSu8HdrybcmEYfyZQOHpr4vAehaJI5T5vdo2
oYeHm3F9B1EdRJNOwyG7hNcvNmwrT0E9on4WEcIYvNtLxsWT4XoiffJxN2sy
EDqRwYyWirS91NiF0XUY0srRNpbIqYAWOAMqyfLK4JNRX+c4qxg+uhqnAWJI
8DI1XuJTVpSRBmmCwo7gHzTIzFjq130KLtIE5AkrFojRCZN+IgMp7oevVgVT
ImYqdtuKQiM7vLnRll+4CFVHgFVHwmJrPS8kcj6yUfVT5PreeaVQ3aKhursE
4vQOISeuJd9Ha4aUhFCB1YDr3bQz4v.GCuxnCWEC7UsUR6V0uF7J0Epe4yB6
SFSyF3UpdLC+fznyQBweQl7zAtv1dRTAudQtl0KBApRXnKeObYiqQ0v+jlGN
afEfV8q93JfOb8++.qkcpxMyn9OR.Zmely0FQC7QG9GabUH3L5fwzPcTd.Nh
bC7i6BDCCQoCVryciggwSj.bT5MvO32P5PuM0h4sRqzodysgntpqR8eCiBuJ
tuQluRaLTRZQlyLnw0NmIC0pfq1iy6oagiBvOE64GunCqs0Vmot2XvEV8zGk
JWyhIPSQiuIHTZuF4ShM16MforBgFqJXmBlVQqx72+GtflpoSzK3Ygy5RPqd
Wobt+fSRe7Ki+KPa0lCT
-----------end_max5_patcher-----------

but unfortunately it has been broken since it was introduced.
last known working commit : 7b9acee

I'm gonna fix it and then if it works like this, does it fit your needs ?
If so, then I'll close this issue and open another one describing exclude attribute which could be interesting anyway even in the libossia caore (not only ossia-max)

[maybites]

@evanmtp probably should chip in here.

Not sure if 'exclude' is the best term, though. its very generic. maybe 'suspend' or 'suspend_preset'?

[avilleret]

i made a small vidéo posed on Gitter that shows the current behaviour (as it was on 7b9acee) :

https://files.gitter.im/5a6c91a0d73408ce4f8a664e/WoLh/ossia.explore-filter-by-access-mode.mov

[maybites]

@avilleret that looks like a powerfull node anyway.

[avilleret]

concerning the word to use for this attribute, I really don't care, but I used to love short name, it saves keyboard strikes and space in patcher, but again since I'm not using it, it's up to you guys to decide the name of such an attribute

[maybites]

@evanmtp should decide. He requested this feature. I just chipped in with my opinions.

[avilleret]

the behaviour shown in the video has been restored with 0573671

could we close this issue @evanmtp ?

[maybites]

@avilleret can you also add the parameter_tree_for_example abstraction to the package so the help patch is working, too?

[evanmtp]

The ossia.explorer access mode filtering is great to have back - thanks, Antoine.

I think having an @exclude attribute would solve the issue. It would be good if ossia.explorer could filter for this, as well.

I'm fine with @exclude as the name, or open to any other ideas. Maybe @store would be an alternative? Shorter, and kind of the opposite/complimentary idea?

I realize now, however, that it's also important that ossia.remote inherit the @exclude behaviour as well. Currently, ossia.remotes always output their values when a patch loads, and I don't know of a way of avoiding this. This can cause some initialization issues, and I'm also wondering if it's sometimes causing slowdowns with larger patches.

Please check the print messages in the console in this example:

remoteTest.zip

Would adding @exclude to an ossia.parameter make it so that all attached ossia.remotes would inherit the behaviour, in terms of not outputting values at the start? If a separate solution is needed, I could create a separate issue/FR.

This question is somewhat touched on in #595 , but that issue is specifically about ossia.parameter @type impulse, whereas the current request concerns all types of remotes/parameters.

[avilleret]

sorry to insist, but please open a separate issue to discuss the @exclude/store attribute behaviour (I'll vote for store if I can)