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.
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
Simplify the logic of duplication of NoteTrack. Duplicates are always in
serialized state. Un-serialization can happen on demand in any of the
NoteTrack operations that require a defined sequence.
Changing the duration of the sequence after paste is needed,
as it was also needed, when I fixed Stretch at commit
90eb4ec142f7d575d0870dd9c755589bff520cbe. I don't know if this should be
considered a bug in Allegro that we are compensating.
This reintroduces the buttons to toggle display of individual midi
channels, and cleans up the code behind that feature.
This functionality has actually been present in production versions of
audacity for a while, at least for clicking. However, the buttons
themselves were not drawn, making it exteremly painful (but possible) to
use.
As requested by PRL, this is always enabled if USE_MIDI is defined.
... in WaveClip and WaveTrack, to save as much recording as we can,
assuming the strong guarantees that Sequence will give.
Also comment that some other WaveTrack methods can give strong guarantee,
incidentally to making HandleClear give strong.
... The return codes were mostly ignored anyway, and exceptions will be thrown
instead.
It seems there was also confusion whether the return values of Track::Paste
and Track::SyncLockAdjust were to indicate success or indicate whether there
was any change. No matter now.
"Velocity" is the technical term, and it's the term that's used everywhere.
"Gain" was probably only used because "gain" is used on wave tracks; since
note tracks aren't wave tracks (and shouldn't be treated as them) the
corresponding variables should be named velocity.
The compilation was broken in 67cec5a but fixed in ed8c7fd. However, the warnings weren't fixed. The same general sign-related changes from 67cec5a were applied, fixing several warnings.
This also changes the arguments for NoteTrack's label click handler, to match the ones found in TrackPanel. That's needed to handle some other const-related changes.
Additionally, EXPERIMENTAL_MIDI_PLAYBACK was changed to EXPERIMENTAL_MIDI_OUT in the documentation, as that is the correct name.
... whenever they really describe the size of a buffer that fits in memory, or
of a block file (which is never now more than a megabyte and so could be fit in
memory all at once), or a part thereof.
... with run-time assertions.
I examined each place and reasoned that the narrowing was safe, and commented
why so.
Again, there are places where the sampleCount variable will later be changed
to have a different type, and they are not changed here.
... A non-narrowing conversion out to long long is a necessity, but the
conversions to float and double are simply conveniences.
Conversion from floating is explicit, to avoid unintended consequences with
arithmetic operators, when later sampleCount ceases to be an alias for an
integral type.
Some conversions are not made explicit, where I expect to change the type of
the variable later to have mere size_t width.
... Define lots of operators for disambiguation, but they will go away after
all conversions from sampleCount to built-in numerical types are forced
to be explicit.
... And in some places where a library uses signed types, assert that
the reported number is not negative.
What led me to this, is that there are many places where a size_t value for
an allocation is the product of a number of channels and some other number.
... This makes much code agnostic about how other things (functions and
arguments) are typed.
Many of these neeed to become size_t instead of sampleCount.
Fix by Uwe and Carsten of DirectSound issue (only). We can't interrogate for formats, so we use userData to tell PortAudio what the format should be. I have a 16 bit built in sound device and that continues to function correctly at 16 bit with 24 bit requested. Unable to test on a 24 bit device.
