Global preset and interaction with default values
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 231
- Forks
- 35
- Avg merge
- 8h 55m
- Merged PRs (30d)
- 14
Description
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the mockups referenced in the issue and the prior discussion in #595, then trace the existing [ossia] and [ossia.device] preset and default-value behavior. Define how initialization should traverse global presets, model presets, sub-models, and parameter defaults, including priority and firing order. Done means the behavior and implementation scope are agreed before coding.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100