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

A pitch interpolated a certain distance between two other pitches.

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.

The transposed version of Pitch.

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

Make an abstract 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.

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.

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.

Annotate a PitchError with additional info. TODO I should probably accumulate info all the way up to get a full "stack trace" of what happened to a pitch (e.g. interpolation), which maybe means abandon PitchError and just use Text, or go ever further with structure? Meanwhile, this seems to do ok practically speaking.

Things that can go wrong evaluating a pitch.

Note out of the scale's range. The values are transpositions from the environment, in case it was out of range because of a transposition.

Some scales have a restricted range, in which case they should throw out_of_range, which pitch_nn and pitch_note will annotate with the transposition signals. Other scales have unlimited range, in which case they're limited by the backend. In this case pitch_nn checks 0--127, which happens to be MIDI's limitation.

Some calls can operate in either RealTime or ScoreTime.

Duration can't be in Fractional since you can't multiple a RealDuration by a ScoreDuration, but scaling operations are still useful.

Insert a val directly, with no typechecking.

This is the type of first class values in the tracklang. It's main purpose is the type for arguments to tracklang calls, and val calls' return type.

Return Nothing if the Vals can't be compared, and whether or not they're equal otherwise.

Show a str intended for call position. Call position is special in that it can contain any character except space and equals without quoting.

Make an untyped VSignal.

This is just a Call, but it's expected to return a VPitch.

Transform the Symbols in a Call.

Another representation of a signal, complementary to Signal.Control. It's more powerful because it has access to a subset of the Dynamic state, as well as the Control is was originally bound to. However, it's also less powerful because you can't inspect it to see if it's constant, or emit exactly the samples present without resorting to sampling, or draw it on the UI. This is the ubiquitous code vs. data tradeoff.

In addition, the main motivation to add control functions was to randomize values, which means that, unlike signals, they're not actually functions at all, and thus couldn't be rendered as a continuous signal. This means that functions are only suitable for sampling at points, not for slicing over time ranges.

Having both signals and functions is awkward because then some calls may ignore a control function if they require a signal, which is inconsistent and confusing. This is the case for all control generators since the signal usually is on a control track and will wind up being rendered on the UI. So the convention is that control functions are generally just modifications of an underlying signal, rather than synthesizing a signal.

Another awkward thing about CFunction is that it really wants to be in Deriver, but can't, due to circular imports. The alternative is a giant hs-boot file, or lumping thousands of lines into Derive.Deriver.Monad. Currently it's a plain function but if I want logging and exceptions I could use Derive.Deriver.DeriveM. It still wouldn't solve the main problem, which is that I can't reuse the Deriver functions, and instead have to rewrite them.

See NOTE [control-function].

A simple pure function.

A stripped down Derive.Deriver.Monad.Dynamic for ControlFunctions to use. The duplication is unfortunate, see CFunction.