Quantcast

Accessibility of Spectral Selection Toolbar at high frequencies

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

Re: Accessibility of Spectral Selection Toolbar at high frequencies

Stevethefiddle
On 17 April 2017 at 19:00, Gale Andrews <[hidden email]> wrote:

> On 17 April 2017 at 17:07, Steve the Fiddle <[hidden email]> wrote:
>> On 17 April 2017 at 16:53, Gale Andrews <[hidden email]> wrote:
>>> On 17 April 2017 at 11:49, Steve the Fiddle <[hidden email]> wrote:
>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]> wrote:
>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>>
>>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>>> helping out by writing a bug report when they see a user report or
>>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>
>>>>>> When I logged the bug, I had no more information than you.
>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>
>>>>> User information often isn't correct. If we can't reproduce what
>>>>> they say I think it's better to write steps for what we can
>>>>> reproduce, then refer to the user's discrepant account in the
>>>>> description.
>>>>>
>>>>>
>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>> you.
>>>>>
>>>>> That isn't very efficient, and it is something that can be delegated
>>>>> to everyone with Bugzilla access.
>>>>
>>>> I'm a "volunteer" not an employee.
>>>
>>> None of us are commercially salaried employees.
>>
>> Well you would be closest to that description, but that's not my point.
>> My point is that you have no authority to tell me what to do. You may
>> of course say what you believe needs to be done, and hopefully one of
>> the volunteers will feel sufficiently motivated to rise to the task.
>
> I have said things like "please" and that it would help me for others
> to create bugs (with Steps to Reproduce).
>
> I feel that asking people to log bugs with essential information is a
> reasonable thing for someone who manages Bugzilla to ask.
>
> As always, if you believe that Team no longer mandates me to manage
> Bugzilla, you need to call a vote on that. I had that explicit mandate
> when I was the only QA'er.
>
> Alternatively you may wait and see if an RM makes the same request
> of you that I do and then argue your case against with him.
>
> Basically though if you are not willing to enter bugs with Steps to
> Reproduce, then for the reasons I gave, I think that makes it more
> difficult for everyone. Fortunately you are the only one so far who
> consistently doesn't add steps to reproduce. Thanks to those who do.

Excuse me Gale, but I do enter steps to reproduce when:
a) clear steps to reproduce are known to me
b) including steps helps to clarify the nature of the problem

What's important to me is that bugs are logged when we become aware of
them, that they are described as clearly and accurately as possible at
the time, so that they may be fixed and closed in a timely manner.
It's unfortunate that you feel that my efforts are unhelpful.

Steve

>
>
>
> Gale
>
>
> .
>
>>>>> However a bug report with no steps to reproduce and a partial
>>>>> description might be no better than one with wrong information,
>>>>> as we saw today. If the person reading it has not seen the user
>>>>> report that generated it, or comes to it a long time after the
>>>>> report, lack of steps can be a serious drawback.
>>>>
>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>> That looks pretty clear to me that there's one or more problems in the
>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>
>>> James.was the one who complained it was not clear.
>>>
>>> What happens if we get more testers working on Bugzilla?
>>> They could find it even harder with no steps to reproduce.
>>>
>>>
>>>> You have said many times that bugs cannot be closed until the full
>>>> scope of the bug has been investigated, in fact, that was a reason
>>>> that you gave for not allowing Peter or myself to close bugs.
>>>
>>> We are talking about opening bugs here, not closing them.
>>>
>>> The invitation still stands for you/Peter to talk to me (offlist) about
>>> some delegation of bug resolution. There is already delegation
>>> for creating bugs and setting their initial priority as the creator
>>> sees fit. I was hoping to see more of that happening.
>>>
>>>
>>>>> So I would say go ahead and log please, but not until you are
>>>>> able to add steps.
>>>>
>>>> We may not immediately have time to fully analyse the problem and work
>>>> out steps to fully characterise the problem, and that delay before
>>>> logging the bug may increase the likelihood of it not being logged at
>>>> all
>>>
>>> As I said, you should log immediately for P1/P2 close to release.
>>>
>>> There are indeed some bugs I have not put on Bugzilla yet
>>> because they are complex to characterise, with multi-faceted
>>> Steps to Reproduce. However I am also confident that if I
>>> put them on Bugzilla with a one line description, a developer
>>> would not have enough information to do anything about them.
>>>
>>> In the case of this bug 1633, it took me about five minutes to
>>> test enough that would have let me write meaningful steps to
>>> reproduce. Surely we can be pragmatic in a case like that,
>>> and post when we can make a good report?
>>>
>>>
>>> Gale
>>>
>>>> but I accept that it's your decision.
>>>
>>>
>>>>
>>>> Steve
>>>>
>>>>> The only exception might be a P2/P1 that
>>>>> was found close to release. In that case the RM needs to
>>>>> know ASAP and there should be no shortage of willing hands
>>>>> to fill in the blanks.
>>>>>
>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>> tracker when you have completed testing.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>>>> See, it's even caught you out now. :=)
>>>>>>>
>>>>>>>
>>>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>>>> The issue was not described there either. The email is saying that VI users
>>>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they can.
>>>>>>>>
>>>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>>>> unintuitive for VI users?
>>>>>>>
>>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>>
>>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>>> unique value for the position. That would be consistent.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>>> --James.
>>>>>>>>
>>>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>>>>
>>>>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>>>>
>>>>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>>>>> truncation, just as when you select in a 38 hour track using samples format,
>>>>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>>>>> values.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gale
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>>>>> Steve wrote in:
>>>>>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>>>>>
>>>>>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>>>>>> an exceptional case for audio)".
>>>>>>>>>>>
>>>>>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>>>>>> 100 000 Hz.
>>>>>>>>>>>
>>>>>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>>>>>> reasonable.
>>>>>>>>>>>
>>>>>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> 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: Accessibility of Spectral Selection Toolbar at high frequencies

Gale
Administrator
In reply to this post by James Crook
We don't know Audacity will get a lot of use before freeze.

A lot of store was set on mid-term (KTT) and experimental
(auteur) releases, but we are not yet enlarging the market
for people who may test those. Until we do, it will still be
mainly "us" who test.


Gale


On 17 April 2017 at 19:08, James Crook <[hidden email]> wrote:

> On 4/17/2017 5:32 PM, Gale Andrews wrote:
>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>
>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>> Where I am coming from on this is only indirectly about practicalities and
>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>> visibly see a bug progressing towards closure.
>>>>
>>>> My first commit, I hoped, was enough to close the bug:
>>>>
>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>
>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>> less important than the original (minor) issue arrived.  My peve about the
>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>> the bug.
>>>>
>>>> My second commit fixes that residual issue too:
>>>>
>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>
>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>> wrong too.
>>>>
>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>
>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>
>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>
>>>>
>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>> Then someone reading the comment trail knows that essentially a new or
>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>> important as it was originally, and indeed the original bug may have been
>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>> bug fixer.
>>>>
>>>> Again this is not so much about practicalities as about how it feels to
>>>> fix the bugs.
>>>
>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>
>>> But as we know, even if there are clear Steps To Reproduce and testing
>>> passes those - Gale will
>>> usually insist on "testing around" and not just relying on steps-passing to
>>> close the bug, and that
>>> can take a lot of time.
>> James has consistently backed me on testing to see if the fix
>> breaks other things, and if seems appropriate, testing more than
>> the steps to reproduce.
> Testing around, especially of P1s P2s, is essential when we are getting
> close to release, e.g. after freeze.
> A case can be made for being more relaxed about it earlier in release
> cycle - especially if we know Audacity is going to get a lot of use
> before freeze.
>
> A strong case can be made for closing bugs where the presenting symptoms
> are fixed, and opening new ones for new but related issues.  The
> alternative can work too, but risks very long bug trails and unhappy
> testers/fixers.  I think our testers/fixers are a bit unhappy, but long
> bug trails aren't the sole cause.
>
>
>>
>> If other testers indicated that they had done that in the bug comments,
>> rather than testing the steps and giving up, then there might be
>> fewer obstacles to delegating closure rights.
>>
>> And if only the steps are tested, that puts even more importance on
>> the steps not only being accurate, but including all the symptoms
>> that can be reproduced.
>>
>>
>> Gale
>>
>>
>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>
>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>> wrote:
>>>>
>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>
>>>> Gale, that issue was not in the steps to reproduce
>>>>
>>>> Well, isn't that the very point I have been making? I appreciate others
>>>> helping out by writing a bug report when they see a user report or
>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>
>>>> When I logged the bug, I had no more information than you.
>>>> I didn't include all of the detail reported by the person that wrote
>>>> in to feedback@ because it did not appear to be correct, and in my
>>>> opinion, incorrect information is worse than incomplete information.
>>>>
>>>> User information often isn't correct. If we can't reproduce what
>>>> they say I think it's better to write steps for what we can
>>>> reproduce, then refer to the user's discrepant account in the
>>>> description.
>>>>
>>>>
>>>> If you prefer that I don't log bugs until I have time to work out the
>>>> full scope of the issue, including detailed steps to reproduce, then
>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>> you.
>>>>
>>>> That isn't very efficient, and it is something that can be delegated
>>>> to everyone with Bugzilla access.
>>>>
>>>> I'm a "volunteer" not an employee.
>>>>
>>>>
>>>> However a bug report with no steps to reproduce and a partial
>>>> description might be no better than one with wrong information,
>>>> as we saw today. If the person reading it has not seen the user
>>>> report that generated it, or comes to it a long time after the
>>>> report, lack of steps can be a serious drawback.
>>>>
>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>> That looks pretty clear to me that there's one or more problems in the
>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>
>>>> You have said many times that bugs cannot be closed until the full
>>>> scope of the bug has been investigated, in fact, that was a reason
>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>
>>>>
>>>> So I would say go ahead and log please, but not until you are
>>>> able to add steps.
>>>>
>>>> We may not immediately have time to fully analyse the problem and work
>>>> out steps to fully characterise the problem, and that delay before
>>>> logging the bug may increase the likelihood of it not being logged at
>>>> all,  but I accept that it's your decision.
>>>>
>>>> Steve
>>>>
>>>> The only exception might be a P2/P1 that
>>>> was found close to release. In that case the RM needs to
>>>> know ASAP and there should be no shortage of willing hands
>>>> to fill in the blanks.
>>>>
>>>> For bugs that are not time sensitive, perhaps you could say to
>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>> tracker when you have completed testing.
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> See, it's even caught you out now. :=)
>>>>
>>>>
>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>> The issue was not described there either. The email is saying that VI
>>>> users
>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>> can.
>>>>
>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>> different cause.  One possible fix is to make the number of digits in
>>>> the Hz display variable, rather than truncate, but that might prove
>>>> unintuitive for VI users?
>>>>
>>>> Can you say then how we would display in Hz, a spectral selection of
>>>> 120 000 Hz to 180 000 Hz?
>>>>
>>>> I can't discuss what technically could be done, but I think it "should"
>>>> behave as Selection Toolbar does when the format can't show a
>>>> unique value for the position. That would be consistent.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> --James.
>>>>
>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>
>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>
>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>> inconvenienced, I have addressed this issue with following commit:
>>>>
>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>
>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>> I don't see that I could resolve the bug just with that.
>>>>
>>>> In Hz format, the display of High Frequency remains incorrect above
>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>
>>>> Surely it should show the correct High and Low frequencies with leading
>>>> truncation, just as when you select in a 38 hour track using samples
>>>> format,
>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>> values.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>
>>>> Steve wrote in:
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>
>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>> an exceptional case for audio)".
>>>>
>>>> For display I might agree, but this does mean that Spectral Selection
>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>> there is no way for VI users to create spectral selections above
>>>> 100 000 Hz.
>>>>
>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>> Selection Toolbar to create selections or move the cursor because
>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>> format because the leading values are truncated, which I agree is
>>>> reasonable.
>>>>
>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>> (still only P4) unless there is a technical reason why not.
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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

