-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Project Suggestion] Configuration script #163
Comments
I think this would also have the advantage of being able to persist configuration changes when a script upgrades (as opposed to using constants within the code) |
This would mean leaving the script each time you want to update its configuration and going back into it to use it again. I can see that being an issue during a live performance. Another way to do it could be to add a generic way to set the configuration of the scripts, always accessible the same way from within the running script, whatever the ongoing script is, with the buttons pressed together at the same time for instance. As you explained, each script could have a dictionary or a list member variable describing their configuration so that this configuration UI would be automatically generated for each script. If the config member variable is a list, it could be a list of configuration objects for instance, these config objects would then be used to generate this config UI. This would have the advantage of letting the script run in background while the user is changing its configuration while also having a generic way of accessing those changes. |
The intention here is that the configuration options are 'set and forget' type options. Anything that would be useful during a performance should be accessible via the UI. The idea is that we can expose these configuration options without complicating the script itself (via concurrency) or its UI (via button presses). That said, I do agree that the interface that you propose would be nice. Most everything that I am developing for this feature would be reusable in the interface you describe. So what I'm thinking is that we first see if this feature is popular and then if there is demand to make the config options accessible while the script is running we can later explore that feature. I have started work on this feature here: |
Thanks for giving me this explanation, I get the point and it totally make sense. I checked your branch and indeed, it seems like some of it could be reused to create a generic config interface in the scripts, let see about that once you're done then! Good luck with this feature, it's looking great so far :) |
Another use case from @t-schreibs
|
With the merge of #220 and continuous development of the config system with plans to implement it as an interactive contrib script in the future, I think this project suggestion has been fulfilled |
Project Suggestion
I've noticed a bunch of places where scripts want to make a particular option configurable, but the limited user interface elements of the EuroPi make it difficult. These options are usually 'set and forget' type options, or are similarly not edited during normal script use. These options end up getting hidden behind long button presses, or are relegated to a well documented code change.
I suggest a script called 'Configuration' (or similar) whose purpose is to surface these options, but keep them from cluttering their script's UI. The script would present a hierarchical menu of config options for each script that has them, and provide a simple and consistent way for setting these options.
UI
The initial interface would be a menu of scripts, similar to the menu script. The left knob would select a menu item. The right button would select it, the left button would be 'back'. After choosing a script the user would be presented with a menu of the config options for that script. Again the buttons would be 'back' and 'select'. Upon selecting an option the user would see a screen for adjusting the value with the right knob. The buttons would be 'back' and 'save'.
API
Scripts declare that they have config points in the same way as declaring menu participation, imports in the settings app. And in the same way as the Menu, scripts would need to implement
EuroPiScript
to participate.Scripts would indicate that they have config options, by overriding a method. The method will return a data structure describing the settings. This structure will be well defined and will contain things like: name, type, type details (range), and default value.
Scripts would then have a member variable that would be a dictionary of name -> value that would automatically be loaded at script boot but the underlying
EuroPiScript
class.Settings would be saved in a json file per script in a settings directory.
Types
Example types: choice, bool, int, float, voltage, const
Examples
The text was updated successfully, but these errors were encountered: