Why enh bug 1331 is there and what to do about it

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Why enh bug 1331 is there and what to do about it

Gale
Administrator
Steve asked about bug 1331:
( http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c16 )

> 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'd like to give my thoughts about how it might be "fixed" so rather
than do that in the comment trail I'll do so here.

SPACE with mouse button down not working is what has generated the
most complaints (if we are calculating, I think it sums to about ~11
users so far, not just the "three more" in
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c11 .

I've also seen two complaints about DEL with mouse button down not
working any longer, as well as about Silence Audio and Zoom.  As those
complaints have been fewer and much less insistent, and I am guessing
globally re-enabling shortcuts with mouse down is unsafe or infeasible
(see near the end of this message), I was not intending to track those
other complaints formally for now.

They could be so tracked though - perhaps as a summary of less
requested restorations of shortcuts with mouse down.

This specific enh (bug 1331) is listed because the users see
disallowing SPACE with mouse down as "wrong" (it's a "bug" to them).
This enh is specific to that problem, but the complaint does not
necessarily predict the fix. This enh means for us that:

* there is a considerable risk of affected users not updating Audacity
* if the original behaviour is not reinstated, we should consider how
we could make things easier for these people when enhancing playback
features.

One fix would be to disallow SPACE with mouse down, but if mouse is
down, play on mouse up.

Examples of apps with arguably more friendly waveform playback
behaviour than we have now were given here:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c5
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c7 .

I notice we still allow shortcuts to be used after a fashion with
mouse down in Envelope Tool. It is more restrictive (some might say
weird) and presumably safer than in 2.1.1. In HEAD with the mouse
down, use the desired shortcut (or any other). This releases the mouse
(even if you are still holding it down). Then use the desired
shortcut.

So, can we do something like that when in Selection Tool? For example,
when mouse is down, make SPACE release the mouse and then play the
track. While playing, moving the mouse would only move the pointer,
not drag the selection, even if mouse button was still down. When you
press SPACE again to Stop, this re-engages the mouse (but this assumes
we don't have to deliver a left-click which would destroy the
selection). If the mouse had moved while playing, let the selection be
redrawn according to the new pointer position.

Yes, the more obvious fix would be to treat this as a request to
restore use of SPACE with mouse down.  Obviously the users would like
that, but I think we should only oblige if it is safe to do so.


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

Is there some kind of global "switch" to re-enable shortcuts with
mouse down? Even if there was, given what Paul found, might such a
"global" change be potentially dangerous?  Should we not take it case
by case to see if other relaxations such as DEL with mouse down are
safe?


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

As it was decided this was enh, not bug, it's the specific feature (or
a means of implementing something comparable in the waveform that
could still satisfy the complainants).


Gale

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Peter Sampson-2
Personally, I am at best neutral on techical grounds whether we restore
the behaviour that enables Play to take place while the user is still in the
process of making a selection.

I would be strongly against extending that to allow the use of other shortcuts
while the selection is still in progress with the left mouse button down.
I can see a possible case for allowing zooms - but nothing else really and
certainly not any Delete shortcut (which has also been compained about.
albeit by a mere two people).

But let's look at the ROI here. 
Over the year that we have had 2.1.2 out now Gale has counted 11 "complaints"
about the removal of that behaviour.   That makes say 12 votes for this (if you
include Gale). 

Now look at our Feature Requests page in the Wiki:
http://wiki.audacityteam.org/wiki/Feature_Requests
12 votes would clearly not merit a place in the important "Higest Rated" section.
And in that section there are many much higher-scoring FRs that warrant the
attention of a developer ahead of this.

So my belief is that to spend developer time on thiscomparively minor UI change
for just 12 people would be a very poor ROI in comparson with those Highest Rated
items.

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

Gale wrote:
>One fix would be to disallow SPACE with mouse down, but if mouse is
>down, play on mouse up.

Indeed - and we already have that functionality:
that is precisely what Timeline QuickPlay does and what it was designed for.

The only difference is that the cursor must be in the Timeline and not over
the waveform. 

When Steve was developing TQP Gale pointed out that he found it hard to
precisely place the play position(s) when using TQP - in response to that
Steve added the very useful (and usable) white lines (yellow if Snap To is
on) over the waveforms to facilitate precision placement.

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

With regard to how other software works and thus what users may be used
to elsewhere, Gale cherry-picks his comments #5 and #7 to support his
argument, carefully ignorning mine sandwiched between them:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c6
in which I researched several apps that did not allow play with mouse down.

Perhaps importantly, given that Windows is our major platform and that many
Mac users also install and use Microsft Office, note that the Office products:
Word, Excel etc. all require that the selection be fully made with the mouse up
before any action on the selection can be invoked and performed.  So this is
the style of behaviour that many of our users would come to expect.

Peter.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Stevethefiddle
In reply to this post by Gale
On 21 January 2017 at 00:11, Gale Andrews <[hidden email]> wrote:

> Steve asked about bug 1331:
> ( http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c16 )
>
>> 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'd like to give my thoughts about how it might be "fixed" so rather
> than do that in the comment trail I'll do so here.

Thanks for moving this to the email list.
I'm interested in not only this specific "enh bug", but also the more
general issue of how to use bugzilla and the wiki feature requests
most effectively.

>
> SPACE with mouse button down not working is what has generated the
> most complaints (if we are calculating, I think it sums to about ~11
> users so far, not just the "three more" in
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c11 .

Whether 3 or 11, it is still a minuscule proportion of users, and
although that is no reason to not do something, we do need to keep a
sense of proportion so as not to over-react to squeaky wheels.

>
> I've also seen two complaints about DEL with mouse button down not
> working any longer, as well as about Silence Audio and Zoom.  As those
> complaints have been fewer and much less insistent, and I am guessing
> globally re-enabling shortcuts with mouse down is unsafe or infeasible
> (see near the end of this message), I was not intending to track those
> other complaints formally for now.
>
> They could be so tracked though - perhaps as a summary of less
> requested restorations of shortcuts with mouse down.
>
> This specific enh (bug 1331) is listed because the users see
> disallowing SPACE with mouse down as "wrong" (it's a "bug" to them).

At least one user has claimed that rendering track envelopes in
"compressed copy of project" is a bug, though clearly it's not.
Many users regularly report the leading padding on MP3 exports is a
bug, which clearly it is not (even if we could handle  it better).
Some users have reported lack of Opus support as a "bug", which
clearly it's not.

There are countless examples of users reporting "bugs", which they see
as "bugs", that are not bugs at all, but surely that is why we have
QA? It's up to us to differentiate between "bug", "feature request",
"user error", and whatever "enh bug" is.

As Peter noted, there are many enhancements listed on the wiki feature
request page that have many more votes than this issue, but, correct
me if I'm wrong, an "enhancement" listed on bugzilla is actively
tracked along with "real bugs", and thereby has greater priority than
enhancements listed on the wiki. What determines whether an
enhancement should get this preferential treatment?

> This enh is specific to that problem, but the complaint does not
> necessarily predict the fix. This enh means for us that:
>
> * there is a considerable risk of affected users not updating Audacity

Risk to whom?
With all software there are early adopters, late adopters, and users
that try out the latest and greatest then go back to a previous
version for a while. In the end it is up to the user to decide what
software best meets their needs. If a later version of an application
has many improvements over old versions and one feature that a user
dislikes, it is up to the user to decide if the many improvements
outweigh the one feature that they don't like.
It's not a "risk" to either the user or to us, it's a decision that
the user is free to make.

Our task is to make Audacity "as good as possible", but we are never
going to satisfy everyone.

In this specific case, 11 users are complaining that they can't start
play until they have completed making a selection. This is only an
issue at all because WxWidgets 2.8 allowed that to happen, but as far
as I'm aware it was not a documented, or even an intended by design
feature of Audacity, but rather just something that happened because
that's what WxWidgets 2.8 did.

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, but then it becomes a "design feature" which has
never existed in Audacity previously.

What happens if we add the proposed feature and 12 new users that have
only ever used Audacity 2.1.2 complain that they don't want play to
start unless they have completed making the selection (don't allow
play until mouse button is up)?

In my opinion, our design decisions should primarily be concerned with
making Audacity as good as we possibly can, and while we should
certainly take account of user feedback, we need to remember that the
user is not always right. Something that is "right" for one user can
easily be "wrong" for thousands of other users.

I am not convinced that the proposed "new feature" (and I call it a
"new feature" because it will need to be a new deliberately designed
feature rather than just "what happens") is better than now. So
although I'm not strongly against the feature (though I do slightly
prefer the current behaviour), I see no reason that it should be
elevated above feature requests that have many more "votes".

Also, as "P3" it would appear to be elevated above hundreds of actual
"bugs", which I don't see to be in the best interest of "making
Audacity as good as we possibly can".

Steve

> * if the original behaviour is not reinstated, we should consider how
> we could make things easier for these people when enhancing playback
> features.
>
> One fix would be to disallow SPACE with mouse down, but if mouse is
> down, play on mouse up.
>
> Examples of apps with arguably more friendly waveform playback
> behaviour than we have now were given here:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c5
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c7 .
>
> I notice we still allow shortcuts to be used after a fashion with
> mouse down in Envelope Tool. It is more restrictive (some might say
> weird) and presumably safer than in 2.1.1. In HEAD with the mouse
> down, use the desired shortcut (or any other). This releases the mouse
> (even if you are still holding it down). Then use the desired
> shortcut.
>
> So, can we do something like that when in Selection Tool? For example,
> when mouse is down, make SPACE release the mouse and then play the
> track. While playing, moving the mouse would only move the pointer,
> not drag the selection, even if mouse button was still down. When you
> press SPACE again to Stop, this re-engages the mouse (but this assumes
> we don't have to deliver a left-click which would destroy the
> selection). If the mouse had moved while playing, let the selection be
> redrawn according to the new pointer position.
>
> Yes, the more obvious fix would be to treat this as a request to
> restore use of SPACE with mouse down.  Obviously the users would like
> that, but I think we should only oblige if it is safe to do so.
>
>
>> I wouldn't want to waste time reintroducing the specific feature request and then
>> be told that it does not fix other cases.
>
> Is there some kind of global "switch" to re-enable shortcuts with
> mouse down? Even if there was, given what Paul found, might such a
> "global" change be potentially dangerous?  Should we not take it case
> by case to see if other relaxations such as DEL with mouse down are
> safe?
>
>
>> We normally treat "bugs" as the whole issue and "feature requests" as a specific
>> feature - which is this?
>
> As it was decided this was enh, not bug, it's the specific feature (or
> a means of implementing something comparable in the waveform that
> could still satisfy the complainants).
>
>
> Gale
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Gale
Administrator
In reply to this post by Peter Sampson-2
This is not a personal thing. I don't use playback with mouse down
myself.

As with feature request "votes", the number of "complaints" about
anything is probably an underestimate. 11 complaints are quite
indicative if they have accumulated in only one year.

Bugzilla is for tracking user impacts. A bug is a user impact. A
feature that no longer works and drives users back to old versions
of Audacity, or works so badly that there are regular complaints,
is a user impact.

A useful benchmark that suggests tracking may be useful is if the
enhs are being reported as "bugs" by the users. Requests for
real-time effect preview (when we did not have it), beat-matching
or multi-channel playback have never been presented by users as
"bugs".

The Forum feedback seems to be clear why Timeline Quick-Play is
not seen by the users as a solution. Mouse release is an extra
action for the right hand that distracts from the task of making the
selection. Once the mouse is up, it's too easy to click outside the
area of the double-headed mouse pointer and thus destroy the
original selection rather than adjust it.

Playing on mouse up when dragging a selection in the waveform has
the same issues, but has the advantage that it would be more familiar
to these users than dragging above the waveform.

Also I think that if playback, once started, adjusted to changes in the
selection, this would make things better for these users (and for a
whole lot of other users too). Once playback started, the complainants
could regrab and drag the selection edge as much as they wanted
with no need to repeatedly release the mouse and drag again.

As I said, we don't IMO absolutely have to fix this enh by reinstating
SPACE with mouse down. Merely recording votes on Feature
Requests that users want SPACE with mouse down does not move
us forward as much as tracking the underlying issue that it was
always fiddly to adjust the selection while playing, and now one
method of doing that has disappeared.

Of course, we can retitle the bug if it helps.


Gale


On 21 January 2017 at 11:22, Peter Sampson
<[hidden email]> wrote:

> Personally, I am at best neutral on techical grounds whether we restore
> the behaviour that enables Play to take place while the user is still in the
> process of making a selection.
>
> I would be strongly against extending that to allow the use of other
> shortcuts
> while the selection is still in progress with the left mouse button down.
> I can see a possible case for allowing zooms - but nothing else really and
> certainly not any Delete shortcut (which has also been compained about.
> albeit by a mere two people).
>
> But let's look at the ROI here.
> Over the year that we have had 2.1.2 out now Gale has counted 11
> "complaints"
> about the removal of that behaviour.   That makes say 12 votes for this (if
> you
> include Gale).
>
> Now look at our Feature Requests page in the Wiki:
> http://wiki.audacityteam.org/wiki/Feature_Requests
> 12 votes would clearly not merit a place in the important "Higest Rated"
> section.
> And in that section there are many much higher-scoring FRs that warrant the
> attention of a developer ahead of this.
>
> So my belief is that to spend developer time on thiscomparively minor UI
> change
> for just 12 people would be a very poor ROI in comparson with those Highest
> Rated
> items.
>
> --------------------------------------------------------------------------------------------------------
>
> Gale wrote:
>>One fix would be to disallow SPACE with mouse down, but if mouse is
>>down, play on mouse up.
>
> Indeed - and we already have that functionality:
> that is precisely what Timeline QuickPlay does and what it was designed for.
>
> The only difference is that the cursor must be in the Timeline and not over
> the waveform.
>
> When Steve was developing TQP Gale pointed out that he found it hard to
> precisely place the play position(s) when using TQP - in response to that
> Steve added the very useful (and usable) white lines (yellow if Snap To is
> on) over the waveforms to facilitate precision placement.
>
> ----------------------------------------------------------------------------------------------------
>
> With regard to how other software works and thus what users may be used
> to elsewhere, Gale cherry-picks his comments #5 and #7 to support his
> argument, carefully ignorning mine sandwiched between them:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c6
> in which I researched several apps that did not allow play with mouse down.
>
> Perhaps importantly, given that Windows is our major platform and that many
> Mac users also install and use Microsft Office, note that the Office
> products:
> Word, Excel etc. all require that the selection be fully made with the mouse
> up
> before any action on the selection can be invoked and performed.  So this is
> the style of behaviour that many of our users would come to expect.
>
> Peter.
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Peter Sampson-2
>The Forum feedback seems to be clear why Timeline Quick-Play is
>not seen by the users as a solution. Mouse release is an extra
>action for the right hand that distracts from the task of making the
>selection. Once the mouse is up, it's too easy to click outside the
>area of the double-headed mouse pointer and thus destroy the
>original selection rather than adjust it.

Aw c'mon Gale I just don't buy that ...

Making a selection and then doing something with it is one of the very
absolute  *basics* of Audacity (and most if not all other GUI apps).

Any Audacity user who is keen not to destroy their carefully made selection will
always give it a temporary range label (I do this all the time - and I'm sure others
do too) - You can't do that with Word or our wiki HTML editor ;-)

Peter

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Gale
Administrator
On 21 January 2017 at 16:22, Peter Sampson
<[hidden email]> wrote:

>>The Forum feedback seems to be clear why Timeline Quick-Play is
>>not seen by the users as a solution. Mouse release is an extra
>>action for the right hand that distracts from the task of making the
>>selection. Once the mouse is up, it's too easy to click outside the
>>area of the double-headed mouse pointer and thus destroy the
>>original selection rather than adjust it.
>
> Aw c'mon Gale I just don't buy that ...
>
> Making a selection and then doing something with it is one of the very
> absolute  *basics* of Audacity (and most if not all other GUI apps).
>
> Any Audacity user who is keen not to destroy their carefully made selection
> will
> always give it a temporary range label (I do this all the time - and I'm
> sure others
> do too) - You can't do that with Word or our wiki HTML editor ;-)

Peter,

I believe I am faithfully reflecting/interpreting what these users have
said, but you can find the topics and draw your own conclusions.
However one of the users PM'ed me about it and he spelt out what
he sees as the problem pretty much as I wrote it above.

Of course it is partly muscle memory but it makes some sense.
One hand does one action, the other hand does the other action.

I don't want to repeat myself, but the issue here is very much how
many times select - adjust - play needs to be done and thus how
fast it needs to done. We might be talking a thousand times a day,
so I am told.

How easy do you find it to drag a selection in Timeline Quick-Play,
release to play, then very rapidly, while looking at the waveform,
click and drag exactly where the double-pointed arrows are?

Remember what the goal is - to adjust the selection edge and
play the adjusted selection.



Gale

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Stevethefiddle
In reply to this post by Gale
On 21 January 2017 at 16:13, Gale Andrews <[hidden email]> wrote:
> This is not a personal thing. I don't use playback with mouse down
> myself.
>
> As with feature request "votes", the number of "complaints" about
> anything is probably an underestimate. 11 complaints are quite
> indicative if they have accumulated in only one year.

11 complaints is indicative of what?
Over the past year there have been thousands of topics started about
all manner of things.

I'd guess there have been many more "complaints" over that period
about not being able to record the right channel of some devices as
mono, but we've not been counting those, so "Allocate specific
channels to specific Audacity tracks:" remains as a "feature request"
on the wiki.

>
> Bugzilla is for tracking user impacts. A bug is a user impact.

A "bug" is something that is broken or does not work as intended.

The inability to record the right channel of some devices as mono, has
obvious "user impact", so shouldn't that be on the "user impact
tracker"?

If, as Bugzilla Tsar, you wish to use Bugzilla for tracking "user
impacts", then I think we also need to have a "bug tracker" for
tracking bugs. I'm quite happy for you to run Bugzilla in whatever way
you wish, but it is increasingly falling short of being useful for my
needs, both as a QA tester and developer.

Steve

> A
> feature that no longer works and drives users back to old versions
> of Audacity, or works so badly that there are regular complaints,
> is a user impact.
>
> A useful benchmark that suggests tracking may be useful is if the
> enhs are being reported as "bugs" by the users. Requests for
> real-time effect preview (when we did not have it), beat-matching
> or multi-channel playback have never been presented by users as
> "bugs".
>
> The Forum feedback seems to be clear why Timeline Quick-Play is
> not seen by the users as a solution. Mouse release is an extra
> action for the right hand that distracts from the task of making the
> selection. Once the mouse is up, it's too easy to click outside the
> area of the double-headed mouse pointer and thus destroy the
> original selection rather than adjust it.
>
> Playing on mouse up when dragging a selection in the waveform has
> the same issues, but has the advantage that it would be more familiar
> to these users than dragging above the waveform.
>
> Also I think that if playback, once started, adjusted to changes in the
> selection, this would make things better for these users (and for a
> whole lot of other users too). Once playback started, the complainants
> could regrab and drag the selection edge as much as they wanted
> with no need to repeatedly release the mouse and drag again.
>
> As I said, we don't IMO absolutely have to fix this enh by reinstating
> SPACE with mouse down. Merely recording votes on Feature
> Requests that users want SPACE with mouse down does not move
> us forward as much as tracking the underlying issue that it was
> always fiddly to adjust the selection while playing, and now one
> method of doing that has disappeared.
>
> Of course, we can retitle the bug if it helps.
>
>
> Gale
>
>
> On 21 January 2017 at 11:22, Peter Sampson
> <[hidden email]> wrote:
>> Personally, I am at best neutral on techical grounds whether we restore
>> the behaviour that enables Play to take place while the user is still in the
>> process of making a selection.
>>
>> I would be strongly against extending that to allow the use of other
>> shortcuts
>> while the selection is still in progress with the left mouse button down.
>> I can see a possible case for allowing zooms - but nothing else really and
>> certainly not any Delete shortcut (which has also been compained about.
>> albeit by a mere two people).
>>
>> But let's look at the ROI here.
>> Over the year that we have had 2.1.2 out now Gale has counted 11
>> "complaints"
>> about the removal of that behaviour.   That makes say 12 votes for this (if
>> you
>> include Gale).
>>
>> Now look at our Feature Requests page in the Wiki:
>> http://wiki.audacityteam.org/wiki/Feature_Requests
>> 12 votes would clearly not merit a place in the important "Higest Rated"
>> section.
>> And in that section there are many much higher-scoring FRs that warrant the
>> attention of a developer ahead of this.
>>
>> So my belief is that to spend developer time on thiscomparively minor UI
>> change
>> for just 12 people would be a very poor ROI in comparson with those Highest
>> Rated
>> items.
>>
>> --------------------------------------------------------------------------------------------------------
>>
>> Gale wrote:
>>>One fix would be to disallow SPACE with mouse down, but if mouse is
>>>down, play on mouse up.
>>
>> Indeed - and we already have that functionality:
>> that is precisely what Timeline QuickPlay does and what it was designed for.
>>
>> The only difference is that the cursor must be in the Timeline and not over
>> the waveform.
>>
>> When Steve was developing TQP Gale pointed out that he found it hard to
>> precisely place the play position(s) when using TQP - in response to that
>> Steve added the very useful (and usable) white lines (yellow if Snap To is
>> on) over the waveforms to facilitate precision placement.
>>
>> ----------------------------------------------------------------------------------------------------
>>
>> With regard to how other software works and thus what users may be used
>> to elsewhere, Gale cherry-picks his comments #5 and #7 to support his
>> argument, carefully ignorning mine sandwiched between them:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c6
>> in which I researched several apps that did not allow play with mouse down.
>>
>> Perhaps importantly, given that Windows is our major platform and that many
>> Mac users also install and use Microsft Office, note that the Office
>> products:
>> Word, Excel etc. all require that the selection be fully made with the mouse
>> up
>> before any action on the selection can be invoked and performed.  So this is
>> the style of behaviour that many of our users would come to expect.
>>
>> Peter.
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Gale
Administrator
In reply to this post by Stevethefiddle
Steve,

I was about to ask if my further reply to Peter explained any more about
why I think we should track this on Bugzilla. It appears not, but I think not
tracking would be an under-reaction. The votes as expressed by the users
don't reflect what the underlying problem is (that it is too hard to adjust
the selection while playing) or the ways in which we could address it.