------------------------------------------------------------------------------
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: Accessibility of Spectral Selection Toolbar at high frequencies

Gale
Administrator
In reply to this post by James Crook
On 17 April 2017 at 19:14, James Crook <[hidden email]> wrote:

> On 4/17/2017 5:44 PM, Gale Andrews wrote:
>> On a general point, for a commit like:
>> https://github.com/audacity/audacity/commit/80928b
>>
>> where the string is a TimeText control, will we ever be able to
>> handle the decimal separator automatically as effects do,
>> so that we simply don't need to present a TimeText string?
> I'll answer a related question, which is that changes to the time text
> strings can be made more impervious to translator omissions.
>
> As long as we include 'h', 'm', 's', 'sample' and such in the time text
> string we have to send the strings for translation, since we can't know
> what to do for every single language ourselves.  The switch between .
> and , could be handled by code if nothing else had to be done to these
> strings.

OK, so this would work for Hz and kHz but not for all units.

But is it not then possible to use some untranslated placeholder
in the TimeText code, and point that placeholder to the word
for the translated unit which is a string on its own?


Gale

>> On 16 April 2017 at 22:36, James Crook <[hidden email]> wrote:
>>> OK.  So VI users who who work with bat and/or porpoise sounds and who
>>> choose, despite the high frequencies, to work in Hz rather than kHz,
>>> should now not be inconvenienced:
>>>
>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>
>>> However I notice that the crucial format string is a translated string,
>>> so until translators update their translation strings too (unless they
>>> never provided one for that format in the first place and so relied on
>>> the untranslated version) the kHz display will still have too few digits
>>> in those translations.
>>>
>>> So VI users who who work with bat and/or porpoise sounds, whether they
>>> choose to work in Hz or kHz, if they happen to use the interface in
>>> GERMAN or happen not to realise values in the high frequency control are
>>> being truncated, WILL still be inconvenienced.  If you want to leave bug
>>> 1633 still open for this or some other residual bug of similar
>>> importance, please at least demote 1633 from P4 to P5.
>>>
>>>
>>> --James.
>>>
>>>
>>>
>>> On 4/16/2017 9:13 PM, Gale Andrews wrote:
>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>> Gale, that issue was not in the steps to reproduce
>>>> Well, isn't that the very point I have been making? I appreciate others
>>>> helping out by writing a bug report when they see a user report or
>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>
>>>> See, it's even caught you out now. :=)
>>>>
>>>>
>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>> The issue was not described there either. The email is saying that VI users
>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they can.
>>>>>
>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>> different cause.  One possible fix is to make the number of digits in
>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>> unintuitive for VI users?
>>>> Can you say then how we would display in Hz, a spectral selection of
>>>> 120 000 Hz to 180 000 Hz?
>>>>
>>>> I can't discuss what technically could be done, but I think it "should"
>>>> behave as Selection Toolbar does when the format can't show a
>>>> unique value for the position. That would be consistent.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>>> --James.
>>>>>
>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>
>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>
>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>> truncation, just as when you select in a 38 hour track using samples format,
>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>> values.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>> Steve wrote in:
>>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>>
>>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>>> an exceptional case for audio)".
>>>>>>>>
>>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>>> 100 000 Hz.
>>>>>>>>
>>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>>> reasonable.
>>>>>>>>
>>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>>
>>>>>>>>
>>>>>>>> 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

------------------------------------------------------------------------------
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: Accessibility of Spectral Selection Toolbar at high frequencies

James Crook
On 4/17/2017 8:50 PM, Gale Andrews wrote:

> On 17 April 2017 at 19:14, James Crook <[hidden email]> wrote:
>> On 4/17/2017 5:44 PM, Gale Andrews wrote:
>>> On a general point, for a commit like:
>>> https://github.com/audacity/audacity/commit/80928b
>>>
>>> where the string is a TimeText control, will we ever be able to
>>> handle the decimal separator automatically as effects do,
>>> so that we simply don't need to present a TimeText string?
>> I'll answer a related question, which is that changes to the time text
>> strings can be made more impervious to translator omissions.
>>
>> As long as we include 'h', 'm', 's', 'sample' and such in the time text
>> string we have to send the strings for translation, since we can't know
>> what to do for every single language ourselves.  The switch between .
>> and , could be handled by code if nothing else had to be done to these
>> strings.
> OK, so this would work for Hz and kHz but not for all units.
>
> But is it not then possible to use some untranslated placeholder
> in the TimeText code, and point that placeholder to the word
> for the translated unit which is a string on its own?

We can do a bit better than that and add some logic that tests that the
translated format string is 'reasonable'.   If it does not have enough
digits at the start, then we can fix that, by insertion, or by falling
back to the untranslated string.  That way a 'fuzzy' translation (to the
old translated string) WILL work correctly.

We are better off giving the translator more context rather than
atomizing the translation.  If we break it up too much, they don't have
enough context to work with.  Consider also that some languages might
put the units before the number rather than after.

--James.


------------------------------------------------------------------------------
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: Accessibility of Spectral Selection Toolbar at high frequencies

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

> On 17 April 2017 at 19:00, Gale Andrews <[hidden email]> wrote:
>> On 17 April 2017 at 17:07, Steve the Fiddle <[hidden email]> wrote:
>>> On 17 April 2017 at 16:53, Gale Andrews <[hidden email]> wrote:
>>>> On 17 April 2017 at 11:49, Steve the Fiddle <[hidden email]> wrote:
>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]> wrote:
>>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>>>
>>>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>>>> helping out by writing a bug report when they see a user report or
>>>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>>
>>>>>>> When I logged the bug, I had no more information than you.
>>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>>
>>>>>> User information often isn't correct. If we can't reproduce what
>>>>>> they say I think it's better to write steps for what we can
>>>>>> reproduce, then refer to the user's discrepant account in the
>>>>>> description.
>>>>>>
>>>>>>
>>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>>> you.
>>>>>>
>>>>>> That isn't very efficient, and it is something that can be delegated
>>>>>> to everyone with Bugzilla access.
>>>>>
>>>>> I'm a "volunteer" not an employee.
>>>>
>>>> None of us are commercially salaried employees.
>>>
>>> Well you would be closest to that description, but that's not my point.
>>> My point is that you have no authority to tell me what to do. You may
>>> of course say what you believe needs to be done, and hopefully one of
>>> the volunteers will feel sufficiently motivated to rise to the task.
>>
>> I have said things like "please" and that it would help me for others
>> to create bugs (with Steps to Reproduce).
>>
>> I feel that asking people to log bugs with essential information is a
>> reasonable thing for someone who manages Bugzilla to ask.
>>
>> As always, if you believe that Team no longer mandates me to manage
>> Bugzilla, you need to call a vote on that. I had that explicit mandate
>> when I was the only QA'er.
>>
>> Alternatively you may wait and see if an RM makes the same request
>> of you that I do and then argue your case against with him.
>>
>> Basically though if you are not willing to enter bugs with Steps to
>> Reproduce, then for the reasons I gave, I think that makes it more
>> difficult for everyone. Fortunately you are the only one so far who
>> consistently doesn't add steps to reproduce. Thanks to those who do.
>
> Excuse me Gale, but I do enter steps to reproduce when:
> a) clear steps to reproduce are known to me

