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

Safe HaskellNone

Instrument.Common

Contents

Description

This contains instrument data in common between different backends.

Synopsis

Documentation

data Common code Source #

Constructors

Common 

Fields

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

Instances

Show code => Show (Common code) # 

Methods

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

show :: Common code -> String #

showList :: [Common code] -> ShowS #

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

Methods

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 #

AttributeMap

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.

Constructors

AttributeMap [(Attrs.Attributes, a)] 

lookup_attributes :: Attrs.Attributes -> AttributeMap a -> Maybe.Maybe a Source #

Look up the value as described in AttributeMap.

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.

Config

data Config Source #

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

Constructors

Config 

Fields