Karya, built on Mon Jul 24 11:39:07 PDT 2017 (patch 33511aca01257b76b88de7c7a2763b7a965c084e)

Safe HaskellNone

Ui.UiConfig

Description

State.Config and State.Default, in their own module to avoid circular imports with State.Update. Everyone else should pretend they're defined in Ui.State.

Synopsis

Documentation

data Config Source #

Miscellaneous config data.

Constructors

Config 

Fields

allocations_map :: Lens.Lens Config (Map Instrument Allocation) Source #

Unwrap the newtype for convenience.

allocate Source #

Arguments

:: Inst.Backend

This should correspond to the alloc_qualified.

-> Instrument 
-> Allocation 
-> Allocations 
-> Either Text Allocations 

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 :: [(Instrument, Allocation)] -> Allocations Source #

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

midi_allocations :: [(Instrument, (InstTypes.Qualified, Patch.Config))] -> Allocations Source #

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

data Allocation Source #

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

data Backend Source #

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.

Constructors

Midi !Patch.Config 
Im 
Dummy

This is for instruments without a backend. For example a paired instrument might be written as one instrument, but realized as two different ones.

data Meta Source #

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

Constructors

Meta 

Fields

data Performance a Source #

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.

Constructors

Performance 

Fields

  • perf_performance :: !a
     
  • perf_creation :: !UTCTime

    The time this performance was recorded.

  • perf_patch :: !Text

    The sequencer's patch level. For darcs, this should be a patch name (technically it should be a tag's name, but it doesn't matter as long as I'm the only developer). For git, it would be the commit hash.

data Default Source #

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.

Constructors

Default 

Fields

type SavedViews = Map Text (Map Id.ViewId Block.View, Maybe Id.ViewId) Source #

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