A pitch signal is similar to a Signal.Control, except that its values are Pitches instead of plain floating point values.

Get the scale id of the signal.

A PSignal can contain pitches from multiple scales, though I don't think this should ever happen. But if it does, the first pitch wins.

PSignal can't take a Scale because that would be a circular import. Fortunately it only needs a few fields. However, because of the circularity, the Scale.Scale -> PSignal.Scale constructor is in Derive.Derive.

Flatten a signal to a non-transposeable Signal.NoteNumber. TODO I could probably avoid the intermediate list

A pitch interpolated a certain distance between two other pitches.

Resample the signal according to the sig_transposers and apply the given controls to the signal.

Controls are added so if this is not correct for a given control then this will do the wrong thing. Transpose signals should be additive so it'll be ok as long as you only apply transposing signals and only apply the complete ControlMap once at the end (i.e. Perform.Midi.Convert).

apply_controls specialized for a single control.

Apply an environ to all the pitches in the signal. Unlike apply_controls, this doesn't have to resample the signal.

The transposed version of Pitch.

This is an untransposed pitch. All pitches have transposition signals from the dynamic state applied when they are converted to MIDI or whatever backend. So if I want the final concrete pitch, I have to apply the transposition signals. But if I want to emit a note with this pitch, I want the untransposed one, or the transposition will be applied twice. I use a phantom type parameter to keep them straight.

A pitch is an abstract value that can generate a Pitch.NoteNumber or symbolic Pitch.Note.

A PitchConfig is the data that can continue to influence the pitch's frequency.

Pitches are configured by controls and by an environ. The controls are for values that change over time, such as transposition or tuning. They're combined additively, which is really only appropriate for transposition. Controls are mostly applied only on conversion to the performer. TODO I don't entirely remember why. However, this leads to some trickiness because if I want to compare a pitch to an absolute NoteNumber, I need the final transposed value, but if I put it in an event it must be untransposed, or transposition will be applied twice. To avoid double. To avoid this, there's a phantom type parameter to distinguish an untransposed Pitch from a Transposed one.

The Environ is for symbolic configuration, such as key or tuning mode. Unlike controls, though, it's taken from the environ in scope when the pith is created. Otherwise, you can't evaluate a pitch with a different key by setting the environ.

This is like pretty for pitch, but just shows the symbolic note name.

Things that can go wrong evaluating a pitch.

Make an abstract Pitch.

Apply a config to a pitch.

Apply just the controls part of a config to a pitch.

Usually I only want to evaluate a fully transposed pitch. Exceptions are documented by applying coerce.

Usually I only want to evaluate a fully transposed pitch. Exceptions are documented by applying coerce.

Create a Pitch that only emits the given NoteNumber, and doesn't respond to transposition.

Like constant_pitch, but easier to use, but uses no_scale, which means the result will be unparseable.