Optimizations in sequencer core

There's an updated version, 0.0.30.001, which will process complex modulation setups significantly faster, due to some sorely-needed optimizations in the sequencer core. If you occasionally get the error "Sequencer Callback took too long" this version may help. Basically the sequencer was doing three dumb things:

1. Muted tracks were processing their modulators, pointlessly.
   
2. Modulator tracks were processing their modulators, pointlessly.
   
3. If a mute modulator evaluated true, the track's remaining modulators were evaluated, pointlessly.
   

All three of these were wasting precious time in the callback thread for no good reason. Large projects often develop subtle flaws like this, due to iterative design over long periods of time. Periodic performance checks and code reviews are a must.

Polymeter 0.0.30 adds synchronization via MIDI clock

Polymeter 0.0.30 optionally transmits MIDI clock, allowing you to synchronize your DAW or hardware sequencer with Polymeter. This was by far the most-requested new feature. The Start, Continue, Stop and Song Position messages are also sent as usual. Note that this feature must be enabled, via Options/Send MIDI Clock.

MIDI clock is old school, but it’s widely supported and works pretty well. There are some limitations, all involving the starting position. 1) Playback must start on a sixteenth note boundary; if you try to start from a position that isn’t evenly divisible by a sixteenth note, you’ll get a warning message and your starting position will be quantized to the nearest sixteenth note. 2) Playback can’t start from a negative position; this is MIDI’s limitation, not mine! 3) Similarly, playback can’t start from a position later than 16,383 sixteenth notes; again, not my fault. And 4) once playback is started, skipping forward or backward in the sequence will cause loss of synchronization; that’s because the MIDI clock specification doesn’t support position change during playback, alas.

This version adds some other handy features. For one, the ability to assign multiple modulators at once (via Insert Group on the Modulation bar’s context menu). This is especially useful with scale and chord modulation. And, the Step Values bar now supports multi-step editing; if the edited step is within a contiguous range of selected items, the track’s corresponding steps are filled with the new value. This is an easier way to set all of a track’s steps to some value, as opposed to using the Velocity pane.

Finally, this version supports assigning custom colors of tracks in the Track view. The color picker is in the main toolbar. This feature is disabled by default, but you can enable it via Options/Show Track Colors.

Polymeter 0.0.29 adds Chord Modulation and mapping to steps

Polymeter 0.0.29 introduces a major new feature called Chord Modulation, explained below. There are many other additions and improvements, including the ability to remotely control each individual step of a track. The release notes are here.

Chord Modulation

A scale is a subset of the chromatic scale. Each scale tone is a note, expressed as an offset in semitones relative to some base note. Assuming a base note of C, zero is C, one is Db, two is D, three is Eb, and so forth.

A chord is a subset of a scale. A chord can contain any number of tones, up to and including all of the tones of the parent scale. Chords are created by modulating a note track with a combination of scale, chord, and index modulators. Voicing modulators may optionally be added also.

Without a chord, index modulation accesses the tones of the current scale. The index modulation picks a scale tone, and the scale tone maps to a note. For example, suppose a note track has seven scale modulators, constituting a C major scale: C, D, E, F, G, A, B. The index modulation is interpreted as a zero-based index into that scale, ranging from zero to six. In other words, if the index modulation is zero the C is picked, if it’s one the D is picked, if it’s two the E is picked, and so on.

With a chord, index modulation accesses the tones of the current chord. This adds an extra level of mapping. The index modulation picks a chord tone, the chord tone map to a scale tone, and the scale tone maps to a note. Suppose the track has four chord modulators, which output 0, 2, 4, and 6 respectively. These correspond to the first, third, fifth, and seventh notes of the current scale. So if the scale is C major as before, the resulting chord is C major seventh.

Pitches:

Index	0	1	2	3	4	5	6	7	8	9	10	11
Note	C	Db	D	Eb	E	F	Gb	G	Ab	A	Bb	B

Scale:

