value output on object instantiation / changing address

[avilleret]

When an ossia.parameter object is instantiated, it output its default value if it has one. When its address or its path (by adding an ossia.model in one of the parent patcher) changed, this is the same : we only fire a default value if there is one.

When an ossia.remote is instantiated, it should output the parameter value if it has one (not only the default value). Thus if we change a parent view's address, to bind a view to another model, all the remotes output their values to keep gui objects in sync.

I think @jln- requested this behaviour, and I agree with him. But @evanmtp seems to disagree as reading its post on #624 :

Additionally, all ossia.remotes that are attached to this ossia.parameter should inherit the same behaviour.

So I let the discussion open to reach a consensus.

[avilleret]

of course others inputs are welcome, @maybites @bltzr @jcelerier @matcham et al.

[maybites]

I agree.

There is maybe a fringe case that would suit @evanmtp :What happens with the ossia.remote when the parameter has no value (no default and recall_safe = 1)? I would assume it doesn't output anything, right?

[avilleret]

as of today, @recall_safe only affect preset recalling, so if a parameter as a default value and @recall_safe 1 then its default value will be fired at instantiation, and the attached remote will output the same value too. But if it doesn't have a default value, but the parent model have a default preset that contains a value for this node, then the value will not be fired because of the @recall_safe 1. (this is not implemented yet, but it has been discussed in #613) And if it has a default value and the parent model default preset has a value for this node, then the default value will fired and not the preset value.

[evanmtp]

I think that so long as there's a way to create parameters that don't automatically output a value when instantiated, that covers my needs. I believe that when things are changed so that parameters without @default set to anything don't fire (and the same holds true for the corresponding remotes), this will take care of it for me.

[maybites]

so to recap - and please correct me if I am wrong (most likely):

 @mode | @default | @recall_safe | parent model preset |    parameter    |      remote      |
   bi  |     y    |       0      |         no          |   fire default  |   fire default   |
   bi  |     y    |       1      |         no          |   fire default  |   fire default   |
   bi  |     y    |       0      |         y           |   fire preset   |   fire preset    |
   bi  |     y    |       1      |         y           |   fire default  |   fire default   |
   bi  |    no    |       0      |         y           |   fire preset   |   fire preset    |
   bi  |    no    |       1      |         y           |         -       |        -         |
   bi  |    no    |       0      |         no          |         -       |        -         |
   bi  |    no    |       1      |         no          |         -       |        -         |

  set  |     y    |       0      |         no          |   fire default  |        -         |
  set  |     y    |       1      |         no          |   fire default  |        -         |
  set  |     y    |       0      |         y           |   fire preset   |        -         |
  set  |     y    |       1      |         y           |   fire default  |        -         |
  set  |    no    |       0      |         y           |   fire preset   |        -         |
  set  |    no    |       1      |         y           |         -       |        -         |
  set  |    no    |       0      |         no          |         -       |        -         |
  set  |    no    |       1      |         no          |         -       |        -         |

  get  |     y    |       0      |         no          |   fire default  |   fire default   |
  get  |     y    |       1      |         no          |   fire default  |   fire default   |
  get  |     y    |       0      |         y           |   fire preset   |   fire preset    |
  get  |     y    |       1      |         y           |   fire default  |   fire default   |
  get  |    no    |       0      |         y           |   fire preset   |   fire preset    |
  get  |    no    |       1      |         y           |         -       |        -         |
  get  |    no    |       0      |         no          |         -       |        -         |
  get  |    no    |       1      |         no          |         -       |        -         |

[jln-]

Thanks for the recap @maybites . I'll take a closer look at it tomorow.

I think for clarity we can set the remote out of the loop regarding init discussion. The rule for remote being (imho) that it outputs the parameter it is binding to current value (no matter how this value is set).