I would argue Steve that at least one set of steps must have
been known to you on Linux in order to write the description
you did and respond to the user as you did.


> b) including steps helps to clarify the nature of the problem

It's hard for me to think of a case where that would not be true,
considering that the potential tester reading the bug may not
have the knowledge of the feature that you do. I refer you to
Cliff's comment.

You did not give Steps to Reproduce in any of the ClipFix bugs.
You clearly could manage without and so (in that case) could I,
but another tester might not, and so be dissuaded from testing.

For what it's worth I think you could close all Nyquist keyword
bugs yourself, as I may have mentioned before (of course
anyone could reopen them if they have a reason). The problem
I have with that is that if you fix the bugs, then the developer
fixing them is closing the bug, which we try to avoid.

I appreciate you (and Peter) actually want more general powers to
resolve bugs, but I think you will have to start that dialogue with
me and see where it takes us. Or, vote me out if you can manage
to do it.


> What's important to me is that bugs are logged when we become aware of
> them, that they are described as clearly and accurately as possible at
> the time, so that they may be fixed and closed in a timely manner.

I don't see the overarching importance of instant add to Bugzilla
for bugs at P3 or below if that means the information in the report
is sketchy.

We don't have massive bug fixing resources, so if a fix is not
attempted quickly, then by the time it is attempted, even the
reporter may have forgotten how to reproduce the bug unless
the details are clearly set out at the time.

If we are really unsure what is going on with a bug then I thought
we would tend to triage it on -quality first. Right now we would
get more takers that way. The default Bugzilla Cc when you
create a bug is minimal.

Also, how many of the bugs arising from James's recent changes
should we be tracking? There are lots of bugs, and though I have
snipped most of them locally, I assume James would find it unhelpful
to log them when he already knows about them and is working on them.
I only intended to add them if they get forgotten.


> It's unfortunate that you feel that my efforts are unhelpful.

That is an exaggeration. But as I see it, a good bug tracker would
have Steps to Reproduce as a mandatory field. Ours does not.
Writing steps is a much clearer way of describing a bug.



Gale



>> .
>>
>>>>>> However a bug report with no steps to reproduce and a partial
>>>>>> description might be no better than one with wrong information,
>>>>>> as we saw today. If the person reading it has not seen the user
>>>>>> report that generated it, or comes to it a long time after the
>>>>>> report, lack of steps can be a serious drawback.
>>>>>
>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>
>>>> James.was the one who complained it was not clear.
>>>>
>>>> What happens if we get more testers working on Bugzilla?
>>>> They could find it even harder with no steps to reproduce.
>>>>
>>>>
>>>>> You have said many times that bugs cannot be closed until the full
>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>
>>>> We are talking about opening bugs here, not closing them.
>>>>
>>>> The invitation still stands for you/Peter to talk to me (offlist) about
>>>> some delegation of bug resolution. There is already delegation
>>>> for creating bugs and setting their initial priority as the creator
>>>> sees fit. I was hoping to see more of that happening.
>>>>
>>>>
>>>>>> So I would say go ahead and log please, but not until you are
>>>>>> able to add steps.
>>>>>
>>>>> We may not immediately have time to fully analyse the problem and work
>>>>> out steps to fully characterise the problem, and that delay before
>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>> all
>>>>
>>>> As I said, you should log immediately for P1/P2 close to release.
>>>>
>>>> There are indeed some bugs I have not put on Bugzilla yet
>>>> because they are complex to characterise, with multi-faceted
>>>> Steps to Reproduce. However I am also confident that if I
>>>> put them on Bugzilla with a one line description, a developer
>>>> would not have enough information to do anything about them.
>>>>
>>>> In the case of this bug 1633, it took me about five minutes to
>>>> test enough that would have let me write meaningful steps to
>>>> reproduce. Surely we can be pragmatic in a case like that,
>>>> and post when we can make a good report?
>>>>
>>>>
>>>> Gale
>>>>
>>>>> but I accept that it's your decision.
>>>>
>>>>
>>>>>
>>>>> Steve
>>>>>
>>>>>> The only exception might be a P2/P1 that
>>>>>> was found close to release. In that case the RM needs to
>>>>>> know ASAP and there should be no shortage of willing hands
>>>>>> to fill in the blanks.
>>>>>>
>>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>>> tracker when you have completed testing.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>>>> See, it's even caught you out now. :=)
>>>>>>>>
>>>>>>>>
>>>>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>>>>> The issue was not described there either. The email is saying that VI users
>>>>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they can.
>>>>>>>>>
>>>>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>>>>> unintuitive for VI users?
>>>>>>>>
>>>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>>>
>>>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>>>> unique value for the position. That would be consistent.
>>>>>>>>
>>>>>>>>
>>>>>>>> Gale
>>>>>>>>
>>>>>>>>
>>>>>>>>> --James.
>>>>>>>>>
>>>>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>>>>>
>>>>>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>>>>>
>>>>>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>>>>>> truncation, just as when you select in a 38 hour track using samples format,
>>>>>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>>>>>> values.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gale
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>>>>>> Steve wrote in:
>>>>>>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>>>>>>
>>>>>>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>>>>>>> an exceptional case for audio)".
>>>>>>>>>>>>
>>>>>>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>>>>>>> 100 000 Hz.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>>>>>>> reasonable.
>>>>>>>>>>>>
>>>>>>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> 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
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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

------------------------------------------------------------------------------
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: Accessibility of Spectral Selection Toolbar at high frequencies

Gale
Administrator
In reply to this post by James Crook
On 17 April 2017 at 21:13, James Crook <[hidden email]> wrote:

> On 4/17/2017 8:50 PM, Gale Andrews wrote:
>> On 17 April 2017 at 19:14, James Crook <[hidden email]> wrote:
>>> On 4/17/2017 5:44 PM, Gale Andrews wrote:
>>>> On a general point, for a commit like:
>>>> https://github.com/audacity/audacity/commit/80928b
>>>>
>>>> where the string is a TimeText control, will we ever be able to
>>>> handle the decimal separator automatically as effects do,
>>>> so that we simply don't need to present a TimeText string?
>>> I'll answer a related question, which is that changes to the time text
>>> strings can be made more impervious to translator omissions.
>>>
>>> As long as we include 'h', 'm', 's', 'sample' and such in the time text
>>> string we have to send the strings for translation, since we can't know
>>> what to do for every single language ourselves.  The switch between .
>>> and , could be handled by code if nothing else had to be done to these
>>> strings.
>> OK, so this would work for Hz and kHz but not for all units.
>>
>> But is it not then possible to use some untranslated placeholder
>> in the TimeText code, and point that placeholder to the word
>> for the translated unit which is a string on its own?
>
> We can do a bit better than that and add some logic that tests that the
> translated format string is 'reasonable'.   If it does not have enough
> digits at the start, then we can fix that, by insertion, or by falling
> back to the untranslated string.  That way a 'fuzzy' translation (to the
> old translated string) WILL work correctly.
>
> We are better off giving the translator more context rather than
> atomizing the translation.  If we break it up too much, they don't have
> enough context to work with.

Yes that's a good point. Though i18n hints could add some context
back.


Gale


> Consider also that some languages might
> put the units before the number rather than after.
>
> --James.
>
>
> ------------------------------------------------------------------------------
> 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: Accessibility of Spectral Selection Toolbar at high frequencies

Peter Sampson-2
James wrote:
>A strong case can be made for closing bugs where the presenting symptoms
>are fixed, and opening new ones for new but related issues.  The
>alternative can work too, but risks very long bug trails and unhappy
>testers/fixers.  I think our testers/fixers are a bit unhappy, but long
>bug trails aren't the sole cause.

A masterpiece of understatement.

What bug-fix devs want is for testers to test their fixes as soon as possible - and what
the testers want is for their tested bugs, especially those that pass the original
symptoms, to be closed/resolved as soon as possible.

I can find bugs in Bugzilla that Paul "fixed" early last year in his bug-purge and I tested in
February/March 2016 on both PC and Mac platforms and also tested by Steve on Linux that
are still left "open" as "Devel fix-made" on Bugzilla.This is really not good enough for either
bug-fix developers or testers.

I happen to believe in "testing around" - but I also believe (as an ex commercial Development
Manager) that if a fixed bug passes its "steps to reproduce" then that bug itself is fixed and
should be closed off.  If other "testing around" issues are observed then these need to be
logged as a separate bug (as James hints) with a link back to the original bug report  (Bugzilla
is fine at handling that).

