Karya, built on 2018-03-16T03:22:32 (patch df7306861219887e676081746f4a4edfe05eb0b5)

Safe HaskellNone



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.



data Config Source #

Miscellaneous config data.




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

Unwrap the newtype for convenience.

allocate Source #


:: Inst.Backend

This should the result of looking up alloc_qualified in the instrument db.

-> Score.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 :: [(Score.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 :: [(Score.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.


Midi !Patch.Config 

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.




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.




  • 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.




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.