Re: [Audacity-quality] Fixing the interaction of Undo/Redo and Recording

[Peter S. <pet...@gm...>]

I observe (on macOS High Sierra 10.13.2 with
*audacity-macos-nightly-2.2.2-4ef8da8.dmg
*
<https://www.fosshub.com/Audacity-Mac-Nightlies.html/audacity-macos-nightly-2.2.2-4ef8da8.dmg>
-
26.27 MB | version: 2.2.2--15Jan18)
That behavior has improved (I get no crash now) but it is still not perfect.

With 2.2.1 using Paul's steps in this thread
1) after several undos as per the last step I get a crash
2) using the Discard in the History while recording is active I get a crash
3) using the Discard in the History after recording makes no discards at all


With 2.2.2
1) Undos work, but the recorded audio is removed a bit at a time in between
the undoing of labels pan/gain.  With final Undo I am still left with  the
segment
of audio recorded before the first label was dropped.
In the user's mind surely the completion of the recording (the whole
recording)
with these steps should logically be the last thing on the stack - and thus
the user
could realistically expect the first Undo to delete the recorded audio.

In fact if all I do is Record and then Stop
a) with the History>Discard the audio is not removed
b) however Undo does remove the audio (but not if you've used
History>Discard first)

The big improvement is that there is no crash


2) The Discard in the History is grayed out and inoperable while recording
is active
so one cannot get a crash a big improvement.

This also makes for good consistency with the Edit>Undo (in both 2.2.2 1nd
2.2.1)
as these are grayed out and inoperable while the recording is active.


3) using the Discard in the History after recording makes no discards at all
just the same as in 2.2.1  -  this is not expected behavior, I would be
expecting
undo to work it's way through the history stack undoing as it goes.
It does empty the items in the History window it just doesn't action the
Undos.

---------------------------------------------------------------------------------------------

This has for me raised a number of fundamental architectural  design
questions:

A) Why do we allow the user to adjust the Pan and gain sliders in a track
that they
are recording into?   They have no impact on the ongoing recording, only
impacting
the track when it is played later.

B) There is a small argument for allowing the gain and pan sliders in
tracks other than
the one in which the ongoing recording is taking place to be usable while
recording
as the user may be overdubbing.  But I will still argue for disabling all
pan/gain
sliders while recording is taking place.

C) The arguments for A and B above also apply to the Mute and Solo buttons
which I
note are operable while the recording is taking place - once again these
have no
impact on the recorded track while recording, only on playback.
Accordingly I argue for the disabling of these buttons.

D) We do already inhibit certain actions while recording
i) access to the Device Toolbar (grayed-out)
ii) access to the edit buttons in the Edit Toolbar (grayed-out)
iii) the Play button (grayed-out) in the Transport Toolbar
iv) many/most menu commands (grayed-out)
So I can see no real reason for not adding to that list.


Things that we do allow and that are useful are:

E) Zooms

F) Labelling (useful but can be risky for the unwary - don't ask me how I
know)

G) Mixer Toolbar

We should continue to allow these.

H) In the Tools Toolbar you can switch tools but all except the selection
tool
are inhibited from use with a no-entry white icon on the waveform
Access to the Selection tool (and selection) can be useful while recording.


We should also bear in mind that doing anything else while recording,
particularly
on older lower-powered engines has the potential to interrupt the recording
and
cause dropouts (unrecoverable) - so minimizing the "stuff" that a user can
do while
recording is almost certainly beneficial.

It's advice we often give out on the Forum:  "Don't do other stuff on your
computer
while you are recording, especially critical unrepeatable recordings ..."


--------------------------------------------------------------------------------------------------

Looking at this has reminded me of some earlier discussions of some months
back
when we were discussing the History stack and its inadequacies.

I suspect that we may have a deeper architectural problem to consider with
this
at some stage - but not right now, I'm thinking.

Peter.


On Mon, Jan 15, 2018 at 1:07 AM, Paul Licameli <pau...@gm...>
wrote:

> I lately filed, and submitted fixes for, two bugs involving the
> interaction of recording and undo.  The first is a crash, and the second is
> just some stupid program behavior that has bothered me for a while, and
> needed a nontrivial fix.
>
> I'd like others to give this some exercise, especially regarding the
> latter one.  Compare it with 2.2.1 (and earlier) behavior, and verify that
> it's better now.
>
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1822
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1823
>
> Quoting the Steps to Reproduce from 1823:
>
> "New project.
> (Open the history window, this may help.)
> Start recording.
> During recording, do one or more things such as:  Adding a label with
> Ctrl+M (Command+.); moving a pan or gain slider; resizing a track; changing
> selection; changing view type.
> Stop recording.
> Undo several times.
>
> Observe that the first undo does not remove all of the recording.
> Instead, the recording may be removed in stages, parts of it belonging to
> other undo items on the stack.
>
> Some of the recording might become part of the "Created new project" undo
> item at the start of the history, which is never undone.  Thus it becomes
> impossible to undo the project back to its original empty state."
>
> PRL
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>