A few replies inline.


On 21 January 2017 at 15:53, Steve the Fiddle <[hidden email]> wrote:

> On 21 January 2017 at 00:11, Gale Andrews <[hidden email]> wrote:
>> Steve asked about bug 1331:
>> ( http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c16 )
>>
>>> 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'd like to give my thoughts about how it might be "fixed" so rather
>> than do that in the comment trail I'll do so here.
>
> Thanks for moving this to the email list.
> I'm interested in not only this specific "enh bug", but also the more
> general issue of how to use bugzilla and the wiki feature requests
> most effectively.
>
>>
>> SPACE with mouse button down not working is what has generated the
>> most complaints (if we are calculating, I think it sums to about ~11
>> users so far, not just the "three more" in
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c11 .
>
> Whether 3 or 11, it is still a minuscule proportion of users, and
> although that is no reason to not do something, we do need to keep a
> sense of proportion so as not to over-react to squeaky wheels.
>
>>
>> I've also seen two complaints about DEL with mouse button down not
>> working any longer, as well as about Silence Audio and Zoom.  As those
>> complaints have been fewer and much less insistent, and I am guessing
>> globally re-enabling shortcuts with mouse down is unsafe or infeasible
>> (see near the end of this message), I was not intending to track those
>> other complaints formally for now.
>>
>> They could be so tracked though - perhaps as a summary of less
>> requested restorations of shortcuts with mouse down.
>>
>> This specific enh (bug 1331) is listed because the users see
>> disallowing SPACE with mouse down as "wrong" (it's a "bug" to them).
>
> At least one user has claimed that rendering track envelopes in
> "compressed copy of project" is a bug, though clearly it's not.
> Many users regularly report the leading padding on MP3 exports is a
> bug, which clearly it is not (even if we could handle  it better).
> Some users have reported lack of Opus support as a "bug", which
> clearly it's not.
>
> There are countless examples of users reporting "bugs", which they see
> as "bugs", that are not bugs at all, but surely that is why we have
> QA? It's up to us to differentiate between "bug", "feature request",
> "user error", and whatever "enh bug" is.

And that is what we are doing in this case. I am not talking about
"user error" bugs when I refer to enhancements that the users
are calling bugs.


> As Peter noted, there are many enhancements listed on the wiki feature
> request page that have many more votes than this issue, but, correct
> me if I'm wrong, an "enhancement" listed on bugzilla is actively
> tracked along with "real bugs"

Yes, that is the point because Feature Requests is not set up well
enough to be a tracking system.


> and thereby has greater priority than enhancements listed on the wiki.

Yes, broadly speaking.


> What determines whether an enhancement should get this preferential
> treatment?

Mine that are above P4 are generated if I see regular "complaints" from
users, especially if I know users are going back to previous Audacity
versions as a result.

What determines whether you (Steve) raise an Enh rather than put it on
Wiki Feature Requests?


>> This enh is specific to that problem, but the complaint does not
>> necessarily predict the fix. This enh means for us that:
>>
>> * there is a considerable risk of affected users not updating Audacity
>
> Risk to whom?
> With all software there are early adopters, late adopters, and users
> that try out the latest and greatest then go back to a previous
> version for a while. In the end it is up to the user to decide what
> software best meets their needs. If a later version of an application
> has many improvements over old versions and one feature that a user
> dislikes, it is up to the user to decide if the many improvements
> outweigh the one feature that they don't like.
> It's not a "risk" to either the user or to us, it's a decision that
> the user is free to make.

Well if we don't care, so be it. To me a "feature request" of
"something that no longer works" that drives users back to old
versions is something we should know about. It is harder to know
about it, if it is only on Feature Requests.


> Our task is to make Audacity "as good as possible", but we are never
> going to satisfy everyone.
>
> In this specific case, 11 users are complaining that they can't start
> play until they have completed making a selection. This is only an
> issue at all because WxWidgets 2.8 allowed that to happen, but as far
> as I'm aware it was not a documented, or even an intended by design
> feature of Audacity, but rather just something that happened because
> that's what WxWidgets 2.8 did.
>
> 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, but then it becomes a "design feature" which has
> never existed in Audacity previously.
>
> What happens if we add the proposed feature and 12 new users that have
> only ever used Audacity 2.1.2 complain that they don't want play to
> start unless they have completed making the selection (don't allow
> play until mouse button is up)?

I am fine with not adding that proposed feature if we apply some other
solution instead, but for all the years that we allowed SPACE with
mouse down, did anyone ever complain about it (apart from Peter,
just now)?


> In my opinion, our design decisions should primarily be concerned with
> making Audacity as good as we possibly can, and while we should
> certainly take account of user feedback, we need to remember that the
> user is not always right. Something that is "right" for one user can
> easily be "wrong" for thousands of other users.
>
> I am not convinced that the proposed "new feature" (and I call it a
> "new feature" because it will need to be a new deliberately designed
> feature rather than just "what happens") is better than now.

So don't implement it, if the consensus is not to. Do something that
will help not only the complainants but others too. I suggested
allowing playback to update when the selection is updated.


> although I'm not strongly against the feature (though I do slightly
> prefer the current behaviour), I see no reason that it should be
> elevated above feature requests that have many more "votes".

My reason is that I attach less importance to "wouldn't it be nice"
than I do to "It's now taking way too long to complete my tasks".



> Also, as "P3" it would appear to be elevated above hundreds of actual
> "bugs", which I don't see to be in the best interest of "making
> Audacity as good as we possibly can".

I assume you meant "P2".  Is a P2 Enh more important than a P2 Bug?
I don't think there is a simple answer to that, but the general answer is
probably "no".



Gale


>> * if the original behaviour is not reinstated, we should consider how
>> we could make things easier for these people when enhancing playback
>> features.
>>
>> One fix would be to disallow SPACE with mouse down, but if mouse is
>> down, play on mouse up.
>>
>> Examples of apps with arguably more friendly waveform playback
>> behaviour than we have now were given here:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c5
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c7 .
>>
>> I notice we still allow shortcuts to be used after a fashion with
>> mouse down in Envelope Tool. It is more restrictive (some might say
>> weird) and presumably safer than in 2.1.1. In HEAD with the mouse
>> down, use the desired shortcut (or any other). This releases the mouse
>> (even if you are still holding it down). Then use the desired
>> shortcut.
>>
>> So, can we do something like that when in Selection Tool? For example,
>> when mouse is down, make SPACE release the mouse and then play the
>> track. While playing, moving the mouse would only move the pointer,
>> not drag the selection, even if mouse button was still down. When you
>> press SPACE again to Stop, this re-engages the mouse (but this assumes
>> we don't have to deliver a left-click which would destroy the
>> selection). If the mouse had moved while playing, let the selection be
>> redrawn according to the new pointer position.
>>
>> Yes, the more obvious fix would be to treat this as a request to
>> restore use of SPACE with mouse down.  Obviously the users would like
>> that, but I think we should only oblige if it is safe to do so.
>>
>>
>>> I wouldn't want to waste time reintroducing the specific feature request and then
>>> be told that it does not fix other cases.
>>
>> Is there some kind of global "switch" to re-enable shortcuts with
>> mouse down? Even if there was, given what Paul found, might such a
>> "global" change be potentially dangerous?  Should we not take it case
>> by case to see if other relaxations such as DEL with mouse down are
>> safe?
>>
>>
>>> We normally treat "bugs" as the whole issue and "feature requests" as a specific
>>> feature - which is this?
>>
>> As it was decided this was enh, not bug, it's the specific feature (or
>> a means of implementing something comparable in the waveform that
>> could still satisfy the complainants).
>>
>>
>> Gale
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Gale
Administrator
In reply to this post by Stevethefiddle
On 21 January 2017 at 17:00, Steve the Fiddle <[hidden email]> wrote:

> On 21 January 2017 at 16:13, Gale Andrews <[hidden email]> wrote:
>> This is not a personal thing. I don't use playback with mouse down
>> myself.
>>
>> As with feature request "votes", the number of "complaints" about
>> anything is probably an underestimate. 11 complaints are quite
>> indicative if they have accumulated in only one year.
>
> 11 complaints is indicative of what?
> Over the past year there have been thousands of topics started about
> all manner of things.

Have we then seen the subject of those topics repeated about once a
month?


> I'd guess there have been many more "complaints" over that period
> about not being able to record the right channel of some devices as
> mono, but we've not been counting those, so "Allocate specific
> channels to specific Audacity tracks:" remains as a "feature request"
> on the wiki.
>
>>
>> Bugzilla is for tracking user impacts. A bug is a user impact.
>
> A "bug" is something that is broken or does not work as intended.
>
> The inability to record the right channel of some devices as mono, has
> obvious "user impact", so shouldn't that be on the "user impact
> tracker"?

I need to be clear what you are asking about. Do you mean when standard
recording in stereo (not append recording), that you have no option but to
record one stereo track?


> If, as Bugzilla Tsar, you wish to use Bugzilla for tracking "user
> impacts", then I think we also need to have a "bug tracker" for
> tracking bugs. I'm quite happy for you to run Bugzilla in whatever way
> you wish, but it is increasingly falling short of being useful for my
> needs, both as a QA tester and developer.

