... in case you also do things, concurrent with the recording, that affect the
undo stack, either by pushing it (such as by changing the gain on one of the
playing tracks, or making a label) or by "Modifying state" without a new undo
item (such as when you change its size or mute or solo).
... This even makes it possible to remove the prohibition of undo and redo
during transport, not that we want to though. Playback and recording will
continue, using track objects that might not be in the current project.
- Dead code from experiments in SelectionBar removed.
- Many warnings about unused parameters fixed with WXUNUSED()
- Many warnings about signed / unsigned comparisons cleaned up.
- Several 'local variable declared but not used' warnings fixed.
... caused by remembering a NULL pointer to active project when starting a
stream.
Hard to reproduce, but reported by David Bailes. We suspect that both the
closing of another project window, and changes of focused application, are
necessary to reproduce the problem.
... Write only one variable in audacityAudioCallback, to be read (maybe in
another thread) by AudioIO::MidiTime().
The non-Alsa case behaves essentially as before: it wasn't broken, so it
isn't fixed, though it is rearranged.
... I am not sure that this will solve all problems of jittery play, but I do
think this will solve the problem of a rush of slightly late notes at start of
play.
... and hoping it is positively helpful for Linux.
In AudioIO::MidiTime(), compute one of the terms by different means.
Use PaStreamInfo::outputLatency.
Do not use the difference of PaStreamCallbackTimeInfo::outputBufferDacTime
and PaStreamCallbackTimeInfo::currentTime.
Which debugging shows is very nearly the same value for Windows and Mac.
But we suspect the PaStreamCallbackTimeInfo fields are not correctly reported
on Linux.
... At least it fixes the gross problem; but there seems to be a small
accumulation of error still each time around the loop, that I don't understand
yet.
... Used to be, it became true too soon when play started after time 0, so
AudioIO::IsStreamActive() might become false too soon -- except that now there
is always a portaudio stream when there is a midi stream, so that didn't happen.
Mistake was to add mT0 to MidiTime(), which already has mT0 for its origin.
This error would affect nothing if you just let play to the end without trying
a keystroke command. The error might have been enabling the wrong commands.
... after I reflected more on the explanation of it in the long comment at top.
Brings back the use of PaUtil_GetTime() but now calls it also in the audio IO
callback, so we can correct the unspecified origin of times supplied to the
audio IO callback to agree with the PaUtilGetTime() clock.
Thus the Midi time calculation is again based on the clock time of the other
thread that calls MidiTime, making it a few milliseconds more accurate, while
avoiding subtraction of two times based on widely different origins, which
made the big numbers that overlowed and caused Bug1714 to happen.
Don't assume Pa_GetStreamTimePaStreamCallbackTimeInfo origin is time-of-day.
portaudio.h says you should not, and in fact it was not.
The report is that this gets us some play, but there are still freezes.
The problem was that Audacity did not refill its buffers until the note-off of the last note played. That was (in the James Bond case) 2.9s after the end of the loop. The fix was to not add note off events after mT1 and instead use gAllNotesOff.
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.
