Global preset and interaction with default values

[bltzr]

As has been previously discussed several times with Jamoma (including @jln- ) and with @evanmtp @navid and @petervanhaaften (and also in #595) it might be interesting to possibly and eventually fuse the default and preset systems.

As is described in the mockups below, the idea would be to have a global preset system, with an init preset, that would be fired once all models are loaded. It would work this way, by going from the global preset (held by the [ossia] object and/or [ossia.device] objects, down to each model's preset, recursively, and down to each parameter's default value - for each parameter:

• first look if a value is present in the global preset, use this one, and ignore all values "below"
• if not, then look into the preset of each model (and then sub-model), if a value is present, use the most top-level one
• if no value is present in presets, then use the default value
• if no default value, don't do anything
• fire all chosen values, for all parameters, by order of priority, recursively (don't fire anything for parameters without a preset or default value)

Does that make sense ?

I'm putting some diagrams about this that we did a few years ago with the Jamoma team

[bltzr]

[jln-]

Totally makes sense to me and obviously agree it would be neat.

Pinging @matcham as it may be interested in the discussion.

For the sake of it, here is also a hacky way of doing such thing I was thinking about this afternoon: having an ossia.model attribute so when instanciating a patcher model in main patcher, one can set whether init from parameters' default attribute or not ([my_synth.model @usedefault 1/0]).

I'd certainly favor the cascading approach, though.

[avilleret]

is it something specific to max ? or should we think more globally and add this functionality to libossia-core ? what do you think @jcelerier ?

[bltzr]

I don't think we have models in libossia (or do we?), but maybe that would make sense in this case (to hold presets), idk...

[jcelerier]

I think that models / view make sense in max, bt not really in e.g. java, python or whatever so not sure about that one.

[avilleret]

ok so I tag this issue as specific to max and I propose to use the @default attribute on model to load preset as described by @bltzr

[evanmtp]

Adding my support for the cascading approach, very intuitive. I know @navid is particularly keen to have per-model presets, similar to the way that existed in Jamoma.

@avilleret , when you say "use the @default attribute on model to load preset", could you clarify? To me it seems like @bltzr 's proposal entails checking if each ossia.parameter has @default set to something (or has a value stored in an initialization preset), but I'm not sure I understand what setting @default on the ossia.model would do.

[bltzr]

Also not sure what you mean by '@default' here @avilleret : what would that do exactly?

[avilleret]

well, I propose a name for the attribute that defines a default preset and that name could be @default. The same attribute name defines a default value for parameter. I thought it is quite intuitive to use the same to define the default preset for model.

@navid is particularly keen to have per-model presets

But that should be already the possible, you should be able to save a preset on a model and apply it on another instance of the same model (or on another model but it makes less sense). (I'm talking about ossia preset here, the one you save with the [preset save ...( message) If that doesn't work, please open an issue.

[bltzr]

But, can ossia.model hold different presets? Or would this attribute hold a preset path?

[bltzr]

About "per-model presets", I guess what's implied here is that there is a default preset file for a model, with a default preset, which is recalled when the model is loaded. I'm not sure, but I don't think we have this... But anyhow, I think we should think about this in a more generic way, with the cascading preset system, for example.

This should be done in two steps, IMHO :

1. What do you folks need for now that you cannot achieve by patching?
2. we should take the time to make generic and future-proof specs, for instance during a dedicated workshop

What do you all think?

[avilleret]

But, can ossia.model hold different presets? Or would this attribute hold a preset path?

In my mind, @default attribute hods a path to a preset file that is loaded at instanciation.

[jln-]

About "per-model presets", I guess what's implied here is that there is a default preset file for a model, with a default preset, which is recalled when the model is loaded. I'm not sure, but I don't think we have this... But anyhow, I think we should think about this in a more generic way, with the cascading preset system, for example.

This should be done in two steps, IMHO :

1. What do you folks need for now that you cannot achieve by patching?
2. we should take the time to make generic and future-proof specs, for instance during a dedicated workshop

What do you all think?

Agree with all points. For sure this is an important and complex topic that needs some time to properly spec things.

[evanmtp]

As far as @petervanhaaften, @navid and I go, for the moment I think that we can really get away with using the @default attribute on parameters to set up the generic initialization state for models. Per-model presets, à la the way they were done in Jamoma with the drop-down menu at the top of the view, would be a nice amenity to have eventually, but I don't think they're critical for us at the moment. I agree that it's worth taking the time to spec this out correctly.