... But make them nondistinct in all themes, so this commit does not yet make
user visible changes.
This uses the HiliteButtonExpandSel resource which was previously unused.
Perhaps not the intended use of the resource so named, but names can change in
2.2.1.
The two were already alike in Classic but the unused one had been just black
in the others.
Previous fix was at commit f9865f39efe46224a1a77c742a789b2cc70f0c54
But then that had this strange effect on Mac: when a menu command such as
rename brought up a modal dialog, then the first click in the dialog would pass
through to the tracks behind it, changing the selection, and only a repeated
click on the OK button would dismiss the dialog.
I don't know exactly why that happened. This avoids it.
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)
