add `recall_safe` attribute to ø.param to exclude it from preset loading

[bltzr]

in Jamoma, we did this for messages and returns... the equivalent of which would be to only include @mode BI in presets

my 1.52 brouzoufs

[jln-]

sounds good to me rather than adding a new attribute

[avilleret]

hum, OK in the meanwhile at least I'll use access mode to filter out parameter. Only BI parameter will be saved.

But what if (and it's my case actually) I want to control a parameter from a remote (and get its state) -- for instance a mic volume -- but I don't want to save it in the preset ? I do need the parameter with BI access mode to control it. So we need a new attribute in that case right ?

[avilleret]

more than not saving it, I don't wan't to recall it. The value should always be saved in the preset, but only restored the recall_safe attribute is fakse (which will be the default)

[bltzr]

Agreed !

What if recall_safe was false by default for mode BI```` andtrueby default for othermode```s

so the user can choose whatever they want, and yet we get a satisfactory behavior by default ?

would that make sense ?

[avilleret]

hum, should SET only and GET only parameter be saved in the preset file ? I'd say no. In that case, recall_safe attribute will be useless on those parameter

[bltzr]

I'd say that, by default, they shouldn't, but I don't see a reason to forbid that if that doesn't create extraneous technical complexities to implement my opinion

[jcelerier]

I'd say that, by default, they shouldn't, but I don't see a reason to forbid that if that doesn't create extraneous technical complexities to implement my opinion

it would. At that point, when attributes start to be part of the preset, wouldn't it be simpler to directly use the json of oscquery messages to represent presets ?

[bltzr]

oh, sorry, I didn't mean that - what I meant:

• we have a recall_safe attribute (or should it just be recalland default to 1?)
• when no value is set to recall_safe it defaults to: 1 for modes GET and SET and to 0 for mode BI
• if there is an explicit value to @recall_safe , then, well, we use the explicit value
• presets only save values of parameters with recall_safe 0

but:

• maybe that's too complicated
• that's different than @avilleret proposal, that recall_safe acts on the recall, not on the storing of values - this implies including this info in the preset, and treating it at recall time, which I think we should be cautious about (as a general rule, the less processing there is at recall time, the better it is, so recalls can be as fast as possible)

is that any clearer ?

[avilleret]

hum, about checking the attribute when loading the preset, this allow to recall or not the value as needed. For me, the attribute state should not be stored in the preset, only the parameter's value despite the recall_safe status

The first use case that comes to my mind is something that was asked during the ENSAT's workshop :

how to keep the hand on such parameter in live ?

Well, the question was more like adding a "touch"-like (cf. Protools glossary) automation mode (which let you rewrite the automation when touching the fader otherwise the recorded automation is played). But in my case, it would be :

ok well, this fucking actor is far from his expected position, let's do it my hand for this time, and he will pay his round of drinks"

Then enable the recall_safe to avoid the next cues modifying the parameter I'm currently controlling and disable it when the guy go back to a "normal" behavior.

Concerning the cue loading timing, checking a node attribute is nothing compared to looking for all objects in the patcher that are bound to this node...

About the name, @bltzr proposed recall which is shorter, and I like shortness but I think its less self-explaining than recall_safe but this might be because of my big amount of hours spend with Yamaha digital mixing desk (which inspired me the name). What @jln- and @matcham think about that name ?

[bltzr]

yes, if that's checked at loadtime, and not at recall time, then that's fine I guess, in the long run, the problem in this implementation is that (AFAIR) there is one and only action for load and recalling the preset (right ?) which is probably suboptimal because that involves disk access, which is usually slower, and we want preset recalls to be quick, don't we ?

as for the name, I agree that the full name recall_safe is most certainly more explicit, that must be my phobia of composed attribute names (and underscores in them), so if others prefer it this way, fine with me!

[jln-]

Sorry for being late on this, currently in a rush.

I'd also favor recall 1/0 rather than racall_safe 0/1.

Or maybe something along the line of ignore 1/0? preset 1/0? snapshot 1/0? Just thinking out loud.

[avilleret]

this is already implemented as recall_safe attribute in libossia and max and pd but now it's only used in Pd / Max

could you @bltzr & @jln- update the document (both help patcher and ossia.io) ? thanks

[avilleret]

now there are some function in ossia::preset that take care of recall_safe attribute when loading a preset and sort nodes by priority when storing.