a) This helps mitigate the issue of overlong Bugzilla threads which are not really helpful for
developers or QA testers.

b) It matters not if that puts the bug-count up - the bug-count is the bug-count.  And the way to
reduce the bug-count is to fix quickly, test quickly and close quickly.  What matters more is the
severity of the outstanding bugs - the P1s to P3s.

But the upshot of all this is, as James hints in his understated way,:
> I think our testers/fixers are a bit unhappy ...

Certainly my motivation as a QA tester of Bugzilla-ed bugs is at an all-time low - and I infer from
this thread and the other parallel thread that Steve is of a similar mind. 

I'm still keen on QAing the big changes like say James' new themes and menu layouts - but
monitoring the commit log for bug-fixes and testing them is largely passing me by.


Gale wrote:
>I appreciate you (and Peter) actually want more general powers to
>resolve bugs, but I think you will have to start that dialogue with
>me and see where it takes us.

I think you'll find that particular ship has sailed Gale.

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: Accessibility of Spectral Selection Toolbar at high frequencies

Vaughan Johnson-4
In reply to this post by Gale
On Mon, Apr 17, 2017 at 11:00 AM, Gale Andrews <[hidden email]> wrote:

> On 17 April 2017 at 17:07, Steve the Fiddle <[hidden email]> wrote:
>> On 17 April 2017 at 16:53, Gale Andrews <[hidden email]> wrote:
>>> On 17 April 2017 at 11:49, Steve the Fiddle <[hidden email]> wrote:
>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]> wrote:
>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>>
>>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>>> helping out by writing a bug report when they see a user report or
>>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>
>>>>>> When I logged the bug, I had no more information than you.
>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>
>>>>> User information often isn't correct. If we can't reproduce what
>>>>> they say I think it's better to write steps for what we can
>>>>> reproduce, then refer to the user's discrepant account in the
>>>>> description.
>>>>>
>>>>>
>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>> you.
>>>>>
>>>>> That isn't very efficient, and it is something that can be delegated
>>>>> to everyone with Bugzilla access.
>>>>
>>>> I'm a "volunteer" not an employee.
>>>
>>> None of us are commercially salaried employees.
>>
>> Well you would be closest to that description, but that's not my point.
>> My point is that you have no authority to tell me what to do. You may
>> of course say what you believe needs to be done, and hopefully one of
>> the volunteers will feel sufficiently motivated to rise to the task.
>
> I have said things like "please" and that it would help me for others
> to create bugs (with Steps to Reproduce).
>
> I feel that asking people to log bugs with essential information is a
> reasonable thing for someone who manages Bugzilla to ask.
>
> As always, if you believe that Team no longer mandates me to manage
> Bugzilla, you need to call a vote on that. I had that explicit mandate
> when I was the only QA'er.

Please move any further discussion about powers/authority/title to team@.

Thanks,
Vaughan



>
> Alternatively you may wait and see if an RM makes the same request
> of you that I do and then argue your case against with him.
>
> Basically though if you are not willing to enter bugs with Steps to
> Reproduce, then for the reasons I gave, I think that makes it more
> difficult for everyone. Fortunately you are the only one so far who
> consistently doesn't add steps to reproduce. Thanks to those who do.
>
>
>
> Gale
>
>
> .
>
>>>>> However a bug report with no steps to reproduce and a partial
>>>>> description might be no better than one with wrong information,
>>>>> as we saw today. If the person reading it has not seen the user
>>>>> report that generated it, or comes to it a long time after the
>>>>> report, lack of steps can be a serious drawback.
>>>>
>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>> That looks pretty clear to me that there's one or more problems in the
>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>
>>> James.was the one who complained it was not clear.
>>>
>>> What happens if we get more testers working on Bugzilla?
>>> They could find it even harder with no steps to reproduce.
>>>
>>>
>>>> You have said many times that bugs cannot be closed until the full
>>>> scope of the bug has been investigated, in fact, that was a reason
>>>> that you gave for not allowing Peter or myself to close bugs.
>>>
>>> We are talking about opening bugs here, not closing them.
>>>
>>> The invitation still stands for you/Peter to talk to me (offlist) about
>>> some delegation of bug resolution. There is already delegation
>>> for creating bugs and setting their initial priority as the creator
>>> sees fit. I was hoping to see more of that happening.
>>>
>>>
>>>>> So I would say go ahead and log please, but not until you are
>>>>> able to add steps.
>>>>
>>>> We may not immediately have time to fully analyse the problem and work
>>>> out steps to fully characterise the problem, and that delay before
>>>> logging the bug may increase the likelihood of it not being logged at
>>>> all
>>>
>>> As I said, you should log immediately for P1/P2 close to release.
>>>
>>> There are indeed some bugs I have not put on Bugzilla yet
>>> because they are complex to characterise, with multi-faceted
>>> Steps to Reproduce. However I am also confident that if I
>>> put them on Bugzilla with a one line description, a developer
>>> would not have enough information to do anything about them.
>>>
>>> In the case of this bug 1633, it took me about five minutes to
>>> test enough that would have let me write meaningful steps to
>>> reproduce. Surely we can be pragmatic in a case like that,
>>> and post when we can make a good report?
>>>
>>>
>>> Gale
>>>
>>>> but I accept that it's your decision.
>>>
>>>
>>>>
>>>> Steve
>>>>
>>>>> The only exception might be a P2/P1 that
>>>>> was found close to release. In that case the RM needs to
>>>>> know ASAP and there should be no shortage of willing hands
>>>>> to fill in the blanks.
>>>>>
>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>> tracker when you have completed testing.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>>>> See, it's even caught you out now. :=)
>>>>>>>
>>>>>>>
>>>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>>>> The issue was not described there either. The email is saying that VI users
>>>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they can.
>>>>>>>>
>>>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>>>> unintuitive for VI users?
>>>>>>>
>>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>>
>>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>>> unique value for the position. That would be consistent.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>>> --James.
>>>>>>>>
>>>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>>>>
>>>>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>>>>
>>>>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>>>>> truncation, just as when you select in a 38 hour track using samples format,
>>>>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>>>>> values.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gale
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>>>>> Steve wrote in:
>>>>>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>>>>>
>>>>>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>>>>>> an exceptional case for audio)".
>>>>>>>>>>>
>>>>>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>>>>>> 100 000 Hz.
>>>>>>>>>>>
>>>>>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>>>>>> reasonable.
>>>>>>>>>>>
>>>>>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> 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: Accessibility of Spectral Selection Toolbar at high frequencies

Vaughan Johnson-4
In reply to this post by Gale
On Mon, Apr 17, 2017 at 8:53 AM, Gale Andrews <[hidden email]> wrote:

> On 17 April 2017 at 11:49, Steve the Fiddle <[hidden email]> wrote:
>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]> wrote:
>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>
>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>> helping out by writing a bug report when they see a user report or
>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>
>>>> When I logged the bug, I had no more information than you.
>>>> I didn't include all of the detail reported by the person that wrote
>>>> in to feedback@ because it did not appear to be correct, and in my
>>>> opinion, incorrect information is worse than incomplete information.
>>>
>>> User information often isn't correct. If we can't reproduce what
>>> they say I think it's better to write steps for what we can
>>> reproduce, then refer to the user's discrepant account in the
>>> description.
>>>
>>>
>>>> If you prefer that I don't log bugs until I have time to work out the
>>>> full scope of the issue, including detailed steps to reproduce, then
>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>> you.
>>>
>>> That isn't very efficient, and it is something that can be delegated
>>> to everyone with Bugzilla access.
>>
>> I'm a "volunteer" not an employee.
>
> None of us are commercially salaried employees.
>
>
>>> However a bug report with no steps to reproduce and a partial
>>> description might be no better than one with wrong information,
>>> as we saw today. If the person reading it has not seen the user
>>> report that generated it, or comes to it a long time after the
>>> report, lack of steps can be a serious drawback.
>>
>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>> That looks pretty clear to me that there's one or more problems in the
>> Spectral Selection Toolbar for frequencies above 100 kHz.
>
> James.was the one who complained it was not clear.
>
> What happens if we get more testers working on Bugzilla?
> They could find it even harder with no steps to reproduce.
>
>
>> You have said many times that bugs cannot be closed until the full
>> scope of the bug has been investigated, in fact, that was a reason
>> that you gave for not allowing Peter or myself to close bugs.
>
> We are talking about opening bugs here, not closing them.

I think the thread has clearly branched to both, as threads often
branch. Both are relevant to the whole who/when/why set of questions.

-- V