That seems like an overstatement to me, but is the broader issue
rather one of tracking Enh's on Bugzilla or not?

If we allowed no Enh's on Bugzlla, then bug 1331 would not exist.

I don't feel enh's are that much of a distraction. Most are P4 or P5.
Steve authored 12 of the 92 open enh's, out of 31 enh's total he
created.

On a quick scan it looks like most of Steve's enh's are not issues that
attracted a lot of negative user input. If so, their lower rating is justified,
IMO, versus those we have at P3 and P2.

It is easy enough to create your own search result that excludes enh's.

Or they could be a separate "product".


Gale

>> A feature that no longer works and drives users back to old versions
>> of Audacity, or works so badly that there are regular complaints,
>> is a user impact.
>>
>> A useful benchmark that suggests tracking may be useful is if the
>> enhs are being reported as "bugs" by the users. Requests for
>> real-time effect preview (when we did not have it), beat-matching
>> or multi-channel playback have never been presented by users as
>> "bugs".
>>
>> The Forum feedback seems to be clear why Timeline Quick-Play is
>> not seen by the users as a solution. Mouse release is an extra
>> action for the right hand that distracts from the task of making the
>> selection. Once the mouse is up, it's too easy to click outside the
>> area of the double-headed mouse pointer and thus destroy the
>> original selection rather than adjust it.
>>
>> Playing on mouse up when dragging a selection in the waveform has
>> the same issues, but has the advantage that it would be more familiar
>> to these users than dragging above the waveform.
>>
>> Also I think that if playback, once started, adjusted to changes in the
>> selection, this would make things better for these users (and for a
>> whole lot of other users too). Once playback started, the complainants
>> could regrab and drag the selection edge as much as they wanted
>> with no need to repeatedly release the mouse and drag again.
>>
>> As I said, we don't IMO absolutely have to fix this enh by reinstating
>> SPACE with mouse down. Merely recording votes on Feature
>> Requests that users want SPACE with mouse down does not move
>> us forward as much as tracking the underlying issue that it was
>> always fiddly to adjust the selection while playing, and now one
>> method of doing that has disappeared.
>>
>> Of course, we can retitle the bug if it helps.
>>
>>
>> Gale
>>
>>
>> On 21 January 2017 at 11:22, Peter Sampson
>> <[hidden email]> wrote:
>>> Personally, I am at best neutral on techical grounds whether we restore
>>> the behaviour that enables Play to take place while the user is still in the
>>> process of making a selection.
>>>
>>> I would be strongly against extending that to allow the use of other
>>> shortcuts
>>> while the selection is still in progress with the left mouse button down.
>>> I can see a possible case for allowing zooms - but nothing else really and
>>> certainly not any Delete shortcut (which has also been compained about.
>>> albeit by a mere two people).
>>>
>>> But let's look at the ROI here.
>>> Over the year that we have had 2.1.2 out now Gale has counted 11
>>> "complaints"
>>> about the removal of that behaviour.   That makes say 12 votes for this (if
>>> you
>>> include Gale).
>>>
>>> Now look at our Feature Requests page in the Wiki:
>>> http://wiki.audacityteam.org/wiki/Feature_Requests
>>> 12 votes would clearly not merit a place in the important "Higest Rated"
>>> section.
>>> And in that section there are many much higher-scoring FRs that warrant the
>>> attention of a developer ahead of this.
>>>
>>> So my belief is that to spend developer time on thiscomparively minor UI
>>> change
>>> for just 12 people would be a very poor ROI in comparson with those Highest
>>> Rated
>>> items.
>>>
>>> --------------------------------------------------------------------------------------------------------
>>>
>>> Gale wrote:
>>>>One fix would be to disallow SPACE with mouse down, but if mouse is
>>>>down, play on mouse up.
>>>
>>> Indeed - and we already have that functionality:
>>> that is precisely what Timeline QuickPlay does and what it was designed for.
>>>
>>> The only difference is that the cursor must be in the Timeline and not over
>>> the waveform.
>>>
>>> When Steve was developing TQP Gale pointed out that he found it hard to
>>> precisely place the play position(s) when using TQP - in response to that
>>> Steve added the very useful (and usable) white lines (yellow if Snap To is
>>> on) over the waveforms to facilitate precision placement.
>>>
>>> ----------------------------------------------------------------------------------------------------
>>>
>>> With regard to how other software works and thus what users may be used
>>> to elsewhere, Gale cherry-picks his comments #5 and #7 to support his
>>> argument, carefully ignorning mine sandwiched between them:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c6
>>> in which I researched several apps that did not allow play with mouse down.
>>>
>>> Perhaps importantly, given that Windows is our major platform and that many
>>> Mac users also install and use Microsft Office, note that the Office
>>> products:
>>> Word, Excel etc. all require that the selection be fully made with the mouse
>>> up
>>> before any action on the selection can be invoked and performed.  So this is
>>> the style of behaviour that many of our users would come to expect.
>>>
>>> Peter.
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Stevethefiddle
On 21 January 2017 at 19:01, Gale Andrews <[hidden email]> wrote:

