restructure dust scripts, SELECT menu, allow "projects"

[tehn]

dust restructuring

• move dust/lib to norns repo. encourage lua libs and engines to be collaboratively maintained/developed.

• remove the dust repo entirely. dust is now the local user folder. establish a "factory pack" of scripts that ship with a new device, or represent a cleanly-flashed image.

• proper matron startup behavior for non-existent ~/dust

projects

• project folder logic. "projects" can contain a bunch of extra files in their folder:

• default pset files (these should get automatically copied to dust/data if the scripts data/subfolder does not exist on first run

• other data files (and/or default data files)

• audio files

• "private" libs/engines can exist inside a dust script subfolder ie /scripts/tehn/lib. lua subfiles need to be called by include (basically do_file with path logic) as require will not watch these paths (and deal dynamically with reloading). scripts should not attempt to use private libs from another project.

• standard init/reset behaviors for script data folder ie contents of scripts/mlr/data is default data (psets/etc)

file management

see maiden issue

• upload single file from host
• download single to host
• upload zip (project) from host and auto-uncompress

git integration

see maiden issue

• add git url
• pull git
• reset git (in case of local edits)
• generate ssh keys
• push git

new menu behavior

• SELECT menu is a flat list, no folder diving. scripts represented this way:

mlr
earthsea/polyperc
earthsea/pluck
ish
tehn/mlr
tehn/mlr/alt
tehn/others/halfsecond

where the folder structure is:

mlr/mlr.lua
earthsea/polyperc.lua
earthsea/pluck.lua
ish.lua
tehn/mlr/mlr.lua
tehn/mlr/alt.lua
tehn/others/halfsecond.lua

1. a "project" folder with a single file named the same as the folder.
   2-3. a project folder with several files.
2. a raw lua file in the root folder
   5-7. within a subfolder, same pattern

• note 'lib' and 'data' folders are ignored in the list

• STARS (or favorites, whatever) is a set list. scripts can be added and sorted in specific order

• reset default script data (if default data is present for the project)

transition

• fix all existing scripts to ensure they're not broken by this change

• encourage versioning in scripts. 1.0.0

[tehn]

extra feature (future):

• favorites / set list. be able to line up a bunch of scripts for sequential execution.
• be able to launch scripts in this set list with specific pset files (or passing args to init() ?)

[nf]

favorites / set list.

counterproposal: 'select >' menu shows 5 most recently used scripts and 'all >' at the bottom to browse everything. or maybe even the favs list could be auto-populated by LRU until the user has nominated favorites.

[tehn]

@nf very good suggestion

[jasonw22]

How will script, library, and engine updating work, especially when script changes depend on library or engine changes? As a user, how will I be informed about changes?

[jasonw22]

monome/maiden#115 seems relevant to my questions, although project organization is an important piece of the puzzle.

[okyeron]

From a user perspective, what happens when I have 100+ scripts? That'd be a bunch of knob turning thru a long flat list.

Being able to subdivide a mass of scripts into groups (sub-folders similar to the current setup) would still be very useful.

[tehn]

re: long flat lists, agreed this is a concern.

alphabetical sorting and knob acceleration should make navigating relatively painless, but there's also been a proposition to have a "favorites" functionality which could be an ordered list, which would double as a "setlist" for sequential script execution during performance, for example.

we can explore the possibility of keeping subfolders, but i'm certainly not convinced that per-author is the correct structure.

[nf]

IMO it's worth trying the flat list initially and revisiting when we have the happy problem of too many scripts.

[pq]

STARS (or favorites, whatever) is a set list. scripts can be added and sorted in specific order

been thinking about this again and would love to revisit the idea.

#987 to track.