>
> The invitation still stands for you/Peter to talk to me (offlist) about
> some delegation of bug resolution. There is already delegation
> for creating bugs and setting their initial priority as the creator
> sees fit. I was hoping to see more of that happening.
>
>
>>> So I would say go ahead and log please, but not until you are
>>> able to add steps.
>>
>> We may not immediately have time to fully analyse the problem and work
>> out steps to fully characterise the problem, and that delay before
>> logging the bug may increase the likelihood of it not being logged at
>> all
>
> As I said, you should log immediately for P1/P2 close to release.
>
> There are indeed some bugs I have not put on Bugzilla yet
> because they are complex to characterise, with multi-faceted
> Steps to Reproduce. However I am also confident that if I
> put them on Bugzilla with a one line description, a developer
> would not have enough information to do anything about them.
>
> In the case of this bug 1633, it took me about five minutes to
> test enough that would have let me write meaningful steps to
> reproduce. Surely we can be pragmatic in a case like that,
> and post when we can make a good report?
>
>
> Gale
>
>> but I accept that it's your decision.
>
>
>>
>> Steve
>>
>>> The only exception might be a P2/P1 that
>>> was found close to release. In that case the RM needs to
>>> know ASAP and there should be no shortage of willing hands
>>> to fill in the blanks.
>>>
>>> For bugs that are not time sensitive, perhaps you could say to
>>> feedback@ as I sometimes do, that you will add it to the bug
>>> tracker when you have completed testing.
>>>
>>>
>>> Thanks
>>>
>>>
>>> Gale
>>>
>>>
>>>>> See, it's even caught you out now. :=)
>>>>>
>>>>>
>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>> The issue was not described there either. The email is saying that VI users
>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they can.
>>>>>>
>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>> unintuitive for VI users?
>>>>>
>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>> 120 000 Hz to 180 000 Hz?
>>>>>
>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>> behave as Selection Toolbar does when the format can't show a
>>>>> unique value for the position. That would be consistent.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>>> --James.
>>>>>>
>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>>
>>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>>
>>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>>> truncation, just as when you select in a 38 hour track using samples format,
>>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>>> values.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>>> Steve wrote in:
>>>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>>>
>>>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>>>> an exceptional case for audio)".
>>>>>>>>>
>>>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>>>> 100 000 Hz.
>>>>>>>>>
>>>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>>>> reasonable.
>>>>>>>>>
>>>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>
> ------------------------------------------------------------------------------
> 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: Accessibility of Spectral Selection Toolbar at high frequencies

Vaughan Johnson-4
In reply to this post by Gale
On Mon, Apr 17, 2017 at 9:32 AM, Gale Andrews <[hidden email]> wrote:

> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>
>>
>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>
>>> Where I am coming from on this is only indirectly about practicalities and
>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>> visibly see a bug progressing towards closure.
>>>
>>> My first commit, I hoped, was enough to close the bug:
>>>
>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>
>>> However, I'd certainly agree the bug title is sufficiently general that it
>>> does cover more, and the bug, that I was not aware of, of max copying from
>>> min fits under that title too.  I think my real issue was that I didn't get
>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>> less important than the original (minor) issue arrived.  My peve about the
>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>> the bug.
>>>
>>> My second commit fixes that residual issue too:
>>>
>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>
>>> However, I am expecting not to get the satisfaction of seeing the bug
>>> close from that either.  I gave the reasons in a previous email.  There are
>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>> frequency display rather than showing '------' for invalid/out-of-range is
>>> wrong too.
>>>
>>> So basically the experience of working on bugs is unsatisfying.  I would
>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>
>>> I added a new bug about Spectral Selection Toolbar in German.
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>
>>> Maybe this new bug will be enough to allow us to close 1633.
>>>
>>>
>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>> Even though there appear to be two bugs in 1634, I think the experience of
>>> working on 1634 might be more satisfying than 1633, as there is a real
>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>> and define what the bug is, rather than the title doing so.  I think if the
>>> steps to reproduce are updated significantly to cover other similar issues,
>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>> Then someone reading the comment trail knows that essentially a new or
>>> residual issue is being worked on now, and earlier bug trail is not as
>>> important as it was originally, and indeed the original bug may have been
>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>> bug fixer.
>>>
>>> Again this is not so much about practicalities as about how it feels to
>>> fix the bugs.
>>
>>
>> It's also about how it feels to test fixed bugs and then not see them close.
>>
>> But as we know, even if there are clear Steps To Reproduce and testing
>> passes those - Gale will
>> usually insist on "testing around" and not just relying on steps-passing to
>> close the bug, and that
>> can take a lot of time.
>
> James has consistently backed me on testing to see if the fix
> breaks other things, and if seems appropriate, testing more than
> the steps to reproduce.

James encouraged your work, Gale, as have I, and still do, as I hope
you understand. You have done great contribution for years, and I hope
that will continue.

Thanks,
Vaughan



>
> If other testers indicated that they had done that in the bug comments,
> rather than testing the steps and giving up, then there might be
> fewer obstacles to delegating closure rights.
>
> And if only the steps are tested, that puts even more importance on
> the steps not only being accurate, but including all the symptoms
> that can be reproduced.
>
>
> Gale
>
>
>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>
>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>> wrote:
>>>
>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>
>>> Gale, that issue was not in the steps to reproduce
>>>
>>> Well, isn't that the very point I have been making? I appreciate others
>>> helping out by writing a bug report when they see a user report or
>>> when a bug is confirmed on a list, but *everyone* should write proper
>>> steps to reproduce (in the Steps to Reproduce) box.
>>>
>>> When I logged the bug, I had no more information than you.
>>> I didn't include all of the detail reported by the person that wrote
>>> in to feedback@ because it did not appear to be correct, and in my
>>> opinion, incorrect information is worse than incomplete information.
>>>
>>> User information often isn't correct. If we can't reproduce what
>>> they say I think it's better to write steps for what we can
>>> reproduce, then refer to the user's discrepant account in the
>>> description.
>>>
>>>
>>> If you prefer that I don't log bugs until I have time to work out the
>>> full scope of the issue, including detailed steps to reproduce, then
>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>> you.
>>>
>>> That isn't very efficient, and it is something that can be delegated
>>> to everyone with Bugzilla access.
>>>
>>> I'm a "volunteer" not an employee.
>>>
>>>
>>> However a bug report with no steps to reproduce and a partial
>>> description might be no better than one with wrong information,
>>> as we saw today. If the person reading it has not seen the user
>>> report that generated it, or comes to it a long time after the
>>> report, lack of steps can be a serious drawback.
>>>
>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>> That looks pretty clear to me that there's one or more problems in the
>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>
>>> You have said many times that bugs cannot be closed until the full
>>> scope of the bug has been investigated, in fact, that was a reason
>>> that you gave for not allowing Peter or myself to close bugs.
>>>
>>>
>>> So I would say go ahead and log please, but not until you are
>>> able to add steps.
>>>
>>> We may not immediately have time to fully analyse the problem and work
>>> out steps to fully characterise the problem, and that delay before
>>> logging the bug may increase the likelihood of it not being logged at
>>> all,  but I accept that it's your decision.
>>>
>>> Steve
>>>
>>> The only exception might be a P2/P1 that
>>> was found close to release. In that case the RM needs to
>>> know ASAP and there should be no shortage of willing hands
>>> to fill in the blanks.
>>>
>>> For bugs that are not time sensitive, perhaps you could say to
>>> feedback@ as I sometimes do, that you will add it to the bug
>>> tracker when you have completed testing.
>>>
>>>
>>> Thanks
>>>
>>>
>>> Gale
>>>
>>>
>>> See, it's even caught you out now. :=)
>>>
>>>
>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>> The issue was not described there either. The email is saying that VI
>>> users
>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>> can.
>>>
>>> I only tested with KHz (and MHz).  The bug you report here has a
>>> different cause.  One possible fix is to make the number of digits in
>>> the Hz display variable, rather than truncate, but that might prove
>>> unintuitive for VI users?
>>>
>>> Can you say then how we would display in Hz, a spectral selection of
>>> 120 000 Hz to 180 000 Hz?
>>>
>>> I can't discuss what technically could be done, but I think it "should"
>>> behave as Selection Toolbar does when the format can't show a
>>> unique value for the position. That would be consistent.
>>>
>>>
>>> Gale
>>>
>>>
>>> --James.
>>>
>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>
>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>
>>> So that our VI users who work with bat and/or porpoise sounds are not
>>> inconvenienced, I have addressed this issue with following commit:
>>>
>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>
>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>> I don't see that I could resolve the bug just with that.
>>>
>>> In Hz format, the display of High Frequency remains incorrect above
>>> 100 000 Hz. It's the same as Low Frequency.
>>>
>>> Surely it should show the correct High and Low frequencies with leading
>>> truncation, just as when you select in a 38 hour track using samples
>>> format,
>>> Selection Start and End in Selection Toolbar show different but truncated
>>> values.
>>>
>>>
>>> Gale
>>>
>>>
>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>
>>> Steve wrote in:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>
>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>> an exceptional case for audio)".
>>>
>>> For display I might agree, but this does mean that Spectral Selection
>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>> there is no way for VI users to create spectral selections above
>>> 100 000 Hz.
>>>
>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>> we compare the case of long audio (say 48 hours) VI users can use
>>> Selection Toolbar to create selections or move the cursor because
>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>> format because the leading values are truncated, which I agree is
>>> reasonable.
>>>
>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>> (still only P4) unless there is a technical reason why not.
>>>
>>>
>>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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: Accessibility of Spectral Selection Toolbar at high frequencies

Vaughan Johnson-4
In reply to this post by Gale
-1 to nonstandard terms like KTT and experimental/auteur and any
proliferation of terms with ultra-fine distinctions from "beta".

If we return to releasing betas, as we did years ago -- and now in
parallel -- I think that's great.

