... doing that only for the user-visible string, seen in the Manage>About menu
of the effect dialog and in the sorted or grouped Effect/Generate/Analyze
menus.
But don't for the string used internally and written into pluginregistry.cfg,
so that compatibility of that file is preserved.
See also commits cafbff9ff82520ff7d4344570385752869c6d230 and
c6bbe4c3dae8a52bb4b7a3c720af97bc3bd69769
... The part that checks the previously unused statusFlags argument of
audacityAudioCallback can make zero-length labels. I did provoke this into
happening repeatably on macOS using a debug build, zero buffer length in device
preferences, and a busy CPU running other programs, within just two minutes of
recording.
But close zooming in on the label, and listening, revealed nothing obviously
wrong, no click in the playback. So I consider that a false positive.
But the part of the drop-out detection that would make nonzero length
labels, because the other AudioThread is lagging in its writes to disk --
this part remains. Yet I have not yet provoked this into happening.
1) When the program detects this, insert zeroes into the recording to keep the
other good parts synchronized.
2) When recording stops, a message box alerts the user, and a label track is
added showing the lost parts, labelled with consecutive numbers.
3) A menu item visible in alpha builds only is added to Tools, to simulate
recording errors at random times and test the reporting feature.
... If you record or append-record, and do things during it that affect
the undo stack, and then complete recording -- then the last undo item will
undo the recording completely, and the other changes will belong to earlier
undo items that contain no part of the new recording.
Things that affect the undo stack during recording can include new undo items
such as movement of pan and gain sliders or adding and editing of labels
with Ctrl+M or Command+.
But such things also include certain changes of view that do not create new
undo items but rather update the most recent undo item to include that change.
Examples are change of mute or solo, resizing of tracks, changes of selection,
zooming (horizontally or vertically), switch among wave track view types, etc.
Fixing this was a rather involved project. This ought to be tested
thoroughly to be sure there are no other odd surprises in the behavior of
undo.
... 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).
... But perhaps we are developing the means to relax even this ban safely.
For instance, why not undo a mistaken AddLabelPlaying command (Ctrl+M) without
stopping the recording?
... Being careful not to use operator == on a default-constructed
std::list::iterator, which violates assertions in the MSVC libraries.
This reverts commit 7fb5ec4b7ab4f9302bd94446db86924cd2b8d67f.
... and require qualified name access to use the underlying std::list iterators
that return shared_ptr to Track.
Which should not be done very much outside of class TrackList, but a few
places need it.
- Added new facility whereby parameters can be optional, and can be
tested for their presence.
- Can now set Pan, Gain, Selected, Solo, Mute, Focused using SetTrackInfo,
mirroring what GetTrackInfo can do.
