Development Discussion – Read at your own risk!
In preparation for the feature TL , AKA Timeline, AKA F, I am beginning design of a better USB disk mode.
To recap, the current disk mode has the following characteristics:
- Automatically launches when USB flash drive
- Writes all scenes in flash to
- Reads all scenes to flash from
To begin designing the new feature, I think it would be wise to list how a USB disk might be used:
- Selectively save / load scenes
- Manipulate directory structure
- Rename / copy / move / delete files
- Paste scripts / patterns from other scenes
Obviously, this list is too broad to implement safely and too complex for non-power users. Direct access to the filesystem is inelegant, confusing, and error-prone.
Facet 1: To combat this, I think Scenes should be organized in banks, with 32 (eventually 16?) scenes available at a time in the user interface. This would permit us to keep the existing file name conventions and present a simple UI.
When a user wishes to copy a script from a scene in another bank, it will need to be parsed and loaded into memory. We should not have to load the whole bank, nor should we have to load the scene into the current bank. Facet 2: There needs to be scratch space available in RAM for one full scene.
When a user is navigating scenes, it may be difficult to remember where each known script is in the bank layout.
Facet 3: The UI should not list blank scenes in read select operations.
Facet 4: The UI should not list empty banks in read select operations (or there are no empty banks which a user has not explicitly allocated / created.)
Facet 5: The UI maybe should list the first line of the description for scene identification when listing scenes.
Points of Entry
We need to consider how a user might access data on the USB drive. Here are some possible use cases:
A user accesses the existing Scene Write mode and uses a keystroke to display a bank/scene selector and saves to USB. A user accesses the existing Scene Read mode and loads from USB as above.
- A user accesses a new, dedicated interface for all USB filesystem transactions.
A user is in edit mode and presses a keystroke to display a bank/scene/script selector to source a script from another scene into the current script. A user is in pattern mode and presses a keystroke to source a pattern from another scene as above.
(Edit: There’s no keyboard connected when a USB stick is inserted, DUH!)
Dedicated Filesystem Mode
A new display mode will need to exist to perform the following operations:
- Save / Load a bank to flash memory
- Save / Load current scene bank with a selectable bank slot
- Save / Load individual scene with a selectable bank / scene slot
- Copy one bank to another bank slot
- Copy one scene to another bank / scene slot
- Delete (clear) a scene
- Delete (clear) a bank
And, depending on design decisions, it may also need to perform:
Copy a script from one scene to another Copy pattern data from one scene to another
(Edit: no keyboard, will be an edit mode feature)
For more mundane usage, a user may wish for a way to use the USB filesystem that is as simple as the current method.
Facet 6: The default selectors for save and load should match the existing save/load idiom so that simplified behaviour is presented in as few keystrokes as possible.
That’s all I have on my mind at the moment. I will not edit this post. Further iterations of the filesystem idiom will be condensed into a future post in this thread to prevent confusion.
Like this post if you agree with it wholeheartedly and don’t have a preference on any of the decisions, reply (with relevant quote, please!) if not.
Edit: Other Facets
Facet 7: The USB UI will need to be entirely operated with the PARAM knob and the button.
Facet 8: Script / pattern copy will need to
either be performed from the current bank in edit mode , or from any bank in USB FS mode, or both.
Facet 9: USB FS mode menu options should have sane defaults.
Facet 10: USB mode must automatically launch when a USB stick is inserted and must automatically close when a USB stick is removed.
Tentative menu structure