- Vaughan

On Mon, Apr 17, 2017 at 12:43 PM, Gale Andrews <[hidden email]> wrote:

> We don't know Audacity will get a lot of use before freeze.
>
> A lot of store was set on mid-term (KTT) and experimental
> (auteur) releases, but we are not yet enlarging the market
> for people who may test those. Until we do, it will still be
> mainly "us" who test.
>
>
> Gale
>
>
> On 17 April 2017 at 19:08, James Crook <[hidden email]> wrote:
>> On 4/17/2017 5:32 PM, Gale Andrews wrote:
>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>
>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>> visibly see a bug progressing towards closure.
>>>>>
>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>
>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>> the bug.
>>>>>
>>>>> My second commit fixes that residual issue too:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>
>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>> wrong too.
>>>>>
>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>
>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>
>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>
>>>>>
>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>> important as it was originally, and indeed the original bug may have been
>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>> bug fixer.
>>>>>
>>>>> Again this is not so much about practicalities as about how it feels to
>>>>> fix the bugs.
>>>>
>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>
>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>> passes those - Gale will
>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>> close the bug, and that
>>>> can take a lot of time.
>>> James has consistently backed me on testing to see if the fix
>>> breaks other things, and if seems appropriate, testing more than
>>> the steps to reproduce.
>> Testing around, especially of P1s P2s, is essential when we are getting
>> close to release, e.g. after freeze.
>> A case can be made for being more relaxed about it earlier in release
>> cycle - especially if we know Audacity is going to get a lot of use
>> before freeze.
>>
>> A strong case can be made for closing bugs where the presenting symptoms
>> are fixed, and opening new ones for new but related issues.  The
>> alternative can work too, but risks very long bug trails and unhappy
>> testers/fixers.  I think our testers/fixers are a bit unhappy, but long
>> bug trails aren't the sole cause.
>>
>>
>>>
>>> If other testers indicated that they had done that in the bug comments,
>>> rather than testing the steps and giving up, then there might be
>>> fewer obstacles to delegating closure rights.
>>>
>>> And if only the steps are tested, that puts even more importance on
>>> the steps not only being accurate, but including all the symptoms
>>> that can be reproduced.
>>>
>>>
>>> Gale
>>>
>>>
>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>
>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>
>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>
>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>
>>>>> Gale, that issue was not in the steps to reproduce
>>>>>
>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>> helping out by writing a bug report when they see a user report or
>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>
>>>>> When I logged the bug, I had no more information than you.
>>>>> I didn't include all of the detail reported by the person that wrote
>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>
>>>>> User information often isn't correct. If we can't reproduce what
>>>>> they say I think it's better to write steps for what we can
>>>>> reproduce, then refer to the user's discrepant account in the
>>>>> description.
>>>>>
>>>>>
>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>> you.
>>>>>
>>>>> That isn't very efficient, and it is something that can be delegated
>>>>> to everyone with Bugzilla access.
>>>>>
>>>>> I'm a "volunteer" not an employee.
>>>>>
>>>>>
>>>>> However a bug report with no steps to reproduce and a partial
>>>>> description might be no better than one with wrong information,
>>>>> as we saw today. If the person reading it has not seen the user
>>>>> report that generated it, or comes to it a long time after the
>>>>> report, lack of steps can be a serious drawback.
>>>>>
>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>
>>>>> You have said many times that bugs cannot be closed until the full
>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>
>>>>>
>>>>> So I would say go ahead and log please, but not until you are
>>>>> able to add steps.
>>>>>
>>>>> We may not immediately have time to fully analyse the problem and work
>>>>> out steps to fully characterise the problem, and that delay before
>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>> all,  but I accept that it's your decision.
>>>>>
>>>>> Steve
>>>>>
>>>>> The only exception might be a P2/P1 that
>>>>> was found close to release. In that case the RM needs to
>>>>> know ASAP and there should be no shortage of willing hands
>>>>> to fill in the blanks.
>>>>>
>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>> tracker when you have completed testing.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> See, it's even caught you out now. :=)
>>>>>
>>>>>
>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>> The issue was not described there either. The email is saying that VI
>>>>> users
>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>> can.
>>>>>
>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>> different cause.  One possible fix is to make the number of digits in
>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>> unintuitive for VI users?
>>>>>
>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>> 120 000 Hz to 180 000 Hz?
>>>>>
>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>> behave as Selection Toolbar does when the format can't show a
>>>>> unique value for the position. That would be consistent.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> --James.
>>>>>
>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>
>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>
>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>
>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>> I don't see that I could resolve the bug just with that.
>>>>>
>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>
>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>> format,
>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>> values.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>
>>>>> Steve wrote in:
>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>
>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>> an exceptional case for audio)".
>>>>>
>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>> there is no way for VI users to create spectral selections above
>>>>> 100 000 Hz.
>>>>>
>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>> Selection Toolbar to create selections or move the cursor because
>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>> format because the leading values are truncated, which I agree is
>>>>> reasonable.
>>>>>
>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>> (still only P4) unless there is a technical reason why not.
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>
> ------------------------------------------------------------------------------
> 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: Accessibility of Spectral Selection Toolbar at high frequencies

Vaughan Johnson-4
In reply to this post by Peter Sampson-2
On Mon, Apr 17, 2017 at 3:38 PM, Peter Sampson
<[hidden email]> wrote:
> James wrote:
>>A strong case can be made for closing bugs where the presenting symptoms
>>are fixed, and opening new ones for new but related issues.  The
>>alternative can work too, but risks very long bug trails and unhappy
>>testers/fixers.  I think our testers/fixers are a bit unhappy, but long
>>bug trails aren't the sole cause.
>
> A masterpiece of understatement.

:)


>
> What bug-fix devs want is for testers to test their fixes as soon as
> possible - and what
> the testers want is for their tested bugs, especially those that pass the
> original
> symptoms, to be closed/resolved as soon as possible.
>
> I can find bugs in Bugzilla that Paul "fixed" early last year in his
> bug-purge and I tested in
> February/March 2016 on both PC and Mac platforms and also tested by Steve on
> Linux that
> are still left "open" as "Devel fix-made" on Bugzilla.This is really not
> good enough for either
> bug-fix developers or testers.
>
> I happen to believe in "testing around" - but I also believe (as an ex
> commercial Development
> Manager) that if a fixed bug passes its "steps to reproduce" then that bug
> itself is fixed and
> should be closed off.  If other "testing around" issues are observed then
> these need to be
> logged as a separate bug (as James hints) with a link back to the original
> bug report  (Bugzilla
> is fine at handling that).
>
> a) This helps mitigate the issue of overlong Bugzilla threads which are not
> really helpful for
> developers or QA testers.
>
> b) It matters not if that puts the bug-count up - the bug-count is the
> bug-count.

Thanks. Yes, I've said that many times.

Some seem to think high bug count is an embarrassment. But if it's
accurate, let's face reality.  And if 80% are low-priority, that's
doing well. Sure, ideally, we would have *no* bugs, but that's not
realistic.  High bug count means that at least we're tracking
minutiae.



>And the way to
> reduce the bug-count is to fix quickly, test quickly and close quickly.
> What matters more is the
> severity of the outstanding bugs - the P1s to P3s.

+1


>
> But the upshot of all this is, as James hints in his understated way,:
>> I think our testers/fixers are a bit unhappy ...
>
> Certainly my motivation as a QA tester of Bugzilla-ed bugs is at an all-time
> low - and I infer from
> this thread and the other parallel thread that Steve is of a similar mind.

Yes, let's please work to *fix* that!


>
> I'm still keen on QAing the big changes like say James' new themes and menu
> layouts - but
> monitoring the commit log for bug-fixes and testing them is largely passing
> me by.

:(


>
>
> Gale wrote:
>>I appreciate you (and Peter) actually want more general powers to
>>resolve bugs, but I think you will have to start that dialogue with
>>me and see where it takes us.
>
> I think you'll find that particular ship has sailed Gale.

Yes, we have had this dialog already, a few times. So let's resolve it, please.

Thanks for your work, Gale, Steve, and Peter. !!!

- V


>
> 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

Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

James Crook
In reply to this post by Vaughan Johnson-4
I think it is fine/good that we distinguish public betas (which have not
been through a full QA process) from releases (which have).

I am fine with phasing out KTT as a term.  At the moment only we know
what KTT means.  'kicking the tyres' is neither a good nor reliable
practice for evaluating a car, motorbike or bicycle.

If we have more than one beta at a time we will need a clear way to
distinguish the different purposes of those betas.  Gale has made that
point off list, and I agree.  I think if we plan to have a mid term
beta, then we need to have a name for it.  If we plan to have an
experimental beta too then we need a name/designation for it.

--James.





On 4/18/2017 4:35 AM, Vaughan Johnson wrote:
> -1 to nonstandard terms like KTT and experimental/auteur and any
> proliferation of terms with ultra-fine distinctions from "beta".
>
> If we return to releasing betas, as we did years ago -- and now in
> parallel -- I think that's great.
>
> - Vaughan


------------------------------------------------------------------------------
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: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Stevethefiddle
On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
> I think it is fine/good that we distinguish public betas (which have not
> been through a full QA process) from releases (which have).
>
> I am fine with phasing out KTT as a term.  At the moment only we know
> what KTT means.  'kicking the tyres' is neither a good nor reliable
> practice for evaluating a car, motorbike or bicycle.

Very true. More like an MOT would be better :-)

