Select the flavor of thru to use when inserting an expression. This selects either expr_midi_thru or expr_im_thru.

Choosing manually is silly because the valid kind of thru depends on the patch type. It's just that due to history and wanting to avoid duplicated code, the Cmd and Derive code in here doesn't care about MIDI vs. im... except for thru.

Create a custom kbd entry cmd that inserts tracklang expressions at the insertion point. Since this shadows the default note entry cmd, it has to handle thru on its own.

Emit MIDI thru for an arbitrary expresison.

This is more accurate and principled than what the usual kbd entry cmds do, since it reuses the deriver and performer directly, while they recreate the performer in an ad-hoc way, e.g. in Cmd.MidiThru. However, this allows them to play chords and is thus more suitable for pitched instruments. Actually, what MidiThru recreates is the channel allocation part of the performer, ultimately becasue the performer's allocator doesn't work in real time. Still, perhaps it would be possible to integrate them better than I have.

Call a note call and return the MIDI msgs it produces.

Create a Cmd to set keyswitches.

This simply sets the note text for subsequent notes, and also configures the instrument to play in the given keyswitch.

TODO this just emits keyswitches for every addr and emits them redundantly. This is simpler but it would be more correct to use WriteDeviceState to emit them only when needed. However, it's more complicated because then I need a current attrs (Map Instrument Attrs) along with current note text, so MidiThru can use the attrs to find the keyswitch.

TODO if I can pull the current or previous note out of the derive then I could use that to play an example note. Wait until I have a "play current line" framework up for that.

Create an unpitched drum instrument. This is an instrument with an enumeration of symbols and no pitch or duration. Each key maps to its own symbol.

Construct code from drum strokes. This is both the deriver calls to interpret the stroke names, and the cmds to enter them.

drum_code, but with the opportunity to insert extra keys for insert_call. This is because insert_expr can't be stacked, since it consumes kbd entry keys it doesn't map, since it's confusing if it doesn't.

Create a MIDI patch for the traditional kind of drum instrument where each different stroke is mapped to a single MIDI keys. pitched_drum_patch is the variant where each stroke has a range of keys.

im is much simpler than MIDI and doesn't need all the keymap garbage. However, like drum_patch, this just sets patch config, the cmd and deriver code has to be added separately, see drum_code or drum_calls for that.

Used with pitched_attribute_map for MIDI instruments that do the strategy of assigning pitch ranges to each drum stroke.

(keyswitch, low, high, root_pitch). The root pitch is the pitch at the bottom of the key range, and winds up in Patch.PitchedKeymap.

Make a KeyswitchRange for each grouped Attributes set. Attributes in the same group get the same range and are differentiated by keyswitch.

This is like make_keymap, except with the arguments rearranged to more closely match the sample utils I use.

This is like make_keymap, except that attributes are differentiated by a Patch.ControlSwitch. CCs start at 102, and only groups of size >1 get a CC. Since each group is controlled by its own CC number, you can then select each variation independently. This means any set of variations can be played simultaneously, which is not true for keyswitches.

Annotate a Patch with an Patch.AttributeMap from the given PitchedStrokes.

Make PitchedStrokes by pairing each Drums.Stroke with its KeyswitchRange.

Create a drum_call for each Drums.Stroke.

This should probably go in DUtil, but that would make it depend on Cmd.Instrument.Drums.

For drum_calls. If Just, only strokes which are a superset of one of these move with the pitch, otherwise the stay at the given NoteNumber. If Nothing, all strokes move with the pitch.

This is the common deriver call that all drums and drum-like instruments use at the bottom.

Given a map describing how Attributes are mapped to the MIDI key range, take a key binding to a PitchedStrokes. The reason these are separate is that the map describes how a particular patch maps attributes, while the key binding describes the capabilities of the instrument itself.

If a mapping has Attrs.soft, it's looked up without the soft, but gets the given dynamic.