More generally, other keystroke shortcuts are processed while dragging on Mac.  For instance left arrow to collapse the selection (though that is undone at button up), or command+B to make a label.

I believe the change in behavior was a consequence of the change to wxWidgets 3.

I also believe it's a bug in wxWidgets 3 that Mac behaves unlike the others.  Because the documentation says here http://docs.wxwidgets.org/3.0/classwx_key_event.html about EVT_CHAR_HOOK (the event we use for dispatching our keystroke shortcuts):

"Finally notice that this event is not generated when the mouse is captured as it is considered that the window which has the capture should receive all the keyboard events too without allowing its parent wxTopLevelWindow to interfere with their processing. "

Captured, i.e. dragging.

It seems wxw3 on Windows and Linux really implements this description but on Mac does not.

I just tried on 2.1.1 on Windows:  drag a clip with time-shift, and as you do, hit r to record, then space to stop.  Note that dragging was frozen during recording but unfreezes after.  Notice the odd behavior of undo after this:  there is an Undo of time shift, but then an Undo of recording that includes some time shift.  The change in 2.1.2 prevents this anomaly on Windows.

Maybe the new behavior is safer as it eliminates this bug and perhaps worse ones I have not discovered.

The Shift+C key closes the focused track.

I have found several ways to crash on Mac by pressing that key during dragging:

Drag a selection.
Drag in the vertical ruler.
Resize a mono track.
Resize a stereo track.
Drag the separator between stereo channels.
Press the track menu button and hit shift+C before releasing the mouse.

I have a remedy for these, and for the Undo oddities metioned in the previous comment.  These remedies will be a necessary part of a fix for this bug, but not sufficient to close it.

It could be argued that until you have released the left mouse button that you have not actually made the selection - rather you are still making the selection.

Ergo one could argue that it is incorrect to allow behavior like playing and labelling on a selection which is not yet complete.

I am of this mind and although this was possible in earlier releases I think that was fundamentally incorrect behavior and prefer the current behavior.

(In reply to Peter Sampson from comment #3)
In a text editor you can't usually act on the selection, such as delete it, before mouse up. However Wavosaur - the only audio editor I tried so far - lets you play or delete a selection while mouse is down. 

Play is the issue that is complained about. This is not unreasonable IMO, given playback of a selection or playback region does not update if the selection or playback region is modified during play. But I agree it is more comfortable not to delete a selection before mouse up.

So is it possible or reasonable to allow transport shortcuts while selection-dragging as the only exception on Windows and Linux to shortcuts being disregarded until mouse up?  My suggestion therefore includes Pause and Record/Append-Record but excludes dragging playback regions which are only meant to play on mouse up. That would imply that we allow Mac to (mostly) behave differently to the other platforms, presumably due to the wx bug, but would allow Mac to come back into line if that wx bug was ever fixed.                 

Thanks to Paul for making safe the crashes on Mac.

(In reply to Gale Andrews from comment #4)
The audio editor "Sweep" does not respond to SPACE (to start play) until the selection is complete (mouse button up).

Ardour 3.5 starts playback on space while the mouse button is down, then restarts playback when the mouse button is released. If the mouse button is not released, then playback stops when it reaches what was the end of the selection when SPACE was pressed. If the mouse button is released during play, then play restarts from the start of the selection and plays to the end of the selection (where the mouse button was released).

Having tested the old Audacity behaviour, a problem that I notice is that when working quickly, it's possible to start playback before having completed making the selection - playback then does not play the selection. Unless you're paying attention to the "play region" arrows, the behaviour looks wrong. The behaviour in Audacity 2.1.2 seems more "positive" in that selecting must be complete before playback, thus avoiding the possibility of "misfiring".

I realise that a few users have stated a preference for the old behaviour. Users hardly ever tell us about changes that they like, but I prefer the new behaviour (and the new behaviour is "correct" for WxWidgets and avoids ugly hacks).

I agree with Paul's comment 1 (and the WxWidgets documentation) that the behaviour on Windows and Linux is what the code should do. "If it ain't broke..."

I have looked at a lot of software in the last couple of days, both audio and
non-audio and the vast majority of those require you to complete a selection
by lifting the left mouse button before you can act on that selection.  

All of the follwing require the selection to be completed by lifting the left mouse button before playing or processing can commence:
1) Garage Band
2) iTunes (this "seeks" when you clicj & drag)
3) YouTube (suspends ongoing playback and does a video farm seek)
4) Reaper
5) Windows Media Player
6) Soundforge
7) Sweep

And of course all the major Microsoft Offive products: Word, Excel and Powerpoint.


And this why I strongly believe that the behaviour that we have now on Windows and Linux (as corrected for us via wx3 widgets) is the correct behavior and not a "regression".  So what Gale is asking for (play to start on presing space while left mouse button is still held down)should properly be classed as a P4 enhancement.  

The real bug part of 1331 is that the Mac behavior is not consistent with the
proper behaviour in Windows and Linux as Paul and Steve have observed earlier in this thread.  And I believe we should be looking to fix that if Wx3 widgets can't fix it for us.

(In reply to Peter Sampson from comment #6)
Yet again "I" am not asking for anything, personally. I am recognising that users with highly repetitive adjust-and-play workflows find it difficult to avoid starting an unwanted new selection using Quick-Play (or just won't change from what they are used to) and are refusing to upgrade Audacity as it currently is.    

I modified the bug to an Enh given Paul's researches, and created bug 1454 (currently P4, believed crash-free) for Mac being out of step in allowing shortcut use with mouse down. Changing bug 1331 to Enh is IMO only a theoretical distinction, not a practical one.  

I also improved the release note to help the complainants use Quick-Play more easily and gave a spin on the reason for this change. I doubt it will help much.  

Ardour's behaviour reported by Steve is interesting. Wavepad doesn't allow SPACE with mouse down, but if you press SPACE with mouse down, the selection plays on mouse up. If you drag the selection during play, the adjusted selection plays on mouse up.

ExpStudio has another variant. It allows the Play shortcut (F2) to start playback and Stop (F7) to stop while the mouse is down, but does not allow the selection to be further modified while mouse is down. If you drag while playing, then either leave mouse down or release it, the modified selection is drawn on stopping playback.  

ExpStudio seems a little odd, but all the applications above seem more friendly than Audacity now is for the identified use case, especially if you prefer modifying the selection directly in the waveform. That disparity is the reason for this enh, irrespective of the solution we come up with.

For 2.1.3 I am going to treat this as a pure enhancement request, and bug 1451 as the actual bug.  In other words RM, will let this Bug 1331 through.  

Longer term I think it highly desirable to try to not lock out actions when other actions are in progress, unless they are logically incompatible.  E.g I'd like to be able to edit audio ahead of the play cursor without pausing play.  This needs quite deep changes in Audacity.  Best if several such changes are done and planned together as a future feature subset.  This item on its own looks too costly in developer time relative to the benefit of the item on its own for where we are with 2.1.3.

(In reply to James Crook from comment #8)
> For 2.1.3 I am going to treat this as a pure enhancement request
Seems logical, given I reset it as Enh. But all we are saying by Enh is that it's not a pure Audacity coding error. 

If the number of strong complaints falls away, then it might be demoted, as with any issue.

I assume James meant that Bug 1454 is the actual bug.

Added Enh: to title.

I have seen three complaints about SPACE with mouse down since my last comment, so I still feel it is right that we have this Enh open. 

Here is a recent post, also mentioning that shortcut Zoom and Silence Audio with mouse down were being used in previous Audacity http://forum.audacityteam.org/viewtopic.php?f=50&t=92968.

(In reply to Gale Andrews from comment #11)
In perspective, three complaints out of millions of downloads over an 8 month period is not really a public outcry. I can't imagine the Ford Motor Company changing their colour scheme because of three complaints (though they do offer more colours than black ;-)

Cannot use Shift+Space either, but to my knowledge no-one has complained about that.

I'm still inclined to think that this should be logged on the wiki as a feature request rather than on the Audacity bug tracker.

(In reply to Steve Daulton from comment #13)
I'm aware of your opinion, but still don't agree with it. IMO we need to be track that this subset of users won't use current Audacity/will go back to old versions until something is provided that is close enough to what they are used to. Examples have already been discussed. 

Yes there are some other things you can't do with mouse down, and also some obscure cases where shortcuts with mouse down still work.

(In reply to Gale Andrews from comment #14)
>I'm aware of your opinion, but still don't agree with it. 
>IMO we need to be track that this subset of users won't use current 
>Audacity/will go back to old versions until something is provided that 
>is close enough to what they are used to.

And I'm aware of your opinion too Gale - and still don't agree with it.

My research documented earlier in this thread indicates that many other apps require the selection to be fully made before an action can take place on it - so I am convinced that we now have appropriate and correct behavior.

From Comment #4
>Play is the issue that is complained about.

We have a useful usable workaround for this and that is to use Timeline QuickPlay.   This is fundamentally designed to quickly play audio, plus 
while it is playing you can extend or contract the Timeline region to be 
quick-played.

===============================================

This is not really a "regression" technically as we have not 
stopped something working, just slightly changed the way it works.


A classic example comes recently from Apple with iTunes.  
For years you could invoke the command to create a compressed version 
of an audio file by right-clicking on the "song" and a dropdown
menu appeared with the conversion command.  

Recently they removed that command from that right-click menu and the user 
has to remember to use File>Convert (also in the process forcing me to 
update the Audacity Manual 

iTunes users (including me) don't complain about "regression" - nor does 
it stop them using iTunes, rather thay just get on with the new way of 
doing things.  Nor does it seem to make them revert to older iTunes versions.

(In reply to Gale Andrews from comment #14)
> Yes there are some other things you can't do with mouse down,

That's what I'm asking clarification about - is this bug / enhancement about restoring the Wx2.8 behaviour, or is it limited to the specific feature as demanded by (a few) users? In other words, is this logged here on bugzilla because the current behaviour is considered "wrong", (which would imply that any other behavioural changes in Audacity due to this change in WxWidgets are also wrong), or are we only concerned with the specific issue of "Play on spacebar while mouse button down"?

I wouldn't want to waste time reintroducing the specific feature request and then be told that it does not fix other cases.

We normally treat "bugs" as the whole issue and "feature requests" as a specific feature - which is this?

(In reply to Peter Sampson from comment #15)
My research shows some audio applications do allow the mouse to be down while using SPACE.  So some do, some don't. I don't think comparisons of text selection with audio selection are entirely relevant. 

As you will have seen from the Forum, so far we convinced none of the complainants that Quick-Play is an adequate replacement. If slowly and carefully used I think it is a reasonable replacement, but slow and careful doesn't cut it for doing the same action over and over repeatedly. 

I suspect a more fluid way of playing and selecting in the waveform would be better for these people, allowing them to use more of their long-practised muscle memory.     

Do we want to use the comments trail to rehash the same for and against arguments?

(In reply to Steve Daulton from comment #16)
> That's what I'm asking clarification about - is this bug / enhancement about restoring 
> the Wx2.8 behaviour, or is it limited to the specific feature as demanded by (a few) 
> users?
I've given my take about it on the -quality list:
http://audacity.238276.n2.nabble.com/Why-enh-bug-1331-is-there-and-what-to-do-about-it-td7577879.html .

Steve mentions that "with WxWidgets 3.0, we can add the ability to start playback while
making a selection is in progress, by calling OnPlayStop when the spacebar is pressed". So presumably this offers a safe route to go down, if we want to. 

Gale thinks that allowing existing playback to update when the selection is updated would help the complainants to some extent, even if we didn't allow playback to start while mouse is down. If that is very long term then I see no strong reason against starting playback with SPACE while selection is in progress. Other use cases to use shortcuts with mouse down seem less strong and less asked for.

I have seen no Forum complaints about this for a long time now - I can't recall any in the lifetime of 2.1.3 - so yesterday I re-downgraded this to P4 (Unh)