Steve

>
> If we have more than one beta at a time we will need a clear way to
> distinguish the different purposes of those betas.  Gale has made that
> point off list, and I agree.  I think if we plan to have a mid term
> beta, then we need to have a name for it.  If we plan to have an
> experimental beta too then we need a name/designation for it.
>
> --James.
>
>
>
>
>
> On 4/18/2017 4:35 AM, Vaughan Johnson wrote:
>> -1 to nonstandard terms like KTT and experimental/auteur and any
>> proliferation of terms with ultra-fine distinctions from "beta".
>>
>> If we return to releasing betas, as we did years ago -- and now in
>> parallel -- I think that's great.
>>
>> - Vaughan
>
>
> ------------------------------------------------------------------------------
> 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: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

James Crook
On 4/18/2017 10:46 AM, Steve the Fiddle wrote:
> On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
>> I think it is fine/good that we distinguish public betas (which have not
>> been through a full QA process) from releases (which have).
>>
>> I am fine with phasing out KTT as a term.  At the moment only we know
>> what KTT means.  'kicking the tyres' is neither a good nor reliable
>> practice for evaluating a car, motorbike or bicycle.
> Very true. More like an MOT would be better :-)

:-)

And the American 'mot' for MOT is I think is 'smog test'.  So I say
Vaughan's point still stands.   And even if we call it a smog-test-build
people in europe aren't going to know what it is. 'Mid-term-beta' or
'mid-term-build' probably will do - using 'term' rather than 'release
cycle' to be vaguer, since Vaughan has cast doubt on what a 'release
cycle' is too.

Anyway, the right 'mot' for MOT or whatever is all moot, if we don't
actually have one, and whether we have one or not seems a more pressing
question.  One thing that came out of an off-list discussion with Gale
is that we can use the suffix -m for a mid term build and -x for an
experimental/exploratory build.  That could help reduce confusion about
the purpose of each.  -m is expected to go into the upcoming release.  
-x additionally has a developers plans/exploratory-ideas that are
unlikely to be in the upcoming release (preview, of interest to early
adopters, who may want to get involved in helping us refine ideas and
fix issues).

For 2.2.0 I think we will likely have just an -m, with the MIDI_OUT in
it too.  There will be plenty new in the -m for 'early adopters'.  If
MIDI_OUT is looking unlikely for 2.2.0, then it should be in an -x, but
it being in the -m would be far better.

--James.


------------------------------------------------------------------------------
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: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Stevethefiddle
On 18 April 2017 at 12:06, James Crook <[hidden email]> wrote:

> On 4/18/2017 10:46 AM, Steve the Fiddle wrote:
>> On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
>>> I think it is fine/good that we distinguish public betas (which have not
>>> been through a full QA process) from releases (which have).
>>>
>>> I am fine with phasing out KTT as a term.  At the moment only we know
>>> what KTT means.  'kicking the tyres' is neither a good nor reliable
>>> practice for evaluating a car, motorbike or bicycle.
>> Very true. More like an MOT would be better :-)
>
> :-)
>
> And the American 'mot' for MOT is I think is 'smog test'.  So I say
> Vaughan's point still stands.   And even if we call it a smog-test-build
> people in europe aren't going to know what it is. 'Mid-term-beta' or
> 'mid-term-build' probably will do - using 'term' rather than 'release
> cycle' to be vaguer, since Vaughan has cast doubt on what a 'release
> cycle' is too.

In case there's confusion, I didn't mean to suggest that we call it an
"MOT", but that testing of a mid-term beta should be a proper safety
check of critical parts (like an MOT in the UK), rather than "kicking
the tyres".

I'm in agreement with what others have said - if we have a mid-term
beta (and no experimental branch or any other "special" builds), then
simply call it a "beta".

Steve

>
> Anyway, the right 'mot' for MOT or whatever is all moot, if we don't
> actually have one, and whether we have one or not seems a more pressing
> question.  One thing that came out of an off-list discussion with Gale
> is that we can use the suffix -m for a mid term build and -x for an
> experimental/exploratory build.  That could help reduce confusion about
> the purpose of each.  -m is expected to go into the upcoming release.
> -x additionally has a developers plans/exploratory-ideas that are
> unlikely to be in the upcoming release (preview, of interest to early
> adopters, who may want to get involved in helping us refine ideas and
> fix issues).
>
> For 2.2.0 I think we will likely have just an -m, with the MIDI_OUT in
> it too.  There will be plenty new in the -m for 'early adopters'.  If
> MIDI_OUT is looking unlikely for 2.2.0, then it should be in an -x, but
> it being in the -m would be far better.
>
> --James.
>
>
> ------------------------------------------------------------------------------
> 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: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Gale
Administrator
On 18 April 2017 at 12:24, Steve the Fiddle <[hidden email]> wrote:

> On 18 April 2017 at 12:06, James Crook <[hidden email]> wrote:
>> On 4/18/2017 10:46 AM, Steve the Fiddle wrote:
>>> On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
>>>> I think it is fine/good that we distinguish public betas (which have not
>>>> been through a full QA process) from releases (which have).
>>>>
>>>> I am fine with phasing out KTT as a term.  At the moment only we know
>>>> what KTT means.  'kicking the tyres' is neither a good nor reliable
>>>> practice for evaluating a car, motorbike or bicycle.
>>> Very true. More like an MOT would be better :-)
>>
>> :-)
>>
>> And the American 'mot' for MOT is I think is 'smog test'.  So I say
>> Vaughan's point still stands.   And even if we call it a smog-test-build
>> people in europe aren't going to know what it is. 'Mid-term-beta' or
>> 'mid-term-build' probably will do - using 'term' rather than 'release
>> cycle' to be vaguer, since Vaughan has cast doubt on what a 'release
>> cycle' is too.
>
> In case there's confusion, I didn't mean to suggest that we call it an
> "MOT", but that testing of a mid-term beta should be a proper safety
> check of critical parts (like an MOT in the UK), rather than "kicking
> the tyres".
>
> I'm in agreement with what others have said - if we have a mid-term
> beta (and no experimental branch or any other "special" builds), then
> simply call it a "beta".

What if we have both? The mid-term pre-release (calling it
how I think of it) must be called the same in both cases.

To me the user perception of stability of these builds is highly
relevant to the willingness of users to test them. To call them
"beta", we would have to explain the difference between beta
and alpha, to assist those users who state that that the
nightlies are betas.

I would expect the KTT stability to be high, between a release
and what we had in most of the 1.3 series. We want a term
that suggests that.

I like "mid-term build" and "experimental build" myself. There
is a clear distinction in perceived stability between those. Have
I got it right that KTT is pure HEAD?  It would be the same
as an alpha built at the same revision?



Gale


>> Anyway, the right 'mot' for MOT or whatever is all moot, if we don't
>> actually have one, and whether we have one or not seems a more pressing
>> question.  One thing that came out of an off-list discussion with Gale
>> is that we can use the suffix -m for a mid term build and -x for an
>> experimental/exploratory build.  That could help reduce confusion about
>> the purpose of each.  -m is expected to go into the upcoming release.
>> -x additionally has a developers plans/exploratory-ideas that are
>> unlikely to be in the upcoming release (preview, of interest to early
>> adopters, who may want to get involved in helping us refine ideas and
>> fix issues).
>>
>> For 2.2.0 I think we will likely have just an -m, with the MIDI_OUT in
>> it too.  There will be plenty new in the -m for 'early adopters'.  If
>> MIDI_OUT is looking unlikely for 2.2.0, then it should be in an -x, but
>> it being in the -m would be far better.
>>
>> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> 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: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Stevethefiddle
On 18 April 2017 at 18:32, Gale Andrews <[hidden email]> wrote:

> On 18 April 2017 at 12:24, Steve the Fiddle <[hidden email]> wrote:
>> On 18 April 2017 at 12:06, James Crook <[hidden email]> wrote:
>>> On 4/18/2017 10:46 AM, Steve the Fiddle wrote:
>>>> On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
>>>>> I think it is fine/good that we distinguish public betas (which have not
>>>>> been through a full QA process) from releases (which have).
>>>>>
>>>>> I am fine with phasing out KTT as a term.  At the moment only we know
>>>>> what KTT means.  'kicking the tyres' is neither a good nor reliable
>>>>> practice for evaluating a car, motorbike or bicycle.
>>>> Very true. More like an MOT would be better :-)
>>>
>>> :-)
>>>
>>> And the American 'mot' for MOT is I think is 'smog test'.  So I say
>>> Vaughan's point still stands.   And even if we call it a smog-test-build
>>> people in europe aren't going to know what it is. 'Mid-term-beta' or
>>> 'mid-term-build' probably will do - using 'term' rather than 'release
>>> cycle' to be vaguer, since Vaughan has cast doubt on what a 'release
>>> cycle' is too.
>>
>> In case there's confusion, I didn't mean to suggest that we call it an
>> "MOT", but that testing of a mid-term beta should be a proper safety
>> check of critical parts (like an MOT in the UK), rather than "kicking
>> the tyres".
>>
>> I'm in agreement with what others have said - if we have a mid-term
>> beta (and no experimental branch or any other "special" builds), then
>> simply call it a "beta".
>
> What if we have both? The mid-term pre-release (calling it
> how I think of it) must be called the same in both cases.