> On 21 January 2017 at 17:00, Steve the Fiddle <[hidden email]> wrote:
>> On 21 January 2017 at 16:13, Gale Andrews <[hidden email]> wrote:
>>> This is not a personal thing. I don't use playback with mouse down
>>> myself.
>>>
>>> As with feature request "votes", the number of "complaints" about
>>> anything is probably an underestimate. 11 complaints are quite
>>> indicative if they have accumulated in only one year.
>>
>> 11 complaints is indicative of what?
>> Over the past year there have been thousands of topics started about
>> all manner of things.
>
> Have we then seen the subject of those topics repeated about once a
> month?

I've not seen this issue repeated on the forum once a month.
I recall seeing a couple of forum topics about this issue.

One such topic says:
"It seems like I need to wait about half a second between the last
time I clicked a mouse button and when I press the spacebar"

>
>
>> I'd guess there have been many more "complaints" over that period
>> about not being able to record the right channel of some devices as
>> mono, but we've not been counting those, so "Allocate specific
>> channels to specific Audacity tracks:" remains as a "feature request"
>> on the wiki.
>>
>>>
>>> Bugzilla is for tracking user impacts. A bug is a user impact.
>>
>> A "bug" is something that is broken or does not work as intended.
>>
>> The inability to record the right channel of some devices as mono, has
>> obvious "user impact", so shouldn't that be on the "user impact
>> tracker"?
>
> I need to be clear what you are asking about. Do you mean when standard
> recording in stereo (not append recording), that you have no option but to
> record one stereo track?

With some sound cards, including most USB sound cards, if you want to
record the second audio channel, you have to record a stereo track and
then split it - you can't just record the second channel as a mono
track because we don't provide allocating which channel gets recorded.
The impact of this is greatest on users that have USB devices where
only the right channel can be used as an instrument input (such as
Behringer U-PHORIA UM2, Focusrite Scarlett Solo, Alesis iO Hub, ESI
Maya 22, and others).


>> If, as Bugzilla Tsar, you wish to use Bugzilla for tracking "user
>> impacts", then I think we also need to have a "bug tracker" for
>> tracking bugs. I'm quite happy for you to run Bugzilla in whatever way
>> you wish, but it is increasingly falling short of being useful for my
>> needs, both as a QA tester and developer.
>
> That seems like an overstatement to me, but is the broader issue
> rather one of tracking Enh's on Bugzilla or not?

Including "feature requests" in bugzilla is one of the contributing
factors to why I find Bugzilla less useful than it used to be. Another
major contributing factor is the length of time that bugs remain open
as "fix made" (the last time I counted there were over 80).

>
> If we allowed no Enh's on Bugzlla, then bug 1331 would not exist.
>
> I don't feel enh's are that much of a distraction. Most are P4 or P5.
> Steve authored 12 of the 92 open enh's, out of 31 enh's total he
> created.

I think that we should track on our bug tracker, issues that QA and/or
devel agree are "not right", even if they are not strictly "bugs". For
example, I think all the developers would agree that TrackPanel is in
need of refactoring, but that is not in itself a "bug".

Another example is that after discussion, QA agreed that "Zoom Normal
(Ctrl+2)" should not move the selection off-screen. Again this is not
strictly a "bug", but we agree that this is not desirable behaviour
and should be improved.

In the case of bug 1331, there is no such agreement among QA or
developers about the proposed enhancement. It's not even clear at this
stage what your requirements are for "fixing" this issue (what the
requirement is for closing the issue). Yet this is logged as a P2
issue, which indicates that it should be treated with higher priority
than, for example:
* Audacity sometimes appending AIFF as the file name for export
formats that are not AIFF,
* Envelopes being corrupted when pasting audio clips into a track.
* Toolbars fail to arrange correctly when maximizing or restoring main
window size .
* and many other real bugs that have far greater impact on far more users.

Steve

>
> On a quick scan it looks like most of Steve's enh's are not issues that
> attracted a lot of negative user input. If so, their lower rating is justified,
> IMO, versus those we have at P3 and P2.
>
> It is easy enough to create your own search result that excludes enh's.
>
> Or they could be a separate "product".
>
>
> Gale
>
>>> A feature that no longer works and drives users back to old versions
>>> of Audacity, or works so badly that there are regular complaints,
>>> is a user impact.
>>>
>>> A useful benchmark that suggests tracking may be useful is if the
>>> enhs are being reported as "bugs" by the users. Requests for
>>> real-time effect preview (when we did not have it), beat-matching
>>> or multi-channel playback have never been presented by users as
>>> "bugs".
>>>
>>> The Forum feedback seems to be clear why Timeline Quick-Play is
>>> not seen by the users as a solution. Mouse release is an extra
>>> action for the right hand that distracts from the task of making the
>>> selection. Once the mouse is up, it's too easy to click outside the
>>> area of the double-headed mouse pointer and thus destroy the
>>> original selection rather than adjust it.
>>>
>>> Playing on mouse up when dragging a selection in the waveform has
>>> the same issues, but has the advantage that it would be more familiar
>>> to these users than dragging above the waveform.
>>>
>>> Also I think that if playback, once started, adjusted to changes in the
>>> selection, this would make things better for these users (and for a
>>> whole lot of other users too). Once playback started, the complainants
>>> could regrab and drag the selection edge as much as they wanted
>>> with no need to repeatedly release the mouse and drag again.
>>>
>>> As I said, we don't IMO absolutely have to fix this enh by reinstating
>>> SPACE with mouse down. Merely recording votes on Feature
>>> Requests that users want SPACE with mouse down does not move
>>> us forward as much as tracking the underlying issue that it was
>>> always fiddly to adjust the selection while playing, and now one
>>> method of doing that has disappeared.
>>>
>>> Of course, we can retitle the bug if it helps.
>>>
>>>
>>> Gale
>>>
>>>
>>> On 21 January 2017 at 11:22, Peter Sampson
>>> <[hidden email]> wrote:
>>>> Personally, I am at best neutral on techical grounds whether we restore
>>>> the behaviour that enables Play to take place while the user is still in the
>>>> process of making a selection.
>>>>
>>>> I would be strongly against extending that to allow the use of other
>>>> shortcuts
>>>> while the selection is still in progress with the left mouse button down.
>>>> I can see a possible case for allowing zooms - but nothing else really and
>>>> certainly not any Delete shortcut (which has also been compained about.
>>>> albeit by a mere two people).
>>>>
>>>> But let's look at the ROI here.
>>>> Over the year that we have had 2.1.2 out now Gale has counted 11
>>>> "complaints"
>>>> about the removal of that behaviour.   That makes say 12 votes for this (if
>>>> you
>>>> include Gale).
>>>>
>>>> Now look at our Feature Requests page in the Wiki:
>>>> http://wiki.audacityteam.org/wiki/Feature_Requests
>>>> 12 votes would clearly not merit a place in the important "Higest Rated"
>>>> section.
>>>> And in that section there are many much higher-scoring FRs that warrant the
>>>> attention of a developer ahead of this.
>>>>
>>>> So my belief is that to spend developer time on thiscomparively minor UI
>>>> change
>>>> for just 12 people would be a very poor ROI in comparson with those Highest
>>>> Rated
>>>> items.
>>>>
>>>> --------------------------------------------------------------------------------------------------------
>>>>
>>>> Gale wrote:
>>>>>One fix would be to disallow SPACE with mouse down, but if mouse is
>>>>>down, play on mouse up.
>>>>
>>>> Indeed - and we already have that functionality:
>>>> that is precisely what Timeline QuickPlay does and what it was designed for.
>>>>
>>>> The only difference is that the cursor must be in the Timeline and not over
>>>> the waveform.
>>>>
>>>> When Steve was developing TQP Gale pointed out that he found it hard to
>>>> precisely place the play position(s) when using TQP - in response to that
>>>> Steve added the very useful (and usable) white lines (yellow if Snap To is
>>>> on) over the waveforms to facilitate precision placement.
>>>>
>>>> ----------------------------------------------------------------------------------------------------
>>>>
>>>> With regard to how other software works and thus what users may be used
>>>> to elsewhere, Gale cherry-picks his comments #5 and #7 to support his
>>>> argument, carefully ignorning mine sandwiched between them:
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c6
>>>> in which I researched several apps that did not allow play with mouse down.
>>>>
>>>> Perhaps importantly, given that Windows is our major platform and that many
>>>> Mac users also install and use Microsft Office, note that the Office
>>>> products:
>>>> Word, Excel etc. all require that the selection be fully made with the mouse
>>>> up
>>>> before any action on the selection can be invoked and performed.  So this is
>>>> the style of behaviour that many of our users would come to expect.
>>>>
>>>> Peter.
>>>>
>>>> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Gale
Administrator
On 22 January 2017 at 14:16, Steve the Fiddle <[hidden email]> wrote:

> On 21 January 2017 at 19:01, Gale Andrews <[hidden email]> wrote:
>> On 21 January 2017 at 17:00, Steve the Fiddle <[hidden email]> wrote:
>>> On 21 January 2017 at 16:13, Gale Andrews <[hidden email]> wrote:
>>>> This is not a personal thing. I don't use playback with mouse down
>>>> myself.
>>>>
>>>> As with feature request "votes", the number of "complaints" about
>>>> anything is probably an underestimate. 11 complaints are quite
>>>> indicative if they have accumulated in only one year.
>>>
>>> 11 complaints is indicative of what?
>>> Over the past year there have been thousands of topics started about
>>> all manner of things.
>>
>> Have we then seen the subject of those topics repeated about once a
>> month?
>
> I've not seen this issue repeated on the forum once a month.
> I recall seeing a couple of forum topics about this issue.

My count includes feedback@ of course.


> One such topic says:
> "It seems like I need to wait about half a second between the last
> time I clicked a mouse button and when I press the spacebar"


>>
>>
>>> I'd guess there have been many more "complaints" over that period
>>> about not being able to record the right channel of some devices as
>>> mono, but we've not been counting those, so "Allocate specific
>>> channels to specific Audacity tracks:" remains as a "feature request"
>>> on the wiki.
>>>
>>>>
>>>> Bugzilla is for tracking user impacts. A bug is a user impact.
>>>
>>> A "bug" is something that is broken or does not work as intended.
>>>
>>> The inability to record the right channel of some devices as mono, has
>>> obvious "user impact", so shouldn't that be on the "user impact
>>> tracker"?
>>
>> I need to be clear what you are asking about. Do you mean when standard
>> recording in stereo (not append recording), that you have no option but to
>> record one stereo track?
>
> With some sound cards, including most USB sound cards, if you want to
> record the second audio channel, you have to record a stereo track and
> then split it - you can't just record the second channel as a mono
> track because we don't provide allocating which channel gets recorded.
> The impact of this is greatest on users that have USB devices where
> only the right channel can be used as an instrument input (such as
> Behringer U-PHORIA UM2, Focusrite Scarlett Solo, Alesis iO Hub, ESI
> Maya 22, and others).

I would recommend they save a project containing two empty mono
tracks so they have a "recording template" they can open, then
append-record into those tracks. If that works, the only task is then
to close the upper track.

Other than some devices only allow instruments in the right channel,
is it sound card dependent at all?

I guess the above, and "recordings in mono are half volume", are
reported once or twice a month, so a little more than SPACE not
working with mouse down.

And yes "can't record from a stereo device as one or two mono tracks"
is something we could address. If we want Enh's on Bugzilla, it ought
to be there.

But because these people are not recording hundreds or more times a
day with a muscle-memory-ingrained workflow, I still see the
SPACE/mouse issue as having "greater impact".


>>> If, as Bugzilla Tsar, you wish to use Bugzilla for tracking "user
>>> impacts", then I think we also need to have a "bug tracker" for
>>> tracking bugs. I'm quite happy for you to run Bugzilla in whatever way
>>> you wish, but it is increasingly falling short of being useful for my
>>> needs, both as a QA tester and developer.
>>
>> That seems like an overstatement to me, but is the broader issue
>> rather one of tracking Enh's on Bugzilla or not?
>
> Including "feature requests" in bugzilla is one of the contributing
> factors to why I find Bugzilla less useful than it used to be.

Then why do you add them yourself? And what would you like to
do about it?

Do you want a separate product for enh's (however defined)?

Is it hard to exclude enh's using the tools provided?


> Another major contributing factor is the length of time that bugs
> remain open as "fix made" (the last time I counted there were over 80).

Not having discussions like these would help a lot. This one is
about the presence or absence and rating of one bug. Even at
P2, it can be ignored. If the number of complaints dry up, it
would be demoted.

Always adding steps to reproduce in bugs would definitely help,
especially if it's a very technical issue. Then more people could
test.

Having some initiative to encourage more people to test alpha
builds/help with Bugzilla would assist. But we don't seem to want
such an initiative.

I would think you (Steve) could probably resolve bugs with the
"nyquist" keyword yourself (obviously if I see some problem, I
could reopen them). I'm not clear how to define bugs that Peter
would be able to resolve himself, which is why I've held back
on this.

If you or Peter want, you could start a new topic about that
devolution.


>> If we allowed no Enh's on Bugzlla, then bug 1331 would not exist.
>>
>> I don't feel enh's are that much of a distraction. Most are P4 or P5.
>> Steve authored 12 of the 92 open enh's, out of 31 enh's total he
>> created.
>
> I think that we should track on our bug tracker, issues that QA and/or
> devel agree are "not right", even if they are not strictly "bugs".

But we can't have it both ways. Either Bugzilla is bugs only or it isn't.

If something happens that means some users can no longer
complete their repetitive tasks, then I argue that is "not right" and
that there is a bigger picture to consider about why those users
find it hard to use whatever alternatives there are.

If users are faced with a unintuitive, inflexible feature that makes it
look like you have to enter the same metadata for each track
in Export Multiple over and over, and frequent complaints are
received, then I argue that is "not right" and should be tracked.

> For example, I think all the developers would agree that TrackPanel
> is in need of refactoring, but that is not in itself a "bug".

If we need a reminder about that then you will have to accept Enhs
on Bugzilla, or track that in a different way, such as a Wiki Proposal.


> Another example is that after discussion, QA agreed that "Zoom Normal
> (Ctrl+2)" should not move the selection off-screen. Again this is not
> strictly a "bug", but we agree that this is not desirable behaviour
> and should be improved.

That is a good example of a useful enh, I agree. But how do we
track that if we no longer accept enh's on Bugzilla? And if we do
track it, should it be in a separate product?

I do think the P4 grade is somewhat cluttered with Enh's, and I
suspect some of the P4's could actually be P3, except that
requires a release note and a release note may not make sense.


> In the case of bug 1331, there is no such agreement among QA or
> developers about the proposed enhancement. It's not even clear at this
> stage what your requirements are for "fixing" this issue (what the
> requirement is for closing the issue).

The obvious quick fix solution, if it is safe, is to enable SPACE while
mouse is down.  I think you are saying it is safe and are only mildly
against. Peter is strongly against. If most are against we can't do
it. I would be in favour:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c19 .

But as James said:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c8

and as I said in pointing out that we don't allow playback to update
if the selection is changed, there may be longer term fixes that
would be better (have wider benefit).

Because of that "longer view" I still say, if we have enh's, then
we need an issue open for this - counting 11 user votes on
Feature Requests that SPACE should be allowed with mouse
down does not reflect the considerations involved.



> Yet this is logged as a P2
> issue, which indicates that it should be treated with higher priority
> than, for example:
> * Audacity sometimes appending AIFF as the file name for export
> formats that are not AIFF,
> * Envelopes being corrupted when pasting audio clips into a track.
> * Toolbars fail to arrange correctly when maximizing or restoring main
> window size .
> * and many other real bugs that have far greater impact on far more users.

Certainly not always "far greater" impact in terms of time, even
though exports are common and might be repetitive.  Greater
number of users - probably yes, but complaints received is
the only objective measure.

I think your list again invites the question, are Enh's less
important than bugs with the same rating?  If Enh's were a
separate product, we could avoid that question to a greater
extent. The Enh rating would show the relative rating amongst
the Enh's. There could even be P1 Enh's that are not release
blockers.

I would be fine to promote 527 and 1434 to P2 amongst the
envelope bugs:
http://bugzilla.audacityteam.org/buglist.cgi?quicksearch=envelope

If you agree, go ahead.  Or suggest something else as you
wish.



Gale




> Steve
>
>>
>> On a quick scan it looks like most of Steve's enh's are not issues that
>> attracted a lot of negative user input. If so, their lower rating is justified,
>> IMO, versus those we have at P3 and P2.
>>
>> It is easy enough to create your own search result that excludes enh's.
>>
>> Or they could be a separate "product".
>>
>>
>> Gale
>>
>>>> A feature that no longer works and drives users back to old versions
>>>> of Audacity, or works so badly that there are regular complaints,
>>>> is a user impact.
>>>>
>>>> A useful benchmark that suggests tracking may be useful is if the
>>>> enhs are being reported as "bugs" by the users. Requests for
>>>> real-time effect preview (when we did not have it), beat-matching
>>>> or multi-channel playback have never been presented by users as
>>>> "bugs".
>>>>
>>>> The Forum feedback seems to be clear why Timeline Quick-Play is
>>>> not seen by the users as a solution. Mouse release is an extra
>>>> action for the right hand that distracts from the task of making the
>>>> selection. Once the mouse is up, it's too easy to click outside the
>>>> area of the double-headed mouse pointer and thus destroy the
>>>> original selection rather than adjust it.
>>>>
>>>> Playing on mouse up when dragging a selection in the waveform has
>>>> the same issues, but has the advantage that it would be more familiar
>>>> to these users than dragging above the waveform.
>>>>
>>>> Also I think that if playback, once started, adjusted to changes in the
>>>> selection, this would make things better for these users (and for a
>>>> whole lot of other users too). Once playback started, the complainants
>>>> could regrab and drag the selection edge as much as they wanted
>>>> with no need to repeatedly release the mouse and drag again.
>>>>
>>>> As I said, we don't IMO absolutely have to fix this enh by reinstating
>>>> SPACE with mouse down. Merely recording votes on Feature
>>>> Requests that users want SPACE with mouse down does not move
>>>> us forward as much as tracking the underlying issue that it was
>>>> always fiddly to adjust the selection while playing, and now one
>>>> method of doing that has disappeared.
>>>>
>>>> Of course, we can retitle the bug if it helps.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 21 January 2017 at 11:22, Peter Sampson
>>>> <[hidden email]> wrote:
>>>>> Personally, I am at best neutral on techical grounds whether we restore
>>>>> the behaviour that enables Play to take place while the user is still in the
>>>>> process of making a selection.
>>>>>
>>>>> I would be strongly against extending that to allow the use of other
>>>>> shortcuts
>>>>> while the selection is still in progress with the left mouse button down.
>>>>> I can see a possible case for allowing zooms - but nothing else really and
>>>>> certainly not any Delete shortcut (which has also been compained about.
>>>>> albeit by a mere two people).
>>>>>
>>>>> But let's look at the ROI here.
>>>>> Over the year that we have had 2.1.2 out now Gale has counted 11
>>>>> "complaints"
>>>>> about the removal of that behaviour.   That makes say 12 votes for this (if
>>>>> you
>>>>> include Gale).
>>>>>
>>>>> Now look at our Feature Requests page in the Wiki:
>>>>> http://wiki.audacityteam.org/wiki/Feature_Requests
>>>>> 12 votes would clearly not merit a place in the important "Higest Rated"
>>>>> section.
>>>>> And in that section there are many much higher-scoring FRs that warrant the
>>>>> attention of a developer ahead of this.
>>>>>
>>>>> So my belief is that to spend developer time on thiscomparively minor UI
>>>>> change
>>>>> for just 12 people would be a very poor ROI in comparson with those Highest
>>>>> Rated
>>>>> items.
>>>>>
>>>>> --------------------------------------------------------------------------------------------------------
>>>>>
>>>>> Gale wrote:
>>>>>>One fix would be to disallow SPACE with mouse down, but if mouse is
>>>>>>down, play on mouse up.
>>>>>
>>>>> Indeed - and we already have that functionality:
>>>>> that is precisely what Timeline QuickPlay does and what it was designed for.
>>>>>
>>>>> The only difference is that the cursor must be in the Timeline and not over
>>>>> the waveform.
>>>>>
>>>>> When Steve was developing TQP Gale pointed out that he found it hard to
>>>>> precisely place the play position(s) when using TQP - in response to that
>>>>> Steve added the very useful (and usable) white lines (yellow if Snap To is
>>>>> on) over the waveforms to facilitate precision placement.
>>>>>
>>>>> ----------------------------------------------------------------------------------------------------
>>>>>
>>>>> With regard to how other software works and thus what users may be used
>>>>> to elsewhere, Gale cherry-picks his comments #5 and #7 to support his
>>>>> argument, carefully ignorning mine sandwiched between them:
>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c6
>>>>> in which I researched several apps that did not allow play with mouse down.
>>>>>
>>>>> Perhaps importantly, given that Windows is our major platform and that many
>>>>> Mac users also install and use Microsft Office, note that the Office
>>>>> products:
>>>>> Word, Excel etc. all require that the selection be fully made with the mouse
>>>>> up
>>>>> before any action on the selection can be invoked and performed.  So this is
>>>>> the style of behaviour that many of our users would come to expect.
>>>>>
>>>>> Peter.
>>>>>
>>>>> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Peter Sampson-2
Gale wrote:
>The obvious quick fix solution, if it is safe, is to enable SPACE while
>mouse is down.  I think you are saying it is safe and are only mildly
>against. Peter is strongly against. If most are against we can't do
>it. I would be in favour:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c19 .

Actually I'm pretty neutral - I just think it's a bit of a daft and unintuitive
way of using a partially-made selection  I have no othet app in my toolbox
that works that was :-//

Reperating what I said earlier in this thread:
>Personally, I am at best neutral on techical grounds whether we restore
>the behaviour that enables Play to take place while the user is still in the
>process of making a selection.
>
>I would be strongly against extending that to allow the use of other shortcuts
>while the selection is still in progress with the left mouse button down.
>I can see a possible case for allowing zooms - but nothing else really and
>certainly not any Delete shortcut (which has also been compained about.
>albeit by a mere two people).

I was and am concerned about the poor ROI on doing this for such a small sample
from among our millions of users.

But IF:
a) a developer could do this in a couple of hours in a safe and secure way
b) and if you are able to recruit such a developer
c) and if we can test it on all three platforms in half a day or so
d) and we get to close it away resolved that dat

THEN I guess we could go ahead and do it

(It's not a feature I'llbe finding myself using though - I'm more interested in accuracy
of selections I make rather than high-speed working.)

ELSE we just leave this on the shelf (and you can continue to count the number
of complaints - dates of complaints would be a useful guide as to demand too)

Peter

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Gale
Administrator
On 22 January 2017 at 18:00, Peter Sampson
<[hidden email]> wrote:

> Gale wrote:
>>The obvious quick fix solution, if it is safe, is to enable SPACE while
>>mouse is down.  I think you are saying it is safe and are only mildly
>>against. Peter is strongly against. If most are against we can't do
>>it. I would be in favour:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c19 .
>
> Actually I'm pretty neutral - I just think it's a bit of a daft and
> unintuitive
> way of using a partially-made selection  I have no othet app in my toolbox
> that works that was :-//

OK. I thought you were opposed because text editors don't do this
(and of course some audio editors don't).  But I don't see it would
make much sense for an audio editor to do it. Audio editors are a
live environment where you play audio in real time, so starting
playback while the selection is not complete could make sense.

What matters to me is if it is safe, and I am assuming yes from the
information Steve provided.


> Reperating what I said earlier in this thread:
>>Personally, I am at best neutral on techical grounds whether we restore
>>the behaviour that enables Play to take place while the user is still in
>> the
>>process of making a selection.
>>
>>I would be strongly against extending that to allow the use of other
>> shortcuts
>>while the selection is still in progress with the left mouse button down.
>>I can see a possible case for allowing zooms - but nothing else really and
>>certainly not any Delete shortcut (which has also been compained about.
>>albeit by a mere two people).

I too think there is a case for allowing the zoom shortcuts to work with
mouse down, again if safe, and that deleting with mouse down doesn't
have such a strong case.


> I was and am concerned about the poor ROI on doing this for such a small
> sample
> from among our millions of users.

For now I interpret as significant the importance of 11 reports of this
in a year, versus 60 or so over 10 years for a high rated feature
request. Of course reports will tend to peak in the first version that
has the change.

Yes, the amount of work involved in a quick fix which simply does
what the users request is part of the equation, versus longer term
improvements which could benefit not just the complainants.

The bug report is a report of a problem, not a dogmatic statement
of the solution, so as I suggested the bug could be retitled. When
the bug opened, before it was looked into, it was thought it actually
was a bug in the strictest sense.



Gale

> But IF:
> a) a developer could do this in a couple of hours in a safe and secure way
> b) and if you are able to recruit such a developer
> c) and if we can test it on all three platforms in half a day or so
> d) and we get to close it away resolved that dat
>
> THEN I guess we could go ahead and do it
>
> (It's not a feature I'llbe finding myself using though - I'm more interested
> in accuracy of selections I make rather than high-speed working.)
>
> ELSE we just leave this on the shelf (and you can continue to count the
> number
> of complaints - dates of complaints would be a useful guide as to demand
> too)
>
> Peter
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Stevethefiddle
The best solution that I can think of is to provide an option where
you don't need to use the keyboard at all - just make the selection
and have it play immediately on releasing the mouse button. Ideally
this would also allow the user to grab either end of the selection,
adjust it, and have playback of the adjusted selection (re-)start
immediately that the mouse button is released without requiring any
additional key presses.

