Queue modulation released in 1.0.18.000

Video: The pitches of "Happy Birthday" assigned to a 3-5-7 polymeter

Queue modulation assigns a sequence of pitches to successive notes in order, regardless of note timing. Only note tracks support queue modulation. Unlike other modulation types, a queue modulator doesn't continuously cycle through its steps during playback. A queue modulator only advances when its target track plays a note. Until the target track plays its next note, the queue modulator remains frozen on its current step for as long as it takes.

A queue modulator is analogous to a line of customers waiting to pay. The customers stay in order, and the line only moves when the clerk signals for the next customer. The customers are the pitches and the clerk is the note track. But the clerk returns each customer to the back of the line, meaning the pitch sequence loops.

A queue modulator's quant is irrelevant because the modulator's stepping isn't driven by time. Any quant will do. The Track Steps view and the Step Values bar correctly report a queue modulator's current position, but other views may not.

Queue modulation decouples pitch from rhythm. This allows a melody to be constructed by applying a sequence of pitches to an unrelated or unquantized rhythm. Even if the rhythm is erratic due to rests, triplets, or syncopation, pitches won't be skipped.

If the target note track uses scale or chord modulation, each queue modulator step is a zero-based signed index that selects a tone from the current scale or chord. If index modulation is also used, the queue and index modulators are summed to produce the final index value. In any case the index value is wrapped as needed to stay within the scale or chord.

If no scale is defined, each queue modulator step is a zero-based signed offset added to the track's note. If note modulation is also used, the queue and note modulators are summed to produce the final note value.

A note track can have only one active queue modulator. Multiple queue modulators can target a track without conflict provided only one of them is unmuted at a time. If a note track has multiple unmuted queue modulators, only the last one is used and the others have no effect.

A queue modulator can target multiple note tracks at once, but this should be considered carefully. If multiple targets are unmuted, they compete for the modulator's pitches, and this potentially alters the sequence, which may or may not be desirable. If only one of the targets is unmuted at a time, there's no issue and the pitch sequence is preserved.

To repeat a fixed melody, the queue modulator should have one step for every note in the target track. Otherwise, the melody may vary over time due to phasing. In the fixed melody case, a queue modulator can lose synchronization with its target note track. This can happen if the note track is muted during the middle of its cycle, for example. To enforce synchronization, a queue modulator can be periodically reset to its start using internal controller 102 (Queue Mod Reset).

Queue modulators can be targeted by mute modulation and position modulation, but they don't support offset modulation.

Position modulation causes a queue modulator to skip forward or backward in its sequence by the specified number of steps, but the effect is temporary and non-destructive. The target track may receive a different queue modulator step than it otherwise would have, but the queue modulator's internal position is unaffected.

Why playing a second time the same note shut down the first one?

[This is a copy of my answer to a question on Stack Exchange's Music Practice and Theory forum.]

Overlapping notes cause ambiguity in a MIDI stream because a MIDI note off message isn't explicitly linked back to a note on message. The illustration below demonstrates the issue. Two notes of the same pitch, 1 and 2, overlap in two different ways, but the exact same MIDI messages are received in both cases. In the first case, note 2 starts after note 1 and extends beyond it. In the second case, note 2 occurs entirely within note 1.

1   2   3   4       time
+---+---+---+---
On  On  Off Off     MIDI stream

11111111            1st case: note 2 starts after note 1
    22222222

111111111111        2nd case: note 2 occurs within note 1
    2222

The stream of MIDI messages doesn't contain enough information to allow a receiver to distinguish between these two cases. The sender knew which case it was, but the receiver doesn't know, and can't know, because data was lost. This ambiguity could have been avoided if a MIDI note message explicitly specified its duration, instead of expecting the receiver to infer the duration from a subsequent note off, but that ship has sailed.

A MIDI instrument can handle overlapping notes in two possible ways. The most common way is this:

• The first note on message starts the note.
• The second note on message ends the first note and starts a new one.
• The first note off message ends the note.
• The second note off message is discarded as spurious.

This method truncates one of the two instances of the note. It's easy to implement, but it's inaccurate and often causes user complaints. Here's a diagram of it:

1   2   3   4       time
+---+---+---+---
On  On  Off Off     MIDI stream

1111                
    2222            note is (unjustly) truncated at time 3

The right way is instance counting. The instrument maintains a count for each note, which indicates how many instances of that note currently exist.

1. The first note on message starts the note (count: 0 to 1).
2. The second note on message starts a second instance of that same note (count: 1 to 2).
3. The first note off message ends one of the two instances of the note (count: 2 to 1).
4. The second note off message ends the other instance of the note (count: 1 to 0).

How does the instrument decide which instance of the note to end at step 3? It has no basis on which to decide, but it doesn't matter, because both instances are presumed to be identical, so either will do. Here's an updated diagram:

1   2   3   4       time
+---+---+---+---
On  On  Off Off     MIDI stream

111111111111        proper overlap handling
    2222

Instrument manufacturers often don't bother with instance counting because it's extra work, and also because stuck notes could occur if the counts somehow get scrambled. Another potential downside is flanging, because during the period of overlap, two sound generators are producing the same sound. Nonetheless instance counting is definitely more correct than truncation.

Instance counting still doesn't allow the receiver to distinguish between the two cases I mentioned at the beginning. You might think it doesn't matter, and for an instrument, you'd be right. But for a music editing software, it does matter, because such software is expected to display the notes correctly, including their durations. In that case, again, the MIDI stream lost crucial information, so there's no proper solution, and the software has to arbitrarily pick one of the two cases. FWIW my MIDI sequencer does distinguish between these cases; see the Note Overlap manual page.