Add concept of built-in compartment presets

[helgoboss]

The current system of delivering "official" presets as individual ReaPack packs somehow turned out to be less great than I imagined.

It comes with the following disadvantages:

• With the advent of Playtime 2, I want to move to a more "everything-works-out-of-the-box" experience. Plug in a controller → Playtime asks "You connected a controller that is suitable for controlling Playtime. Do you want to use it for that?" → Yes ... that should be everything necessary ideally. That kind of thing wouldn't be possible if the presets are not available offline (auto-downloading presets would just make everything more complex, plus it would require internet access while using Playtime ... let's not go there).
• It's a burden for the average user because they need to install presets separately.
• It's a burden for me as a developer because I need to put each preset into the index. It could be automated but why go that way if it could be easier from the start.
• The freedom of installing "official" presets separately from ReaLearn plug-in can easily constellations where the ReaLearn version is too old to support a preset. It's then a responsibility of the user to figure out a working combination.
• The simple "Update to the latest ReaLearn" suggestion will not be enough in many cases.
• Official presets and user-defined presets get mixed in the same directory tree.

Initially, I saw the following advantages (over delivering built-in presets):

Possibility to pin a certain version of a preset (using ReaPack's "Pin" option)

• This could also be achieved by saving a built-in preset explicitly (e.g. under a new name) and then using that preset explicitly.
• The effect of always having the cutting-edge version of a preset is less bad than it sounds: Existing ReaLearn instances will not be effected anyway, unless one explicitly reloads the preset.
• It's still easy to forget pinning.

Users don't see hundreds of presets which they will never need anyway.

• There are ways to solve this with built-in presets, e.g. a better representation in the GUI.

Presets don't take space unless needed.

Preset space usage is peanuts compared to the rest of ReaLearn.

I was unsure about how to distribute the built-in presets without running into potential issues with file system storage when doing updates (delete all? delete only unmodified? delete complete directory vs. single files?).

There are ways, see below.

Rough concept

I'm planning to embed the built-in presets into the binary. That way they will not show up in the file system at all. But "Save as..." would be available in order to write it as an actual file.

Open questions answered:

Should it be possible for a built-in preset to be saved with the same ID as a built-in preset? And if yes, should that one take precedence over the built-in preset (e.g. as one way to pin a preset)?

No. It would cause confusion and make users wonder why updates on built-in presets are not applied anymore. The only possible application of overriding built-in presets (I can think of) is to pin a built-in preset or - more generally - substitute it with an own one. However, this can also be done without much effort and more explicitly by just using a user preset:

• If the preset is loaded manually (in a manual ReaLearn unit and without auto-load), substituting the built-in preset is just a matter of choosing the correct substitute preset when loading the preset. This is a conscious explicit decision. Once chosen, the contents of the built-in preset are saved anyway in that instance and don't change unless reloading the preset or another preset. So no issue there.
• If the preset is loaded automatically (either via the new "Auto unit" feature or with "Auto-load depending on FX"), choosing the substitute preset needs to be done only once globally.

In short, there's no case in which substitution requires lots of manual work.

ID conflicts can be prevented by making the ID of built-in presets by definition start with factory/. User presets which have that ID (by putting them into a folder named factory) should be ignored.

• How exactly present built-in vs. user presets in the GUI?

Maybe a pop-up menu instead of a dropdown. Divided into categories "User" and "Factory". In order to prevent very long preset lists, we could add one more nesting layer, e.g. "Manufacturer" if the preset meta data provides one. It's important to not nest like the directory structure. The directory structure should be solely used for namespacing the ID, not for categorization. Because categorization is subjective and can change. But preset IDs must not change!