Re: [Audacity-quality] Bug 647 Snap To Direction WAS Re: BSG bug (Was: Audacity 2.0.5rc1 ready for testing!)

[Steve t. F. <ste...@gm...>]

On 29 October 2013 21:21, Gale Andrews <ga...@au...> wrote:
>
> | From Peter Sampson <pet...@ya...>
> | Tue, 29 Oct 2013 03:10:07 -0700 (PDT)
> | Subject: [Audacity-quality] BSG bug (Was: Audacity 2.0.5rc1 ready for testing!)
>> Gale wrote:
>> > However a choice for snapping to "nearest" or "nearest previous"
>> > is more pressing, according to my inbox. Unless Steve and Peter
>> > are going to accept nearest previous as it is now.
>>
>> Like Steve, I seldom (never in fact, unless testing or documenting) use
>> snap-to.
>
> Then perhaps you should defer to stated use cases of people who
> do use Snap To?

Unfortunately I don't think that we have a representative sample.
We have "some" users that have been working with obsolete beta
versions for a long time that are complaining that the behaviour has
changed. Users that are happy with the change are unlikely to write
in.

>
>
>>  My objection to "nearest previous" stems from the fact that
>> it would be a regression.  We have *never* had snapping to "nearest
>> previous" in any formal release of Audacity, not in 1.2 x nor 2.0.x.
>>
>>
>> Steve wrote:
>> >To me it looks like a bug was introduced in 1.3.3 and fixed in 1.3.13.
>>
>> Indeed, this behaviour is a temporary aberration introduced during Beta
>> testing.
>>
>> The use case that you quote, Gale, comes from users using early Betas
>> and getting used to the aberrant behaviour introduced there.  You, Gale,
>> are usually one of the keenest adherents of avoiding regressions so I'm
>> somewhat surprised that you seem keen to support this particular one.
>
> Your argument totally assumes that the behaviour in 1.2 was correct
> or preferred in some sense in the first place. As I see it, the regression
> that is fixed in the current code was on 1.3.3.
>
> After the "bug" was "fixed" in 1.3.13 there have been repeated complaints
> about the change, to the extent that the affected users feel the need to
> stop with 1.3.x.

How many users are we talking about (roughly)?

> In contrast, no use case has been presented for "snap
> to nearest" by those who actually use the feature.

Although (at present) I rarely use the feature in the type of work
that I generally do with Audacity, I do use the equivalent feature in
other software and in other software it is invariably "snap to
closest". I know that "the majority" are not always right, but in this
case it seems that *all* audio software companies (other than
Audacity) agree that grid snapping should be to the closest. As the
"Snap to previous" appears to have happened by accident I'm not
convinced that all the others are wrong, even if a few users have
written in to feedback@.

>> >If we have a preference then the user can choose...
>>
>> Big +1 to that, but the default should remain snap-to "nearest", again in
>> the interests of avoiding a regression.
>
> That depends where you consider the regression to be. There may be
> a case for default behaviour staying as it was in 2.0.5 release, but
> since users of Snap To are complaining about that very behaviour,
> and only non-users of Snap To are arguing for it, I'm inclined to think
> the default should be snap to previous.
>
> That way we'll hear if anyone who uses snap to wants it as was in
> 2.0.5 release. I asked for views on Snap To direction in the Release
> Notes, but the only people who replied were the same people who
> already asked for it to be changed back to nearest previous.
>
>
>> But I thought that the developers are not keen on introducing new
>> preferences, though I'm never sure why.
>
> It doesn't have to be a Preference. It could perhaps be a second
> checkbox, only one of which can be enabled at a time.

or a drop down menu?

Steve