Steve

On 23 January 2017 at 15:36, Gale Andrews <[hidden email]> wrote:

> On 22 January 2017 at 18:00, Peter Sampson
> <[hidden email]> wrote:
>> Gale wrote:
>>>The obvious quick fix solution, if it is safe, is to enable SPACE while
>>>mouse is down.  I think you are saying it is safe and are only mildly
>>>against. Peter is strongly against. If most are against we can't do
>>>it. I would be in favour:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c19 .
>>
>> Actually I'm pretty neutral - I just think it's a bit of a daft and
>> unintuitive
>> way of using a partially-made selection  I have no othet app in my toolbox
>> that works that was :-//
>
> OK. I thought you were opposed because text editors don't do this
> (and of course some audio editors don't).  But I don't see it would
> make much sense for an audio editor to do it. Audio editors are a
> live environment where you play audio in real time, so starting
> playback while the selection is not complete could make sense.
>
> What matters to me is if it is safe, and I am assuming yes from the
> information Steve provided.
>
>
>> Reperating what I said earlier in this thread:
>>>Personally, I am at best neutral on techical grounds whether we restore
>>>the behaviour that enables Play to take place while the user is still in
>>> the
>>>process of making a selection.
>>>
>>>I would be strongly against extending that to allow the use of other
>>> shortcuts
>>>while the selection is still in progress with the left mouse button down.
>>>I can see a possible case for allowing zooms - but nothing else really and
>>>certainly not any Delete shortcut (which has also been compained about.
>>>albeit by a mere two people).
>
> I too think there is a case for allowing the zoom shortcuts to work with
> mouse down, again if safe, and that deleting with mouse down doesn't
> have such a strong case.
>
>
>> I was and am concerned about the poor ROI on doing this for such a small
>> sample
>> from among our millions of users.
>
> For now I interpret as significant the importance of 11 reports of this
> in a year, versus 60 or so over 10 years for a high rated feature
> request. Of course reports will tend to peak in the first version that
> has the change.
>
> Yes, the amount of work involved in a quick fix which simply does
> what the users request is part of the equation, versus longer term
> improvements which could benefit not just the complainants.
>
> The bug report is a report of a problem, not a dogmatic statement
> of the solution, so as I suggested the bug could be retitled. When
> the bug opened, before it was looked into, it was thought it actually
> was a bug in the strictest sense.
>
>
>
> Gale
>
>> But IF:
>> a) a developer could do this in a couple of hours in a safe and secure way
>> b) and if you are able to recruit such a developer
>> c) and if we can test it on all three platforms in half a day or so
>> d) and we get to close it away resolved that dat
>>
>> THEN I guess we could go ahead and do it
>>
>> (It's not a feature I'llbe finding myself using though - I'm more interested
>> in accuracy of selections I make rather than high-speed working.)
>>
>> ELSE we just leave this on the shelf (and you can continue to count the
>> number
>> of complaints - dates of complaints would be a useful guide as to demand
>> too)
>>
>> Peter
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why enh bug 1331 is there and what to do about it

Gale
Administrator
On 23 January 2017 at 17:18, Steve the Fiddle <[hidden email]> wrote:
> The best solution that I can think of is to provide an option where
> you don't need to use the keyboard at all - just make the selection
> and have it play immediately on releasing the mouse button. Ideally
> this would also allow the user to grab either end of the selection,
> adjust it, and have playback of the adjusted selection (re-)start
> immediately that the mouse button is released without requiring any
> additional key presses.

That sounds almost the same as Quick-Play, so is the idea that this
is a special play mode if you drag and release a selection in the
waveform?

When you drag the selection, release the mouse then drag the right
selection edge, I think there should be some way to play seamlessly
according to the adjusted selection. Likewise with dragging the left
edge, if we ever have non-scrub reverse playback.

Use cases:

* Drag the selection, release to play, drag the right edge of the
  selection further to right then have the audio continue to the end
  of the new selection and stop.

* Drag the selection, release to play, drag the right edge leftwards
  then have the audio stop at the end of the new selection instead
  of going past it.

I think those two bullet points would help these people, but the method
of starting playback by releasing the mouse is a problem. Presumably
to keep playing after adjusting the selection, they would keep holding
the mouse, but then releasing the mouse would restart playback from
the start when they may not want to restart at all. Until the Widgets
change, whether to restart or stop was fully controllable with SPACE.

Also, how much the above would help them, especially without
self-adjusting playback, depends on how easy it is to regrab the
selection edge after releasing the mouse. With what they used to be
able to do, it's hugely easy, because you never let go of the selection
edge in the first place.


Gale

> On 23 January 2017 at 15:36, Gale Andrews <[hidden email]> wrote:
>> On 22 January 2017 at 18:00, Peter Sampson
>> <[hidden email]> wrote:
>>> Gale wrote:
>>>>The obvious quick fix solution, if it is safe, is to enable SPACE while
>>>>mouse is down.  I think you are saying it is safe and are only mildly
>>>>against. Peter is strongly against. If most are against we can't do
>>>>it. I would be in favour:
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c19 .
>>>
>>> Actually I'm pretty neutral - I just think it's a bit of a daft and
>>> unintuitive
>>> way of using a partially-made selection  I have no othet app in my toolbox
>>> that works that was :-//
>>
>> OK. I thought you were opposed because text editors don't do this
>> (and of course some audio editors don't).  But I don't see it would
>> make much sense for an audio editor to do it. Audio editors are a
>> live environment where you play audio in real time, so starting
>> playback while the selection is not complete could make sense.
>>
>> What matters to me is if it is safe, and I am assuming yes from the
>> information Steve provided.
>>
>>
>>> Reperating what I said earlier in this thread:
>>>>Personally, I am at best neutral on techical grounds whether we restore
>>>>the behaviour that enables Play to take place while the user is still in
>>>> the
>>>>process of making a selection.
>>>>
>>>>I would be strongly against extending that to allow the use of other
>>>> shortcuts
>>>>while the selection is still in progress with the left mouse button down.
>>>>I can see a possible case for allowing zooms - but nothing else really and
>>>>certainly not any Delete shortcut (which has also been compained about.
>>>>albeit by a mere two people).
>>
>> I too think there is a case for allowing the zoom shortcuts to work with
>> mouse down, again if safe, and that deleting with mouse down doesn't
>> have such a strong case.
>>
>>
>>> I was and am concerned about the poor ROI on doing this for such a small
>>> sample
>>> from among our millions of users.
>>
>> For now I interpret as significant the importance of 11 reports of this
>> in a year, versus 60 or so over 10 years for a high rated feature
>> request. Of course reports will tend to peak in the first version that
>> has the change.
>>
>> Yes, the amount of work involved in a quick fix which simply does
>> what the users request is part of the equation, versus longer term
>> improvements which could benefit not just the complainants.
>>
>> The bug report is a report of a problem, not a dogmatic statement
>> of the solution, so as I suggested the bug could be retitled. When
>> the bug opened, before it was looked into, it was thought it actually
>> was a bug in the strictest sense.
>>
>>
>>
>> Gale
>>
>>> But IF:
>>> a) a developer could do this in a couple of hours in a safe and secure way
>>> b) and if you are able to recruit such a developer
>>> c) and if we can test it on all three platforms in half a day or so
>>> d) and we get to close it away resolved that dat
>>>
>>> THEN I guess we could go ahead and do it
>>>
>>> (It's not a feature I'llbe finding myself using though - I'm more interested
>>> in accuracy of selections I make rather than high-speed working.)
>>>
>>> ELSE we just leave this on the shelf (and you can continue to count the
>>> number
>>> of complaints - dates of complaints would be a useful guide as to demand
>>> too)
>>>
>>> Peter
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...