Get edit buffer should add patch to current list, if any selected

[christofmuc]

I am now able to import patches one by one, following the sequence I described above. I made a "User list" called Juno-DS Favs.

Is there a way I can import the currently selected patch on the synth directly into my user list? Going through the entire process for each patch is a slow process, and feels awkward, partly because each time I press F8, the Roland Juno-DS menu folds up. This requires me to:

1) Re-open the Roland Juno-DS menu 2) ... and its By import submenu 3) ... and then the Edit buffer imports sub-sub-menu, 4) before I can drag the newly imported patch into my User list.

It would be nice if the User lists were implemented such that, if a User list was selected, F8 caused the imported patch to appear at the end of the user list.

Originally posted by @mslinn in https://github.com/christofmuc/KnobKraft-orm/discussions/274#discussioncomment-7266858

[christofmuc]

Additional, maybe better idea: Add a function get Edit Buffesr from all synths, and this automatically creates a new list with the current patches?

[mslinn]

Let's try to enumerate the use cases that should be supported, then fill in the details (user actions for each use cases) after the bigger picture is understood. Some of them might be the same or similar - optimize that after the list is complete.

Use Cases

1) New user, new synth 2) Existing user, new synth 3) Existing user and synth who used some other mechanism to add a collection of patches. 4) Existing user and synth who defined a small number (1..5?) of patches manually on the synth 5) Existing user and synth stumbling towards making a new patch

I do not believe the above is complete.

Functionality

The next step would be to describe the desired high-level functionality for each use case: I am still learning about the details of Knobkraft operation, so please correct any errors:

1) New user and synth a) Prompt for configuration details b) Detect synth c) Automatically back up predefined patches from synth into a new User list d) Display predefined patches

2) Existing user with new synth a) Detect synth b) Automatically back up predefined patches from synth into new User list c) Display predefined patches

3) Existing user and synth with recent bulk import of patches a) Detect new patches on synth and offer to back them up into new or existing User list b) Offer to upload recent patches to a central database somewhere

3) Existing user and synth with new hand-made patches a) Detect new patches on synth and offer to back them up into new or existing User list b) Offer to upload recent patches to a central database somewhere

5) Existing user and synth, stumbling towards a new patch a) Poll synth to discover new and modified patches b) When user activity is detected, make a snapshot

New / Existing Patch Detection

New patch detection would require distinguishing between renaming a patch and modifying an existing patch. This would require matching by name and a hash of the patch data. Possible user cases:

1) New patch 2) Renamed patch 3) Modified patch 4) Renamed and modified patches would be indistinguishable from new patches, so user intervention would be required

Git Repository as a Versioned Database

Git could essentially provide a versioned database. While existing git clients could be used for managing the versioned database, expecting users to learn git is unreasonable. Instead, libgit2 could be used without revealing to users that git is a dependency.

One patches have been downloaded from synths, putting the patches into a git repository should help automate new/existing patch detection. git diff is good at this.

Defining a remote would allow each user to back up their patches easily. Git repos could have a remote defined, and perhaps that would be recommended practice, but that is an optional extra and is unnecessary to use git as a versioned database.

When user activity regarding modifying patches is detected, automatically store changes as git commits. This would allow the user to recover from experimental accidents when modifying their patches.

A further possibility would be to create a central git repo for accepting pull requests for merging user patches into a central location.

Synth Patch Banks as Virtualized Drives

Imagine that a synth could be viewed as a virtual drive volume, and each patch would be a virtual file. This abstraction would allow existing directory-based mechanisms to operate directly on patch banks in synths.

Another benefit would be that user documentation could explain patches in synths as if they were files, and the UI for operating on that data would be the same as operations for patches in databases. Users would find the resulting software more intuitive.

No actual user-mode filesystems would be required; a shim would suffice. If libgit2 were used, for example, patch data would be provided via libgit2 function calls instead of a series of git commands.

The same shim interface could be applied to the patch database. If the implementation was an actual filesystem, then git command lines would be possible. Alternatively, the implementation could be a database. However, I expect that since all data would be memory resident, and search and reporting requirements would be minimal (no joins, for example), an actual database would not provide any benefit over a directory tree structure.