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

Accessibility of Spectral Selection Toolbar at high frequencies

Gale
Administrator
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

Stevethefiddle
On 16 April 2017 at 17:59, Gale Andrews <[hidden email]> 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.

Plug-ins with a conventional numeric input in the UI are probably more
convenient for VI users. For example, the standard Notch filter rather
than the "spectral effect" equivalent. The only real benefit of the
"Spectral Edit" effects is that it provides a "visual" means of input
rather than numeric.

Steve

>
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

James Crook
In reply to this post by Gale
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

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

Gale
Administrator
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

James Crook
Gale, that issue was not in the steps to reproduce, 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?

--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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

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

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

Steve

>
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

James Crook
In reply to this post by Gale
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
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 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.

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.

So I would say go ahead and log please, but not until you are
able to add steps. 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
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 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

James Crook
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.


--James.


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

Peter Sampson-2


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.

Peter


 


--James.



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

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

Steve

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

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


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

Cliff Scott
In reply to this post by Gale

> On Apr 17, 2017, at 11: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.
>
> 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

I've been following this conversation not wanting to get in the way of the discussion, but wanted just second the opinion that the steps to reproduce are key to testers like myself. Those steps are all I have to go on and any notes of possible side effects is helpful to know were to expand the testing. The more information given the better I can test. I know there has to be a balance in time spent in figuring out and writing all the info down as well, but just wanted to say it helps those of us that are not as acquainted with the insides as some to do the best we can to test.

Cliff

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

Gale
Administrator
In reply to this post by Stevethefiddle
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.



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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

James Crook
In reply to this post by Gale
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessibility of Spectral Selection Toolbar at high frequencies

James Crook
In reply to this post by Gale
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.


>
>
> 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
123
Loading...