If we have "experimental builds", in my opinion they should be from an
experimental branch of https://github.com/audacity/audacity
The name will then be obvious, based on the name of the branch.

For example, if we have an experimental MIDI branch at:
https://github.com/audacity/audacity/tree/midi
and we make a beta build from that branch, then the build would be
called something along the lines of:
"Audacity MIDI 2.2.0-beta"

Steve

>
> To me the user perception of stability of these builds is highly
> relevant to the willingness of users to test them. To call them
> "beta", we would have to explain the difference between beta
> and alpha, to assist those users who state that that the
> nightlies are betas.
>
> I would expect the KTT stability to be high, between a release
> and what we had in most of the 1.3 series. We want a term
> that suggests that.
>
> I like "mid-term build" and "experimental build" myself. There
> is a clear distinction in perceived stability between those. Have
> I got it right that KTT is pure HEAD?  It would be the same
> as an alpha built at the same revision?
>
>
>
> Gale
>
>
>>> Anyway, the right 'mot' for MOT or whatever is all moot, if we don't
>>> actually have one, and whether we have one or not seems a more pressing
>>> question.  One thing that came out of an off-list discussion with Gale
>>> is that we can use the suffix -m for a mid term build and -x for an
>>> experimental/exploratory build.  That could help reduce confusion about
>>> the purpose of each.  -m is expected to go into the upcoming release.
>>> -x additionally has a developers plans/exploratory-ideas that are
>>> unlikely to be in the upcoming release (preview, of interest to early
>>> adopters, who may want to get involved in helping us refine ideas and
>>> fix issues).
>>>
>>> For 2.2.0 I think we will likely have just an -m, with the MIDI_OUT in
>>> it too.  There will be plenty new in the -m for 'early adopters'.  If
>>> MIDI_OUT is looking unlikely for 2.2.0, then it should be in an -x, but
>>> it being in the -m would be far better.
>>>
>>> --James.
>>>
>>>
>>> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
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: Accessibility of Spectral Selection Toolbar at high frequencies

Gale
Administrator
In reply to this post by Peter Sampson-2
It's known as priorities. Almost all of the bugs on DEVEL-FIX MADE
are P4 and below, and I see it is that way before a release. It matters
more to add new P2's and P1's, if we have to choose.

If I got more help with tracking and adding new bugs, which help
I have asked for several times, and which clearly matters to Steve,
then I have more time for resolving bug fixes. Even looking for and
triaging the many things that are reported as bugs in vague and
confusing terms, but turn out to be user error, takes considerable
time. Should we ignore those things until we get an understandable
report or we find it ourseleves?

As far as I know Peter does not do any of that "bug detective" type
of activity. Steve sometimes does.

At which end does one start with a log jam? I have been starting
at the current end of DEVEL-FIXED. Check it out.

Please explain the "ship has already sailed" comment.


Gale


On 17 April 2017 at 23:38, Peter Sampson <[hidden email]> wrote:

> James wrote:
>>A strong case can be made for closing bugs where the presenting symptoms
>>are fixed, and opening new ones for new but related issues.  The
>>alternative can work too, but risks very long bug trails and unhappy
>>testers/fixers.  I think our testers/fixers are a bit unhappy, but long
>>bug trails aren't the sole cause.
>
> A masterpiece of understatement.
>
> What bug-fix devs want is for testers to test their fixes as soon as
> possible - and what
> the testers want is for their tested bugs, especially those that pass the
> original
> symptoms, to be closed/resolved as soon as possible.
>
> I can find bugs in Bugzilla that Paul "fixed" early last year in his
> bug-purge and I tested in
> February/March 2016 on both PC and Mac platforms and also tested by Steve on
> Linux that
> are still left "open" as "Devel fix-made" on Bugzilla.This is really not
> good enough for either
> bug-fix developers or testers.
>
> I happen to believe in "testing around" - but I also believe (as an ex
> commercial Development
> Manager) that if a fixed bug passes its "steps to reproduce" then that bug
> itself is fixed and
> should be closed off.  If other "testing around" issues are observed then
> these need to be
> logged as a separate bug (as James hints) with a link back to the original
> bug report  (Bugzilla
> is fine at handling that).
>
> a) This helps mitigate the issue of overlong Bugzilla threads which are not
> really helpful for
> developers or QA testers.
>
> b) It matters not if that puts the bug-count up - the bug-count is the
> bug-count.  And the way to
> reduce the bug-count is to fix quickly, test quickly and close quickly.
> What matters more is the
> severity of the outstanding bugs - the P1s to P3s.
>
> But the upshot of all this is, as James hints in his understated way,:
>> I think our testers/fixers are a bit unhappy ...
>
> Certainly my motivation as a QA tester of Bugzilla-ed bugs is at an all-time
> low - and I infer from
> this thread and the other parallel thread that Steve is of a similar mind.
>
> I'm still keen on QAing the big changes like say James' new themes and menu
> layouts - but
> monitoring the commit log for bug-fixes and testing them is largely passing
> me by.
>
>
> Gale wrote:
>>I appreciate you (and Peter) actually want more general powers to
>>resolve bugs, but I think you will have to start that dialogue with
>>me and see where it takes us.
>
> I think you'll find that particular ship has sailed Gale.
>
> 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: Accessibility of Spectral Selection Toolbar at high frequencies

Gale
Administrator
In reply to this post by Vaughan Johnson-4
On 18 April 2017 at 04:46, Vaughan Johnson <[hidden email]> wrote:

> On Mon, Apr 17, 2017 at 3:38 PM, Peter Sampson
> <[hidden email]> wrote:
>> James wrote:
>>>A strong case can be made for closing bugs where the presenting symptoms
>>>are fixed, and opening new ones for new but related issues.  The
>>>alternative can work too, but risks very long bug trails and unhappy
>>>testers/fixers.  I think our testers/fixers are a bit unhappy, but long
>>>bug trails aren't the sole cause.
>>
>> A masterpiece of understatement.
>
> :)
>
>
>>
>> What bug-fix devs want is for testers to test their fixes as soon as
>> possible - and what
>> the testers want is for their tested bugs, especially those that pass the
>> original
>> symptoms, to be closed/resolved as soon as possible.
>>
>> I can find bugs in Bugzilla that Paul "fixed" early last year in his
>> bug-purge and I tested in
>> February/March 2016 on both PC and Mac platforms and also tested by Steve on
>> Linux that
>> are still left "open" as "Devel fix-made" on Bugzilla.This is really not
>> good enough for either
>> bug-fix developers or testers.
>>
>> I happen to believe in "testing around" - but I also believe (as an ex
>> commercial Development
>> Manager) that if a fixed bug passes its "steps to reproduce" then that bug
>> itself is fixed and
>> should be closed off.  If other "testing around" issues are observed then
>> these need to be
>> logged as a separate bug (as James hints) with a link back to the original
>> bug report  (Bugzilla
>> is fine at handling that).
>>
>> a) This helps mitigate the issue of overlong Bugzilla threads which are not
>> really helpful for
>> developers or QA testers.
>>
>> b) It matters not if that puts the bug-count up - the bug-count is the
>> bug-count.
>
> Thanks. Yes, I've said that many times.
>
> Some seem to think high bug count is an embarrassment. But if it's
> accurate, let's face reality.  And if 80% are low-priority, that's
> doing well. Sure, ideally, we would have *no* bugs, but that's not
> realistic.  High bug count means that at least we're tracking
> minutiae.
>
>
>
>>And the way to
>> reduce the bug-count is to fix quickly, test quickly and close quickly.
>> What matters more is the
>> severity of the outstanding bugs - the P1s to P3s.
>
> +1

Excuse me, but that happens now by and large. See my previous
message.

I think to complain as Peter did that it takes me four days to resolve
a P1 at the start of dev cycle, and where by definition the bug is
important and the fix may have ramifications that the testers have
said they won't test for, is ridiculous.



Gale


>> But the upshot of all this is, as James hints in his understated way,:
>>> I think our testers/fixers are a bit unhappy ...
>>
>> Certainly my motivation as a QA tester of Bugzilla-ed bugs is at an all-time
>> low - and I infer from
>> this thread and the other parallel thread that Steve is of a similar mind.
>
> Yes, let's please work to *fix* that!
>
>
>>
>> I'm still keen on QAing the big changes like say James' new themes and menu
>> layouts - but
>> monitoring the commit log for bug-fixes and testing them is largely passing
>> me by.
>
> :(
>
>
>>
>>
>> Gale wrote:
>>>I appreciate you (and Peter) actually want more general powers to
>>>resolve bugs, but I think you will have to start that dialogue with
>>>me and see where it takes us.
>>
>> I think you'll find that particular ship has sailed Gale.
>
> Yes, we have had this dialog already, a few times. So let's resolve it, please.
>
> Thanks for your work, Gale, Steve, and Peter. !!!
>
> - V
>
>
>>
>> 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
123
Loading...