Index	0	1	2	3	4	5	6
Scale Tone	0	2	4	5	7	9	11
Note	C	D	E	F	G	A	B

Chord:

Index	0	1	2	3
Chord Tone	0	2	4	6
Scale Tone	0	4	7	11
Note	C	E	G	B

In this example, when accessing the scale, indices 0, 1, 2 map to the notes C, D, E but when accessing the chord, the same indices map to the notes C E G. The chord gives the indices a different meaning.

Notice that three things are being distinguished: the subset of notes (the scale), the subset of scale tones (the chord), and which tone is picked (the index). All three of these entities are distinguished from the rhythm, which is determined by the note track. So we have an orthogonal system in which each axis (scale, chord, ordering, and rhythm) is independent of the others.

A demo file that makes use of chord modulation is attached to this post. The demo file uses chord modulation to implement the "Numbers" system of tonal palettes popularized by my ex-teacher, noted tenor saxophonist Jerry Bergonzi. This system was also implemented in my previous project ChordEase. The Numbers system is explained here.

Mapping to Track Steps

Why would you want to want to map a controller to a track step? I’m glad you asked that question. For one thing, it means you can control the tempo. Here’s how.

Create a track, change its type to Tempo, set its Length to one, and set its Duration to 100. The duration in this case is repurposed as the range of tempo scaling, as a percentage. The 100 means the tempo control ranges from half time to double time. Create a mapping for whatever controller you’re using. Within the mapping, set the Output Event to Step, the Output Control to zero, and the Track to your tempo track. Note that for Step mapping, Output Control is the zero-based index of the target step.

Start the sequencer. Your controller should now control the tempo. Zero gives you half time, 127 gives you double time, and at 64 the base tempo is unaffected.

There’s lots of other fun stuff you can do with step mapping. For example, you could make an empty track, and then map each of its steps to a key on a keyboard. Pressing and holding a note on the keyboard sets the corresponding step in your pattern. How hard you hit the key determines the step’s velocity. Playing a chord on the keyboard gives you a rhythm.
Try doing this for two different tracks, each with a different prime length. For example one could have a length of five and the other a length of seven. Create two sets of step mappings, one for each track, on different ranges of the keyboard. Now you can dynamically create two rhythms, one with each hand, and they’re in polymeter. Pretty cool!

Step mapping will most likely be useful for controlling the behavior modulator tracks, for example range modulation, voicing modulation, and so on.

Docking bars to tabbed panes: visible but inactive

Re the issue with not being able to dock Piano and MIDI bars to a tabbed pane: I looked into that some more. It's a non-trivial issue with pros and cons that need consideration. But the short form is this: Currently, keeping many of the bars in tabbed panes may make the UI sluggish. This is especially true of the Step Values bar!

When a bar is docked to a tabbed pane, Windows considers it "visible" even if it's not the active tab, in which case it's not actually visible to the user. In my current implementation, such "visible but inactive" bars receive document updates (affecting performance), though they don't get "painted".

It seems reasonable that hidden bars shouldn't consume any CPU cycles. When a bar gets "shown" my code assumes the bar is "dirty" (meaning it wasn't being updated while it was "hidden"), and updates it. But there's a catch to that work-saving strategy: bars that show real-time events (e.g. the Piano and MIDI event bars) will miss events that occur while they're hidden. This is why when you show the Piano bar, it doesn't display notes that were already in progress by the time you showed the bar; it missed those events.

It's also why I had to disable tabbed docking for Piano and MIDI event bars. Those bars have big impact, because they oblige the sequencer to send a "monitoring" copy of the entire output MIDI sequence to the main thread. If those bars were allowed to tab-dock (or auto-hide), they would drag performance even though they might not be visible to the user. This seemed wrong to me, so I disallowed it.

It's a messy situation with competing design goals. On the one hand, it's nice if bars don't consume resources while they're "hidden". On the other hand, it's annoying that when you show the Piano or MIDI event bars, events that occurred while they were hidden are missing.