Documentation

Miscellaneous config data.

Unwrap the newtype for convenience.

Insert an allocation into config_allocations while checking it for validity.

TODO Of course there's no enforcement for this. I could get rid of the lens, but there is still uncontrolled access through modify_config. On the other hand, it might not really matter, and I do use unchecked modification when the backend doesn't change.

Make Allocations with no verification. This should probably only be used for tests, allocations from user input should use allocate.

This is make_allocations specialized for MIDI instruments. Like make_allocations, it also does no verification.

This is the root of the dynamic (per-score) instrument config. It's divided into common and backend-specific configuration.

How instruments work:

The terminology is a bit inconsistent, but the intention is:

Inst.Synth - Container for Patches.

Patch - Statically declared as haskell source, contains backend-specific configuration, as well as common config in Common.Common. They are grouped with the unfortunately named Inst.Inst, and the backend is Inst.Backend. They all have a unique name which is InstT.Qualified and looks like "synth/patch-name".

Allocation - An instantiation of a Patch in a particular score, and associates it with an Instrument. Like Patch, it also has common config in Common.Config and backend-specific config in Backend. Backend-specific config may be midi devices and channels for midi, and Common.Config can override settings from the Patch's Common.Common. E.g. allocate "vln1" to "vsl/solo-violin" on MIDI chan 1.

Instrument - The is a bit overloaded, but generally should mean ScoreT.Instrument, which is just a string used to look up an Allocation.

Both the Patch and Allocation have Backends and they should match, but this can't be statically ensured because Patch is statically declared in the source while Allocation is dynamic data which is saved to and loaded from the score files. verify_backends_match will check on allocation and resolve_instrument will crash if it notices mismatched backends don't match.

There is an additional Dummy backend. This is for instruments which are more abstract and don't correspond to a single Patch, but they can still have Patch level config such as special notation or env vars. For instance, pemade or gangsa can refer to a whole section, and must be expanded into specific instruments at the derive level. You can either allocate a Dummy from a Patch with Inst.Dummy backend, or allocate one from InstT.dummy, which will resolve to an empty Patch.

Backend-specific config. This should match the Inst.Backend of the instrument in question, ensured by verify_allocation.

I can't think of a way to ensure this statically, since the instrument and config are saved in instrument db and score respectively, and only come together when a new score is loaded.

Local Backend version of Inst.backend_name, keep them consistent.

Extra data that doesn't have any effect on the score.

A record of the last successful performance that sounded as expected. You can compare this with the current performance to see if code changes have messed things up.

I'm ambivalent about including this in the save file, since it will be saved and loaded all the time when it should rarely change. But it seems like the only reliable way to keep the score and performance in sync. Besides, it shouldn't actually be that large, and if it is, the git repo save should only save it when Config changes. I could also split it into its own file.

Initial values for derivation.

This used to have other fields, but they were replaced by the more general ky and the implicit GLOBAL call. I haven't removed tempo yet because it's the only way to change the speed for tempo-less blocks, and doesn't affect (or rather, is undone automatically) for integrated blocks.

This is a place to save sets of views so you can switch between them. The ViewId is the one with focus.