Audacity could be more helpful when paused ...

[waxcylinder]

Yet another user who got confused when stuff doesn't work when in Pause mode - see: http://forum.audacityteam.org/viewtopic ... 46&t=72554

This has happened many, many times before - I have to confess to getting caught out by this myself occasionally ...

I always think that it would be a bit more useful if Audacity actually told the user why a particular tool is unavailable rather than just graying it out when the project is in Pause mode rather than Stop.

I do realize that this is technically not a "bug" as it was "designed that way" by whoever the developer was - but if we get to log it as a bug there is a better chance that a developer may pick this up and run with it than if I just wrote another proposal for it (it seems such a small thing anyway - one that does not warrant a proposal.

Thoughts?

Peter.

[steve]

I always think that it would be a bit more useful if Audacity actually told the user why a particular tool is unavailable

How would it do that?

The tools are greyed out because they are not available for use.
Greying out provides an instant visual indication if a particular function is available or not,
If a function is greyed out, then there is no "on click" action, so where is the opportunity to notify the user?

[waxcylinder]

Greying out provides an instant visual indication if a particular function is available or not ...

But it's quite clear that user's either do not "see" the graying out - or they do not understand the import of that visual cue

... If a function is greyed out, then there is no "on click" action, so where is the opportunity to notify the user?

But Audacity still "knows" where the user is trying to click - and thus could generate an error message or warning in those circumstances.

It certainly wouldn't hurt to do it - nor would it create a regression.

And it would *never* impinge on power users as they *always" know what they are doing ...

Peter.

[billw58]

Greying out provides an instant visual indication if a particular function is available or not ...

But it's quite clear that user's either do not "see" the graying out - or they do not understand the import of that visual cue

... If a function is greyed out, then there is no "on click" action, so where is the opportunity to notify the user?

But Audacity still "knows" where the user is trying to click - and thus could generate an error message or warning in those circumstances.

Actually, Audacity doesn't know. If I read Steve's comment correctly, Audacity does not receive any notification that the user has clicked on a disabled control.

-- Bill

[steve]

If I read Steve's comment correctly, Audacity does not receive any notification that the user has clicked on a disabled control.

I don't know for sure, but I think that is the case.
If the software can detect a click on a greyed out control then I would support giving a message in this case, but I don't think that clicks on greyed out controls are detected (they are disabled).

WxMenus have two states: Enabled and Disabled. The state is set with a boolean wxWidgets function:
.Enable(true/false)
Menus can also be hidden, and can be enabled/disabled by the state of specified "flags".

It looks to me like it would be necessary to use a custom (non-standard) wxMenu that has an additional state of "grey but not disabled" that is able to trigger a different behaviour (the error message) when in this start. Probably quite hard to do and open to cross-platform problems and ongoing maintenance difficulties. It's generally better to allow wxWidgets to do the heavy lifting on cross-platform issues. Features where we have not done that have often been a lot of trouble (such as use of a comma as the decimal separator in Nyquist effects).

[waxcylinder]

[Gale Andrews]

Moved to "Adding Features" - it's not a bug.

It could be a candidate for a bugzilla enhancement, but I think developer input would be needed on the -quality list. It may be hard to get such input, so I am counting votes for "Full editing (including effects) while paused" to demonstrate that it's an issue. It already has 28 votes on Wiki Feature Requests. When a user gets caught by this, let's add a vote (I made a note to add one more for the post Peter pointed to).

When we had no "select all if none" and thus had problems with users not selecting any track then finding the effects greyed out, a warning when clicking the grayed out effect menu was discussed. Look on -devel if you want to. I think it's possible but I would much rather go another route as below.

What do the big boy DAW's do here? I don't have any of those, but CoolEdit seems to let you Pause, delete from behind the pause point, then pressing Pause again resumes from where you paused. You can even delete over the area where the paused cursor is (say at 3 seconds), delete a second either side of the cursor, then pressing Pause again restarts from 3 seconds into the shorter audio. This seems optimal behaviour to me.

Goldawave and Wavosaur seem to treat Pause, then cut a selection as invoking Stop, then performing the cut. You can delete where the cursor was and the cursor becomes the left edge of the audio that was cut (as in Audacity when stopped). Unlike Audacity and Goldwave, Pause in Wavosaur plays from the cursor even when audio is stopped, so to a user who had paused then cut a region over the cursor, this probably seems intuitive.

I don't see why Audacity should not be able to do better here. If we really cannot edit when audio is paused, then why cannot Pause then delete a selection stop the stream but keep it armed at the pause point (so faking a Pause)?

Note there is a bug (I have never had time to put it on Bugzilla) that if you Play, Pause then drag a selection, the Cut, Copy, Trim and Silence buttons in Edit Toolbar (but not the corresponding Edit Menu items) become wrongly enabled, leading users to think they can actually perform those actions. Maybe Steve can do a patch sometime?

We need Stop and Set Cursor (SHIFT + A) in the Transport Menu so a reasonable alternative to edit while paused is discoverable.

For those who Pause, realise their mistake then SHIFT + A, we should try to make SHIFT + A actually set the cursor at the Pause point, not set down farther along the track.


Gale

[kozikowski]

It might be useful if Pause didn't look just like most people are expecting Stop to look.

"Of course the cursor froze in the middle of the song. That's what "Stop" does, isn't it?

Pause is really Stop.
Stop is really Reset the Cursor, or Stop + Home.

It would be like you stopped a reel-to-reel machine and it insisted on rolling back to the top of the tape every time.

That made me crazy until I got used to it.

Koz

[steve]

I don't see why Audacity should not be able to do better here. If we really cannot edit when audio is paused, then why cannot Pause then delete a selection stop the stream but keep it armed at the pause point (so faking a Pause)?

Something along those lines looks possible.
The problem with applying actions while paused seems to be a conflict with the current playback stream, so the playback stream would have to be stopped. Rather than "faking a pause", the most simple solution would be for effects and edit functions to test for AudioIONotBusyFlag and if set, to just stop playback before applying the action. The resting place of the cursor after applying the edit/effect would be the start of the selection that was used for the edit/effect (which seems reasonable to me).

This method also appears to work for applying an edit or effect during playback / record, but perhaps we would want to disable edit/effects in these cases. I don't know how the state of the Pause button can be read but I presume that it is possible to do so.

The current behaviour (disallow edit/effects during play/record/pause) makes a lot of other safety checks unnecessary, but if we were to not grey out edit/effects when paused then there could be unexpected and unwanted consequences, so a change to this behaviour would require a lot of rigorous testing before it could be released.

[Gale Andrews]

I don't see why Audacity should not be able to do better here. If we really cannot edit when audio is paused, then why cannot Pause then delete a selection stop the stream but keep it armed at the pause point (so faking a Pause)?

Something along those lines looks possible.
The problem with applying actions while paused seems to be a conflict with the current playback stream, so the playback stream would have to be stopped. Rather than "faking a pause", the most simple solution would be for effects and edit functions to test for AudioIONotBusyFlag and if set, to just stop playback before applying the action. The resting place of the cursor after applying the edit/effect would be the start of the selection that was used for the edit/effect (which seems reasonable to me).

It's not unreasonable, especially if you were deleting the selection, but it's not what is implied by a Pause button. Clearly people who pause and select some audio they had just heard with the intention of deleting it or applying an effect to it are not intending to play from the cursor or start of the selection, but from the paused playback position.

This method also appears to work for applying an edit or effect during playback / record, but perhaps we would want to disable edit/effects in these cases.

Definitely this should be disabled during recording. I think it is reasonable to drag a selection during playback, then pressing DELETE stops playback and deletes the selection. or pressing a shortcut for an effect stops playback and applies the effect.

CoolEdit lets you delete during playback. It even lets you select all, play, delete, then carries on playing audio for a few seconds (presumably from a buffer) then plays silence until the end of the "track". That isn't very useful, though I can understand people wanting to delete audio that had already been played while still continuing to play.


Gale