This was caused by the indicator-passed-selection check being inside a loop over all wave tracks. If there are no wave tracks, then the check never happened. I added a duplicate version of the check if there are no wave tracks. This may not be the best solution, but it works for now.
I'm not entirely sure why the check is in the loop (or what's going on with the len and maxLen variables); as such, I just haven't touched that. Perhaps it would be safe to move the check always outside of the loop, but I'm not completely confident in that.
Instead, always start a portaudio stream (if there is either a note track or a wave track). This ensures that playback is always in sync (eg when recording), and gets rid of a lot of duplicate logic throughout.
Scrubbing (currently) still doesn't work with only note tracks, but it should be easier to fix that now than trying to reimplement all of the scrubbing time logic.
Conflicts:
src/AudioIO.cpp
mMidiPlaySpeed doesn't handle all of the options provided by time tracks,
and in fact doesn't even use time tracks. Using the time track
instead allows note tracks to remain synchronized with the rest of the audio.
mMidiPlaySpeed _did_ work where it was used in the transcription tool
bar, but that already updates a time track so no special handling is
needed.
If the velocity of a note was, for instance, 30, and the velocity slider was at -30, then you'd get a data2 of 0, which wouldn't be clamped (and would produce a note off). However, if the note were 29 or 31, you'd get a velocity of 1. This makes it so that note ons always have a velocity of at least 1, even in that edge case.
PRL mentioned a while ago that it was possible to get channels greater
than 16 via allegro files. This makes those channels correctly work with
the CHANNEL_BIT macro (which was supposed to handle them this way before).
The fields in AudioIO are simply unneeded (commented out, declared but never implemented, or otherwise unused).
mLastMidiPosition (in NoteTrack) looks like the vestiges of a far older attempt at MIDI playback; the field itself is completely unused though so it is safe to remove it.
* MIDI Device Info menu item, like Audio Device Info
* MIDI device info in crash reports
* Only enabled with EXPERIMENTAL_MIDI_OUT, but tracks info related to the (unimplemented) EXPERIMENTAL_MIDI_IN
This was the fix for Bug 800 now considered unsatisfactory.
This reverts commit dc1193a0af83f1d43de5a30aea6b6b09087eea58.
(Some merge resolution was needed)
... As they did with Ctrl+Shift+F, with a certain minimimum number of wave
tracks that depends on screen resolution. On my Macbook, that was 13 tracks.
This bug was a consequence of James' TCP layout changes making buttons a little
taller plus my changes to hide any top controls for which there is not
sufficient height.
The fix makes the height of tracks after Ctrl+Shift+F a bit more (44 pixels
not 40) than in 2.1.3.
This fix also replaces some more "magic numbers" with calculation from
tabled data about TCP layout.
Problem: If the accessibility name of a control is empty, Jaws may use nearly text for the name - in this case Audio position.
Fix: Set the accessibility name to "\a".
... Really two crashes, one in case Linear frequency scale is selected, the
other if Logarithmic.
Problem was introduced at commit 7d5e54e364fcccd630274f2658703543d8c596eb
... also stop making the finger cursor at merge lines, because this prevew
supersedes that visual aid.
Toggling of snap lines can apply both to start and end of selection.