If we dont want a remote to output its parameter value, we can either not make it bind to a parameter or set the 'enable' attribute to 0 or 'mute' to 1. (not totally sure what is the difference between the two at the moment, but that's another story...).

I am not sure about the remote behavior regarding get or set parameters. I'd tend to think that the remote behavior is the same for all parameter modes. But no strong opinion about this.

[evanmtp]

@maybites , thanks for the analysis! The bi and get sections look fine to me. I'm just wondering why the remotes are excluded from the set section. I agree with @jln- that it makes sense for the remote behaviour to be the same for all parameter modes.

Also, I'm assuming that the - states should be interpreted as "do not output a value," and not "undefined behaviour."

@jln-, in some cases I'm dealing with, it's important to have a way to make sure that remotes do not fire their value on load, but also are able to receive/send values to/from their corresponding parameters after. An example of this would be a parameter that gets a bang from a UI element connected to a remote in the view and uses that to open a window. The remote has to be bound to the parameter in order to pass the bang when the user clicks. If it's muted, I would need to either create another remote/parameter pair to unmute it later (which seems like it could lead to some sort of infinite regress of remotes unmuting remotes unmuting remotes), or else unmute it with e.g. a loadbang/delay, which always feels risky to me due to scheduler weirdness. Having the remote inherit the behaviour of the parameter seems like the simplest way of doing this. There might be other cases that I'm not thinking of, though.

[avilleret]

thanks @maybites for this wonderful sum-up, I think we should put it somewhere in the help patchers.

but I agree that remote should output their value even if parameter's mode is set and always reflect parameter's value.

[maybites]

@avilleret you just metioned (https://github.com/ossia/libossia/issues/624#issuecomment-733956790):

The @mode attribute is a hint for remote client to let them know what they can do with the parameter. With mode set the client knows that it is useless to listen to change. With mode get the client knows that it is useless to try to set it.

which contradicts

but I agree that remote should output their value even if parameter's mode is set and always reflect parameter's value.

hmm..

@bltzr gave here (https://github.com/ossia/libossia/issues/504#issuecomment-505881487) a passionate vote for sending parameter value to remote with @set.

I guess you guys are arguing it means:

with mode @set the model (or client) gets the current value from parameter only 
on time of creation of the model (or client) - be it on or after the creation of parameter - 
but not anytime afterwards.

which is fine with me. I am just a sucker for clear definitions.

[evanmtp]

Hi folks, I made some test patches to check the parameter and remote behaviour. Please take a look - comments and revisions welcome.

paramTest.zip

The patch to open is _paramTest.maxpat . This contains a two pairs of models and views. One (y) has a preset saved for it, and the other (n) does not. There's also an overall preset for ossia.device.

Some observations:

• I'm currently loading the model preset followed by the device preset using a loadbang/t object. This doesn't actually work in terms of preventing the model preset values from being overwritten by the device preset. Is there some other way of doing this?

• Among the parameters that have @default values, currently only the BI parameters fire their default values. This does not conform to the behaviour in maybites' analysis, where all parameters with defaults should fire.

• Based on the fact that only the parameters with @recall_safe 0 fire when the model preset is recalled, @recall_safe seems to be working correctly.

• When the device preset is recalled, only the parameters that have @recall_safe 0 fire. However, the BI remotes that have defaults set also fire, although the corresponding presets don't. Is this expected behaviour?

[avilleret]

I'm currently loading the model preset followed by the device preset using a loadbang/t object. This doesn't actually work in terms of preventing the model preset values from being overwritten by the device preset. Is there some other way of doing this?

This won't work because we don't know which one between the loadbang object and le ossia object is being loadbanged first. As a workaround, I proposed to use the @default attribute for model to specify a preset file to load at startup. Ossia-max framework takes care of registering all ossia objects before firing default values. This is discussed in https://github.com/ossia/libossia/issues/613 but won't be implemented before next year.

Among the parameters that have @default values, currently only the BI parameters fire their default values. This does not conform to the behaviour in maybites' analysis, where all parameters with defaults should fire.

Since I think we reach a consensus with @maybites analysis (but for the remote bound to parameter in mode set that should always reflect parameter value to me) I think I have to review the current behaviour to follow @maybites description.

When the device preset is recalled, only the parameters that have @recall_safe 0 fire. However, the BI remotes that have defaults set also fire, although the corresponding presets don't. Is this expected behaviour?

This sounds like a bug to me.

[maybites]

Since I think we reach a consensus with @maybites analysis (but for the remote bound to parameter in mode set that should always reflect parameter value to me) I think I have to review the current behaviour to follow @maybites description.

to be clear: this list was not my analysis of the current behavior but a representation of my understanding of how I thought it should work. here an updated version without the @mode attribute that according to the above discussion should have no influence:

@default  | @recall_safe | parent model preset |    parameter    
     y    |       0      |         no          |   fire default  
     y    |       1      |         no          |   fire default  
     y    |       0      |         y           |   fire preset   
     y    |       1      |         y           |   fire default  
    no    |       0      |         y           |   fire preset   
    no    |       1      |         y           |   fire nothing      
    no    |       0      |         no          |   fire nothing  
    no    |       1      |         no          |   fire nothing  

[avilleret]

I agree with that updated list and as soon as #613 will be implemented, this behaviour should be there.