Skip to content
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

Closed
mjaskula opened this issue Aug 3, 2022 · 6 comments
Closed

[Project Suggestion] Configuration script #163

mjaskula opened this issue Aug 3, 2022 · 6 comments
Assignees
Labels
suggestion New feature or request

Comments

@mjaskula
Copy link
Collaborator

mjaskula commented Aug 3, 2022

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

  • PolySquare - set the mode for the ain: v/oct, detune, chord
  • consequencer - that one param that was added late
  • some parameters that are configurable in code now
  • TM: write 0 or 1
  • pico version (for eventual wifi support)
  • europi lib Voltage range
  • display modes
  • probapoly ain.mode
@mjaskula mjaskula added the suggestion New feature or request label Aug 3, 2022
@mjaskula mjaskula self-assigned this Aug 3, 2022
@djmjr
Copy link
Contributor

djmjr commented Aug 4, 2022

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)

@awonak awonak mentioned this issue Aug 9, 2022
@atulrnt
Copy link
Contributor

atulrnt commented Sep 30, 2022

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.

@mjaskula
Copy link
Collaborator Author

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:
https://github.com/mjaskula/EuroPi/tree/mjj/config_script

@atulrnt
Copy link
Contributor

atulrnt commented Sep 30, 2022

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 :)

@mjaskula mjaskula mentioned this issue Oct 21, 2022
@awonak
Copy link
Collaborator

awonak commented Dec 20, 2022

Another use case from @t-schreibs

I use the Harmonic LFOs script for a million things & being able to select several preconfigured presets with just a handful of UI buttons would be life changing.

@roryjamesallen
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants