I find the way settings are managed kind of counter-intuitive between the global config and the song config and find always myself looking first in the song settings before realizing it’s actually at global level. Having then to switch back to main menu, reply if I want or not to save the song etc… And redo that again and again with the next song
This topic is a proposal which goal is to lead to an easier config management, more versatile and potentially even more resilient regarding firmware updates.
All this for me comes from the fact the split between what is today the global config and the song config is arbitrary and at least not really consistent.
The song config contains settings that have clearly their place at song level, but they lack some default values.
The global config contains some settings that are really system-wide, like all those related to routing for example.
But it contains as well some settings that are arguably system-wide, like clicks management for example or even flags related to how transitions should occur. They could completely be at song level either.
Everything starts by first identifying the global settings that are really system-wide. And really apart routing and maybe some MIDI settings, I do not see any other.
My proposal is to migrate all settings to global settings, without exception.
When a song is created all song-related settings present at global config level (let’s call them template settings now) are duplicated at song level and become the song config. You can then tweak them without changing the global settings (like clicks for example, that you may definitely want different for this or this song).
- You simplify navigation within the device to access settings.
- You bring more features in terms of tweaks at song level.
- You introduce a nice templating mechanism for song settings values
- Here it’s just a guess and maybe I’m wrong, but I feel like if you introduce new stuff at global template level (now in global config) with a new firmware, you would not impact previously recorded songs, which only need their local config (a kind of backward compatibility).
From a development point of view depending on your architecture it may be not so costly (there I am in full guess mode, so forgive me if I’m wrong):
- The UI is already there, not necessarily at the right place.
- You probably already build a kind of context when you start a song. You would just build it differently (probably simpler).
- You impact the song creation flow by introducing a settings copy mechanism at that time.
Even if obviously not urgent, if you assess such a migration is not so costly, I would definitely say that it brings a lot of possibilities while bringing a much cleaner navigation flow for the user.