Karya, built on Sun Nov 26 01:04:37 PST 2017 (patch 0a920b2bde70c0cbac8ee09d158064798b61bbe5)

Safe HaskellNone




This contains instrument data in common between different backends.



data Common code Source #




  • common_code :: !code

    Cmds and Derive calls. This is abstract so this can be defined without incurring a dependency on Cmd.Cmd, which would wind up being a circular dependency.

  • common_environ :: !RestrictedEnviron.Environ

    This environ is merged into the derive environ when the instrument comes into scope, and also when the pitch of Events with this instrument is converted. Typically it sets things like instrument range, tuning details, etc.

  • common_tags :: ![Tag.Tag]

    Key-value pairs used to index the instrument. A key may appear more than once with different values. Tags are free-form, but there is a list of standard tags in Instrument.Tag.

  • common_doc :: !Doc.Doc

    So, instrument, tell me about yourself.


Show code => Show (Common code) # 


showsPrec :: Int -> Common code -> ShowS #

show :: Common code -> String #

showList :: [Common code] -> ShowS #

Pretty.Pretty code => Pretty.Pretty (Common code) # 


pretty :: Common code -> Text Source #

format :: Common code -> Doc Source #

formatList :: [Common code] -> Doc Source #

code :: (:->) (Common code) code Source #

common :: code -> Common code Source #


newtype AttributeMap a Source #

This determines what Attributes the instrument can respond to. Each set of Attributes is mapped to a backend-specific value. The attributes are matched by subset in order, so their order gives a priority.

For example, if +pizz is before +nv, then +pizz+nv will map to +pizz, unless +pizz+nv exists. The idea is that more specific or more perceptually important attributes go first. Since pizz vs. arco is a much more obvious distinction than vibrato vs. nv, if you say everything is nv but some notes are also pizz, chances are you want those notes to get pizz even if there isn't a specifically nv pizz variant.

This also means that if a previous attr is a subset of a later one, the later one will never be selected. overlapping_attributes will check for that, but normally you use a constructor that calls sort_attributes to make sure that can't happen.


AttributeMap [(Attrs.Attributes, a)] 

overlapping_attributes :: AttributeMap a -> [Text] Source #

Figured out if any attributes shadow other attributes. I think this shouldn't happen if you called sort_attribute_map, or used any of the constructors other than AttributeMap.

sort_attribute_map :: AttributeMap a -> AttributeMap a Source #

lookup_attribute looks for the first subset, which means that a smaller set of attributes can shadow a larger set. Since it's annoying to have to worry about order, sort larger sets to the back.

The sort is stable, so it shouldn't destroy the priority implicit in the order.


data Config Source #

Configuration for a specific allocation of an instrument in a specific score.




  • config_environ :: !RestrictedEnviron.Environ

    This is a local version of common_environ.

  • config_controls :: !ControlValMap

    This is the control equivalent to config_environ. These controls are merged using their default mergers in the note call. Being in the note call means that the merge should only happen once. config_environ, on the other hand, is applied when the instrument comes into scope, which should be safe, since merging the environ is idempotent.

    This can be useful to set a per-instrument transposition, or dynamic level.

  • config_mute :: !Bool

    If true, this instrument is filtered out prior to playing.

  • config_solo :: !Bool

    If any instrument is soloed, all instruments except soloed ones are filtered out prior to playing.