Revamping Beast Paths

[Tim Janik <timj gnu org>]

Hey all.

Here are my notes about Beast paths from last weekends meetup:

* To support starting Beast within the build tree, simplify installation and
simplify user visible search paths, we'll move paths out of library/ to unify
the hierarchies used during development and during installation and cut down on
explicit search path preferences.

* Paths should be discoverable relative to the Beast binary in order to support
moving of the installation directory after the build completed (esp. needed on
Windows).

* We need support for several lookup layers to support downloads and user files:
        1. User Files - Beast files stored in home (per user)
        2. Custom Search Paths - environment variables (per user)
        3. Media Packs - optionally downloaded after installation (per user)
        4. Stock resources - installed with the Beast package (per system)
        5. Standard OS paths - e.g. /usr/lib/ladspa, etc (per system)

* Temporary files, cached files and potentially big files need to be stored in
dedicated subdirectory hierarchies which may be symlinked, so users can move
these across filesystems (e.g. to evade quotas, backups or unburden a cryptfs).

* The entire Beast distribution is installed under a single directory point now
(when built from source as /usr/local/lib/beast-$MAJOR-$MINOR, or under
/opt/beast-$MAJOR-$MINOR when packaged) because installing media files, plugin
libraries, an electron bundle with CSS/JS, etc doesn't fit well with the FHS [1]
way of distributing files across a system. If anything, Beast comes closest to
an FHS /opt package [2]. Convenience links into the Beast hierarchy are provided
for bin/, man/ etc, so a properly installed Beast is readily usable.

* Concrete paths:
  /usr/lib/ladspa/ $prefix/lib/ladspa/ ~/.ladspa/ ~/.vst/ - known system paths
  LADSPA_PATH VST_PATH - configurable system paths
  $beastroot/Demos - demo songs, formerly beast.git/library/demo/
  $beastroot/Effects - stock effects, formerly beast.git/library/effects/
  $beastroot/Instruments - stock instr., formerly beast.git/library/instruments/
  $beastroot/Samples - stock samples, formerly beast.git/library/samples/
  ~/.beast/beastrc - config settings, formerly ~/.beastrc or ~/.bserc
  ~/.beast/media-packs/ - used to store optionally downloaded media files
  ~/Beast/ - User's media files to be processed by Beast
  ~/Beast/Projects - Beast project files
  ~/Beast/Effects - Beast effect files
  ~/Beast/Samples - Sample files
  ~/Beast/Instruments - Beast instrument files
  ~/Beast/Clips - clips to copy / paste
  ~/Beast/Extensions/ - extension scripts
  ~/Beast/Plugins/ - plugin libraries like .so files
  ~/Beast/Scripts/Controller/ - interface to controllers
  ~/Beast/Scripts/Hotkey/ - scripts to execute on hotkeys, etc

* Converted Samples, Soundfonts, etc are going into a similar hierarchy under
~/.beast/media-packs/

* Gus Patches - due to lack of use, Stefan recommends removing GUS support entirely

* Tentative API:
    enum class MediaType { PROJECT, DEMO, INSTRUMENT, EFFECT, SAMPLE, CLIP,
                           EXTENSION, CONTROLLER_SCRIPT, PLUGIN, LADSPA };
    vectory<String> get_search_path (MediaType);
    String          get_user_dir    (MediaType);

Naturally, it'll take some time until all these ideas are realized, also
feedback is welcome on any point presented here.

[1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES


-- 
Yours sincerely,
Tim Janik

https://testbit.eu/timj/
Free software author.