ossia.remotes always fire on load, even with @type impulse

[evanmtp]

There seems to be no way to prevent ossia.remote outputting a value when a model and view load. See attached demo:

impulseTest.zip

It would be useful to have this functionality in order to build UI elements into views that only fire when the user actually clicks on them.

[avilleret]

thanks for the report and the test patcher, will look into that soon

[evanmtp]

Here's another example patch showing how this interacts with preset recall. In this example, there are four instances of the same model. Each instance contains a single parameter set to:

@type impulse
@invisible 1
@recall_safe 1
@mode SET

They all fire when the patch is loaded, and also when the presets are recalled.

Please open impulseTest_cues.maxpat for the demo.

Tagging @bltzr in this as well, following up on our cue_manager conversation from today.

impulseTestCues.zip

[bltzr]

I think there might 2 separate problems here:

• what happens when the model initializes
• what is stored in presets

What we discussed today, and agreed was the right behaviour for presets, was that: we want to exclude ACCESS GET, SET & TYPE Impulse from presets (ie. we store all ACCES BI parameters of all types except Impulse)

What happens at init is another matter.
My feeling is that GET and SET parameters shouldn't be firing anything at init, but I would need confirmation from others. A good way to check is: what is happening in Jamoma ? Are messages and return having default values ? Do they do anything at init ? If they don't, then I guess we should do the same in ossia-max. If they do, then we should discuss that.

In any case, as these are two separate problems, it would be better to have 2 separate issues, one for each.

What do you think ? Also @jln- ?

[bltzr]

I think @invisibleattribute is yet another matter entirely - I don't even remember what that does - does anyone know ?

[jcelerier]

If it's set the parameter won't show up over oscquery or other devices (e.g. in score)

[evanmtp]

I'm actually wondering now - is it necessary or beneficial for ossia.remotes to output their values when a model is loaded? It seems preferable to me that all the remotes would load "silently," not outputting their values unless asked to do so explicitly, e.g. by recalling a preset, or if the parameter in question has a default value.

I guess this might complicate things in terms of having remotes accurately reflect parameter state, though, e.g. if a second view of an existing model is added later...

[jln-]

I'm actually wondering now - is it necessary or beneficial for ossia.remotes to output their values when a model is loaded? It seems preferable to me that all the remotes would load "silently," not outputting their values unless asked to do so explicitly, e.g. by recalling a preset, or if the parameter in question has a default value.

It is necessary and required imho. Else it would mean that views can get un-synchronized which is not desirable. Further more if remotes are within a model and not in a GUI view.

Do I understand correctly that what is bothering you is that models & view get initiated with their default value AND by your default cue that actually initializes your patch ? (at least that was something that bothered me with Jamoma but never got solved). Not sure there would be a way to solve this, though (like "if there's an 'init' cue, don't initialize with default value attribute).

[bltzr]

Yes, things have always worked this way in Jamoma, and this has been discussed several times.
We even made some drawings that I photographed and am attaching here, about a kind of "cascading presets" system. Maybe that's overkill, though, IDK

However, as I said the other day about cue systems generally (IIRC) during our last zoom meeting, this is longer-term research, and we should definitely make a workshop on this topic, where we would gather needs, techniques and perspectives of each of us (and others), in order to find the best, most generic, solution (as we did several times with Jamoma).

Should we start a doc somewhere with these kinds of questions ?
Or maybe a github project, where we would gather relevant issues to this topic ?
So we can keep track of questions for when this workshop actually happens... (will try and look soon into the funding I mentioned the other day about this)

What do you think ?

[avilleret]

this issue has lots of digression.
the subject is about a bug with ossia.remote that fires a bang on load with type impulse.
This is a bug I'm about to fix.
For other discussion, please open another issue and sum-up the spec to something like : "when I do this, I get that while I'm expecting those".

Thanks

[avilleret]

this is fixed with 20ddeab

please open another issue to talk about default preset etc.