>
>
>
> Gale
>
>
>>  Audacity is now a complex product and of its nature it requires a complexity
>> of controls to manage it properly.  I'm guessing that a lot of users seldom,
>> if ever, look at preferences anyway and just use Audacity with "factory settings"
>> OOTB.
>
>>   From: Gale Andrews <ga...@au...>
>>  To: audacity-quality <aud...@li...>
>>  Sent: Monday, October 28, 2013 11:33 PM
>>  Subject: Re: [Audacity-quality] BSG bug (Was: Audacity 2.0.5rc1 ready for testing!)
>>
>>
>>
>> | From Steve the Fiddle <ste...@gm...>
>> | Mon, 28 Oct 2013 22:56:09 +0000
>> | Subject: [Audacity-quality] BSG bug (Was: Audacity 2.0.5rc1 ready for testing!)
>> > >
>> > > However a choice for snapping to "nearest" or "nearest previous"
>> > > is more pressing, according to my inbox. Unless Steve and Peter
>> > > are going to accept nearest previous as it is now.
>> >
>> > Snapping to the nearest seems far more logical / expected / intuitive to me.
>> > What's the use case for snapping to the previous? Is this to help left
>> > handed users?
>>
>> The clearly stated use case in
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=647
>>
>> is snapping to frames.
>>
>> What was the use case for the unannounced and undiscussed
>> change to snapping to nearest?
>>
>>
>> > I rarely use the "Snap To:" feature, so I don't currently have a
>> > strong opinion about this. However, I hope that at some time in the
>> > future we will have the option to "Snap to:" bars and beats, and then
>> > I expect that I'll get quite stroppy about not snapping to the nearest
>> > :-)
>>
>> Perhaps. I would still like to snap to the nearest previous (complete)
>> bar or beat.
>>
>> If we have a preference then the user can choose...
>>
>>
>>
>>
>> Gale
>>
>>
>> > >> It may be a bit much to produce yellow lines every time a dragged clip
>> > >> edge crosses a snap to position when "Snap To:" is set to samples, so
>> > >> perhaps the appearance of yellow guides should depend on zoom level.
>> > >> If zoomed in close enough to see individual time units, then yellow
>> > >> guides appear, but when zoomed out such that time units are too close
>> > >> together then yellow snap guides do not appear, though snapping still
>> > >> occurs.
>> > >
>> > > +1, but probably few users care about this.
>> > >
>> > >
>> > >
>> > > Gale
>> > >
>> > >
>> > >> > I do feel that if a user does not change their time selection format then
>> > >> > they
>> > >> > should reasonably expect BSGs to work whether or not snap-to is "on" or
>> > >> > "off".  Which means, I think, that labels should always be created or moved
>> > >> > to
>> > >> > an exact boundary of whatever the user's current time selection format is.
>> > >> >
>> > >> > Thanks,
>> > >> > Peter.
>> > >> >
>> > >> > Peter Sampson
>> > >> > Tel: +44 (0)1625 524 780
>> > >> > Mob: +44 (0)7732 278 299
>> > >> >
>> > >> > From: Gale Andrews <ga...@au...>
>> > >> > To: audacity-quality <aud...@li...>
>> > >> > Sent: Sunday, October 27, 2013 8:25 PM
>> > >> > Subject: Re: [Audacity-quality] BSG bug (Was: Audacity 2.0.5rc1 ready for
>> > >> > testing!)
>> > >> >
>> > >> >
>> > >> > | From Leland <le...@au...>
>> > >> > | Sun, 27 Oct 2013 14:34:15 -0500
>> > >> > | Subject: [Audacity-quality] BSG bug (Was: Audacity 2.0.5rc1 ready for
>> > >> > testing!)
>> > >> >> On 10/27/2013 2:33 PM, Leland wrote:
>> > >> >> > On 10/27/2013 1:22 PM, Leland wrote:
>> > >> >> >> Can y'all try this again?  I believe I've found my screw up.
>> > >> >> >>
>> > >> >> >> However, I had a hard time following the conversation and determining
>> > >> >> >> when the BSG should appear or not, so there might still be issues.
>> > >> >> >>
>> > >> >> >> Also, when SnapTo is on and you are sliding a clip left and right, it
>> > >> >> >> seems to me that a BSG should appear when the clip edge crosses a snap
>> > >> >> >> point (left or right edge depending on slide direction).
>> > >> >
>> > >> > That works for me in one case - dragging a clip above a point label
>> > >> > that is on a sample point. But it also works (and should do) when
>> > >> > dragging above a label that is not on a sample point.
>> > >> >
>> > >> > Do you mean if the Selection Format was seconds, Snap To on, the
>> > >> > guide should light up when crossing a whole second point, even if
>> > >> > there was no physical boundary? That might be visually intrusive.
>> > >> >
>> > >> > Time shifts are allowed to park themselves anywhere, like add label
>> > >> > at playback position.
>> > >> >
>> > >> >
>> > >> >> > And what about labels?  When SnapTo is on, should dragging a label or
>> > >> >> > adjusting label length always snap to a snap point?
>> > >> >> Or at least, show a BSG when crossing a snap point?
>> > >> >
>> > >> > IMO the label drag should show a guide when aligned with a
>> > >> > physical boundary (such as a clip edge or the edge of another
>> > >> > label), whether Snap To is on or off.
>> > >> >
>> > >> > A significant problem now is that you can't drag join labels
>> > >> > to each other easily because there is no guide shown when
>> > >> > they are aligned.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Gale
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality