(In reply to comment #0)

I've looked into this and know how to fix it. Unfortunately, each generator class was implemented with its own member variable to track its display format, and those were implemented multiple times as only either seconds or hh:mm:ss + samples, initialized again each time the dialog opened. So there will be a lot of code places touched by the change, so I want to get feedback on consensus preference.

It seems to me that all generators should simply use the Selection Format, set in the Selection Toolbar, rather than all generators be different from Selection Format, or each generator have its own display format. Doesn't that make the most sense, to be universally in the same display format, as defined in Selection Toolbar?

"It seems to me that all generators should simply use the Selection Format, set
in the Selection Toolbar"

-1

I can see a strong case for wanting to generate '1 second of sound' whilst the selection bar is being used in samples or frames.  I think we SHOULD persist the display format for each generator.  If we don't we could get 'unexpected' changes in duration for the saved time interval for generate effects when moving back and forth between different sample rates and between samples and seconds.

> I think we SHOULD persist the display format for each generator.  If we don't 
> we could get 'unexpected' changes in duration for the saved time interval for
> generate effects when moving back and forth between different sample rates and 
> between samples and seconds.
As per the description the (user/QA) consensus is to persist the generator format. It's about 3:1 in favour of persisting as regards user "votes". I think there is a often a strong disconnect between Selection Toolbar format and what format is wanted for generation at the time you do it (almost complete disconnect for region generation, which I suggest leaving as is). 

I don't know how much easier it would be to implement if we were to default point generation to hh:mm:ss + milliseconds instead of seconds. That would probably let us demote this to P4 as the main issue is that lots of people want to generate at a point in less than whole seconds. I'd rather see if we can do what this enhancement suggests, though.

(In reply to comment #2)
> "It seems to me that all generators should simply use the Selection Format, set
> in the Selection Toolbar"
> 
> -1
> 
> I can see a strong case for wanting to generate '1 second of sound' whilst the
> selection bar is being used in samples or frames. 

I'd bet more people would find that confusing than would really want it. 

But I was just asking, and can be persuaded. I just want to have it decided before I implement, because the implementation will be quite different, depending. ;-)


> I think we SHOULD persist
> the display format for each generator. 

Why different for each generator? Really necessary? 

For one thing, that's a lot more work than maintaining one display format for all generators. (And that code has a lot of duplication that could well be factored up to the base class, regardless, btw.)


> If we don't we could get 'unexpected'
> changes in duration for the saved time interval for generate effects when
> moving back and forth between different sample rates and between samples and
> seconds.
> 

Yes, true. I just thought that as all the Selection Toolbar TimeTextCtrls track each other, it makes sense for that to be a universal mode. 

How about if prefs have been re-initialized? Default generator time display format to same as Selection Toolbar on first invocation, right?

(In reply to comment #3)

On 7/29/2012 11:07 AM, bugzilla-daemon@audacityteam.org wrote:> http://bugzilla.audacityteam.org/show_bug.cgi?id=547
> 
> 
> 
> --- Comment #3 from Gale Andrews <gale@audacityteam.org> 2012-07-29 19:07:18 BST ---
>> I think we SHOULD persist the display format for each generator.  If we don't 
>> we could get 'unexpected' changes in duration for the saved time interval for
>> generate effects when moving back and forth between different sample rates and 
>> between samples and seconds.
> As per the description the (user/QA) consensus is to persist the generator
> format. 

But that's not incompatible with having it preserved universally, for all TimeTextCtrls (incl Selection Toolbar), or the same display format for all generators. 


>It's about 3:1 in favour of persisting as regards user "votes". I think
> there is a often a strong disconnect between Selection Toolbar format and what
> format is wanted for generation at the time you do it (almost complete
> disconnect for region generation, which I suggest leaving as is). 

Okay, but why would we want the generators different from one another. Use case, please.

And I really don't understand why the default format should be different for point vs region. I don't know the history, but it seems it was just a lazy decision that later propagated. It's very weird to me that the same generator, opened twice in a row, once with point selection, next with region selection, should have a different display format.


> 
> I don't know how much easier it would be to implement if we were to default
> point generation to hh:mm:ss + milliseconds instead of seconds. 

*Much* easier. But I've already done the code analysis, and know how to make the changes, so if we do that, whoever gets to it later would need to do that analysis again.


>That would
> probably let us demote this to P4 as the main issue is that lots of people want
> to generate at a point in less than whole seconds. I'd rather see if we can do
> what this enhancement suggests, though.
> 

More than demoting this soon, and getting to other P3's?

>>It's about 3:1 in favour of persisting as regards user "votes". I think
>> there is a often a strong disconnect between Selection Toolbar format and
>> what format is wanted for generation at the time you do it (almost complete
>> disconnect for region generation, which I suggest leaving as is). 
> Okay, but why would we want the generators different from one another. Use
> case, please.
For example, I can easily see someone wanting to generate silence in whole seconds but generate audio in a much finer resolution. And DTMF in a different resolution again because it is a different type of audio.  

Logically, since we store Chirp and Tone Generation duration together as [Effects/ToneGen], it would make sense to me to have the format for those two the same, but allow different formats for DtmfGen, Noise and SilenceGen.   


> And I really don't understand why the default format should be different for
> point vs region. I don't know the history, but it seems it was just a lazy
> decision that later propagated. It's very weird to me that the same generator,
> opened twice in a row, once with point selection, next with region selection,
> should have a different display format.
I think the use case for hh:mm:ss+samples for regions was a good one. E.g. select an exact region you need to silence. It happens to be 2s + 31920 samples. But if you had the silence format for point generation at a whole seconds format, and region generation thus opened with a whole seconds format, just clicking OK to generate what you thought would be 2s + 31920 samples will expand the generated silence to exactly 3s. I think on the whole this would be a liability. 


>> I don't know how much easier it would be to implement if we were to default
>> point generation to hh:mm:ss + milliseconds instead of seconds. 
> *Much* easier. But I've already done the code analysis, and know how to make
> the changes, so if we do that, whoever gets to it later would need to do that
> analysis again.
>
>> That would probably let us demote this to P4 as the main issue is that lots 
>> of people want to generate at a point in less than whole seconds. 
>> I'd rather see if we can do  what this enhancement suggests, though.
>> More than demoting this soon, and getting to other P3's?
Depends how vital it is to stick to Aug 1st. To me, what matters more is getting at least two P3s fully fixed without leaving a P4 behind (if the cost is only a day or two). If we agree that always defaulting point generation to hh:mm:ss + milliseconds would still leave a P4, it seems more efficient to do the complete fix given you have done the analysis. 


> How about if prefs have been re-initialized? Default generator time display
> format to same as Selection Toolbar on first invocation, right?
If we are talking just about point generation, that means defaulting to hh:mm:ss which would be a change from the current seconds. I think hh:mm:ss would be even less useful than whole seconds. Could point generation on re-initialize default to hh:mm:ss + milliseconds? It is probably the most 
useful choice, and could mean some users would not even need to change the format.

(In reply to comment #6)

>>> It's about 3:1 in favour of persisting as regards user "votes". I think
>>> there is a often a strong disconnect between Selection Toolbar format and
>>> what format is wanted for generation at the time you do it (almost complete
>>> disconnect for region generation, which I suggest leaving as is). 
>> Okay, but why would we want the generators different from one another. Use
>> case, please.
> For example, I can easily see someone wanting to generate silence in whole
> seconds but generate audio in a much finer resolution. And DTMF in a different
> resolution again because it is a different type of audio.  

Hmm. I still think those are the relatively rare cases. And DTMF is more likely to be a shorter time span, but not different resolution.

As an initial implementation, though, how about one display format maintained for all generators? And then see whether there is actual demand for separate ones. Easier to implement, and we don't know for sure what the vast majority of users would prefer.


> 
> Logically, since we store Chirp and Tone Generation duration together as
> [Effects/ToneGen], it would make sense to me to have the format for those two
> the same, but allow different formats for DtmfGen, Noise and SilenceGen.   

That would be baffling to users, to whom Chirp and Tone appear as totally separate. 


> 
> 
>> And I really don't understand why the default format should be different for
>> point vs region. I don't know the history, but it seems it was just a lazy
>> decision that later propagated. It's very weird to me that the same generator,
>> opened twice in a row, once with point selection, next with region selection,
>> should have a different display format.
> I think the use case for hh:mm:ss+samples for regions was a good one. E.g.
> select an exact region you need to silence. It happens to be 2s + 31920
> samples. But if you had the silence format 

"silence format"?

>for point generation at a whole
> seconds format, and region generation thus opened with a whole seconds format,
> just clicking OK to generate what you thought would be 2s + 31920 samples will
> expand the generated silence to exactly 3s. I think on the whole this would be
> a liability. 

My suggestion is to make display format the same for both point and region, so you would have hh:mm:ss+samples (or whatever) for both. No inconsistency, and if you want whole seconds, just set samples field to zero.


> 
> 
>>> I don't know how much easier it would be to implement if we were to default
>>> point generation to hh:mm:ss + milliseconds instead of seconds. 
>> *Much* easier. But I've already done the code analysis, and know how to make
>> the changes, so if we do that, whoever gets to it later would need to do that
>> analysis again.
>>
>>> That would probably let us demote this to P4 as the main issue is that lots 
>>> of people want to generate at a point in less than whole seconds. 
>>> I'd rather see if we can do  what this enhancement suggests, though.
>>> More than demoting this soon, and getting to other P3's?
> Depends how vital it is to stick to Aug 1st. 

It is vital to have deadlines mean something, rather than your approach of always considering them soft. I and others have described to you before how badly that squishiness affects the rest of our lives, and you continue to ignore that. I am really disappointed to have to argue this with you every cycle. Please assume from now on that my deadlines are firm.

As RM, when I set a deadline, I mean it, and only in rare cases will I extend it. Not this time. The deadline was set weeks ago, and I double-checked 5 days ago whether there were any objections. 

All P1 and P2 have been fixed. Unless there's a new P1, we are sticking to schedule. 

When James first reacted to the real reason we're doing this release, he thought we should do so in emergency mode, right away. It's already been about a month, so we should get on with it. 


> To me, what matters more is
> getting at least two P3s fully fixed 

Well, you see that James and I completed all the P1 and P2 fixes/enhancements. And you see I'm working on the P3's, the one you wanted most, first. That's all as per my message 5 days ago, which indicated I wanted to get the P3's done, as soon as I finished the P2's.


>without leaving a P4 behind (if the cost
> is only a day or two). 

It is extremely likely that the remaining P4's on the agenda will not be completed. Both are significant efforts. 



>If we agree that always defaulting point generation to
> hh:mm:ss + milliseconds would still leave a P4, it seems more efficient to do
> the complete fix given you have done the analysis. 

Not in terms of meeting deadline and getting more P3's done. (And of course this discussion is taking time, too.) But the intermediate step I propose, one display format for all generators, would take an intermediate amount of time. 


> 
> 
>> How about if prefs have been re-initialized? Default generator time display
>> format to same as Selection Toolbar on first invocation, right?
> If we are talking just about point generation, 

We're talking about both, because I still see no valid reason for point and region to be different. When I first saw they were different, it was a wtf moment.


>that means defaulting to
> hh:mm:ss which would be a change from the current seconds. I think hh:mm:ss
> would be even less useful than whole seconds. Could point generation on
> re-initialize default to hh:mm:ss + milliseconds? It is probably the most 
> useful choice, and could mean some users would not even need to change the
> format.
> 

My actual preference would be for Selection Toolbar to default to hh:mm:ss + milliseconds on reset config, then generators would match (for point or region). I *always* set it to that format.

(In reply to comment #7)
> As an initial implementation, though, how about one display format maintained
> for all generators? And then see whether there is actual demand for separate
> ones. Easier to implement, and we don't know for sure what the vast majority 
> of users would prefer.
I can't prove the demand at the moment, and I don't think that idea is unreasonable, but I do think it is very "unexpected" given separate durations are stored for the generators (with chirp and tone sharing the same duration).   

>> Logically, since we store Chirp and Tone Generation duration together as
>> [Effects/ToneGen], it would make sense to me to have the format for those 
>> two the same, but allow different formats for DtmfGen, Noise and 
>> SilenceGen.   
> That would be baffling to users, to whom Chirp and Tone appear as totally
> separate. 
Then why did we use the same duration for Chirp and Tone? I don't like it either, so why not let Chirp and Tone have different durations? 
 
>> I think the use case for hh:mm:ss+samples for regions was a good one. E.g.
>> select an exact region you need to silence. It happens to be 2s + 31920
>> samples. But if you had the silence format 
> "silence format"?
Yes, "Silence format", meaning the selection format for silence generation as opposed to that for some other generator. 

>>for point generation at a whole seconds format, and region generation thus 
>>opened with a whole seconds format, just clicking OK to generate what you 
>>thought would be 2s + 31920 samples will expand the generated silence to 
>>exactly 3s. I think on the whole this would be a liability. 
> My suggestion is to make display format the same for both point and region, 
> so you would have hh:mm:ss+samples (or whatever) for both. No inconsistency, 
> and if you want whole seconds, just set samples field to zero.
The "inconsistency" when generating at a region was chosen deliberately I feel, for the reasons I stated of avoiding length changes. 1 in 3 voters who made a detailed comment on this problem wanted to still default region generation to hh:mm:ss + samples.

I am confident hh:mm:ss + samples is the best format for region generation. Hh:mm:ss + milliseconds is not accurate enough. I am confident hh:mm:ss + samples is not the best format for point generation. It would be worse than what we have now (because novice users would not know what a "sample" is, and could not convert samples into fractions of seconds). 

Putting all that together, -1 on having the same default format for region and point generation. Too much of a support headache.  

If you want that region generation should also allow the last used format to be remembered, fine, though I think almost no-one will change the region format if set to hh:mm:ss + samples, so it is redundant. 


>>>>> I don't know how much easier it would be to implement if we were to
>>>>> default point generation to hh:mm:ss + milliseconds instead of seconds. 
>>>> *Much* easier. But I've already done the code analysis, and know how to 
>>>> make the changes, so if we do that, whoever gets to it later would need
>>>> to do that analysis again.
>>> That would probably let us demote this to P4 as the main issue is that lots 
>>> of people want to generate at a point in less than whole seconds. 
>>>> I'd rather see if we can do  what this enhancement suggests, though.
>> More than demoting this soon, and getting to other P3's?
>> Depends how vital it is to stick to Aug 1st. 
> It is vital to have deadlines mean something, rather than your approach of
> always considering them soft. I and others have described to you before how
> badly that squishiness affects the rest of our lives, and you continue to
> ignore that. I am really disappointed to have to argue this with you every
> cycle. Please assume from now on that my deadlines are firm.
Firstly, the last e-mail I saw about this (written by a developer) stated that the release might be put back to 7th August. To me this would be a much better plan and I stated that from the outset. Of course, that e-mail was then countered by subsequent communications, but clearly extending the deadline was actually discussed.  

Secondly, please understand that I accept the general "squishiness" point more than you realise. But this is not a normal release. Looking at the README as it would currently be, we seem to be releasing for almost no apparent reason (given our usual lags between releases). It was agreed that doing this could draw attention to this particular release in an unwanted way.   

> As RM, when I set a deadline, I mean it, and only in rare cases will I extend
> it. Not this time. The deadline was set weeks ago, and I double-checked 5 days
> ago whether there were any objections. 
Note that I raised no objection, but I pointed out it would be better to include some P3's. 

>> without leaving a P4 behind (if the cost is only a day or two). 
> It is extremely likely that the remaining P4's on the agenda will not
> be completed. Both are significant efforts. 
Misunderstanding. The current P4's are off agenda as far as I am concerned. I was talking about fixing a P3 in a partial way such that it was demoted to P4.


> The intermediate step I propose, one display format for all generators, 
> would take an intermediate amount of time. 
As above that seems reasonable to me, persisting the last used format, as long as we only do that for point generation. I think that would demote this to P4 and there is a chance if no complaints of demotion to P5. 

If you want some other quickish way to demote this to P4, just default point generation to hh:mm:ss+ miiliseconds. There is more chance that complaints would continue and that the issue would be promoted again. 


>> that means defaulting to hh:mm:ss which would be a change from the current
>> seconds. I think hh:mm:ss would be even less useful than whole seconds. 
>> Could point generation on re-initialize default to hh:mm:ss + milliseconds? 
>> It is probably the most useful choice, and could mean some users would not 
>> even need to change the format.
> My actual preference would be for Selection Toolbar to default to hh:mm:ss +
> milliseconds on reset config, then generators would match (for point or
> region). I *always* set it to that format.
Off the cuff, I have no strong objection to defaulting Selection Toolbar to hh:mm:ss + milliseconds. It is a bit less friendly for novices, but it would actually help the Snap To confusion. 

There is at least one cost - the initialised window would not be wide enough for the Audio Position spinbox, unless you widened the window. But there is a good case to widen the window to fit hh:mm:ss + milliseconds (circa 700 px, maybe needs more width for Linux and Mac). We can't go over about 780 px as we still try to support 800x600.

(In reply to comment #8)

>> [...]
>>> Logically, since we store Chirp and Tone Generation duration together as
>>> [Effects/ToneGen], it would make sense to me to have the format for those 
>>> two the same, but allow different formats for DtmfGen, Noise and 
>>> SilenceGen.   
>> That would be baffling to users, to whom Chirp and Tone appear as totally
>> separate. 
> Then why did we use the same duration for Chirp and Tone? 

Don't ask me -- I didn't do it! ;-)


>I don't like it
> either, so why not let Chirp and Tone have different durations? 

Probably just a minor oversight, in deriving Chirp from Tone, rather than a decision.


> 
>>> I think the use case for hh:mm:ss+samples for regions was a good one. E.g.
>>> select an exact region you need to silence. It happens to be 2s + 31920
>>> samples. But if you had the silence format 
>> "silence format"?
> Yes, "Silence format", meaning the selection format for silence generation as
> opposed to that for some other generator. 

It's not a selection format unless it's in the Selection Toolbar -- and that's more properly "selection display format". This is a duration display format. It's not a format for Silence (meaningless), it's for display. I had no idea what you meant.


> 
>>> for point generation at a whole seconds format, and region generation thus 
>>> opened with a whole seconds format, just clicking OK to generate what you 
>>> thought would be 2s + 31920 samples will expand the generated silence to 
>>> exactly 3s. I think on the whole this would be a liability. 
>> My suggestion is to make display format the same for both point and region, 
>> so you would have hh:mm:ss+samples (or whatever) for both. No inconsistency, 
>> and if you want whole seconds, just set samples field to zero.
> The "inconsistency" when generating at a region was chosen deliberately I feel,
> for the reasons I stated of avoiding length changes. 

This doesn't respond to my suggestion that they simply should use the more precise format for point or region. That avoids accidental length changes.


>1 in 3 voters who made a
> detailed comment on this problem wanted to still default region generation to
> hh:mm:ss + samples.

That seems to imply 2 in 3 voted against it.

Any indication *why* they voted that way?


> 
> I am confident hh:mm:ss + samples is the best format for region generation.
> Hh:mm:ss + milliseconds is not accurate enough. I am confident hh:mm:ss +
> samples is not the best format for point generation. It would be worse than
> what we have now (because novice users would not know what a "sample" is, and
> could not convert samples into fractions of seconds). 

I see. I don't like it, but I see. 


> 
> Putting all that together, -1 on having the same default format for region and
> point generation. Too much of a support headache.  

<snark>
Ah, the Microsoft way -- don't fix things, let our history and our least-savvy users turn our product ever more mediocre and internally inconsistent. 
</snark>

I capitulate.


> 
> If you want that region generation should also allow the last used format to be
> remembered, fine, though I think almost no-one will change the region format if
> set to hh:mm:ss + samples, so it is redundant. 

Okay, will leave as is. 



(Moved the discussion about missing the deadline off this thread. It doesn't belong here.)

 
>[...] 
>> The intermediate step I propose, one display format for all generators, 
>> would take an intermediate amount of time. 
> As above that seems reasonable to me, persisting the last used format, as long
> as we only do that for point generation. I think that would demote this to P4
> and there is a chance if no complaints of demotion to P5. 
> 
> If you want some other quickish way to demote this to P4, just default point
> generation to hh:mm:ss+ miiliseconds. There is more chance that complaints
> would continue and that the issue would be promoted again. 

Done, r11884. Please confirm and demote. 

If I get the other P3's fixed, I'll work on a more complete solution.


> 
> 
>>> that means defaulting to hh:mm:ss which would be a change from the current
>>> seconds. I think hh:mm:ss would be even less useful than whole seconds. 
>>> Could point generation on re-initialize default to hh:mm:ss + milliseconds? 
>>> It is probably the most useful choice, and could mean some users would not 
>>> even need to change the format.

Done, r11884. 


>> My actual preference would be for Selection Toolbar to default to hh:mm:ss +
>> milliseconds on reset config, then generators would match (for point or
>> region). I *always* set it to that format.
> Off the cuff, I have no strong objection to defaulting Selection Toolbar to
> hh:mm:ss + milliseconds. It is a bit less friendly for novices, but it would
> actually help the Snap To confusion. 

Done, r11885. 


> 
> There is at least one cost - the initialised window would not be wide enough
> for the Audio Position spinbox, unless you widened the window. But there is a
> good case to widen the window to fit hh:mm:ss + milliseconds (circa 700 px,
> maybe needs more width for Linux and Mac). We can't go over about 780 px as we
> still try to support 800x600.
> 
Done, r11885.

>> There is at least one cost - the initialised window would not be wide enough
>> for the Audio Position spinbox, unless you widened the window. But there is a
>> good case to widen the window to fit hh:mm:ss + milliseconds (circa 700 px,
>> maybe needs more width for Linux and Mac). We can't go over about 780 px as we
>> still try to support 800x600.
>> 
>Done, r11885.
On that specific, Mac looks fine, but Ubuntu 12.04 (default theme/font) has the Audio Position truncated. To give the merest border after Audio Position needs 762 px, so really I guess that means 780 px if we want a decent chance of not truncating on Linux.

All seems OK on the three platforms except the width question on Linux.
  
>>1 in 3 voters who made a detailed comment on this problem wanted to still 
>> default region generation to hh:mm:ss + samples.
> That seems to imply 2 in 3 voted against it.
2 in 3 had no view. No-one voted for changing the region generation default. 

Any indication *why* they voted that way?
> Not recorded on Wiki, but some I am sure thought it was the most accurate. 

In an ideal world I would agree region and point generation should default the same but Audacity is popular because we are not Ardour.

I really don't think user changing the selection format for point generation should ever change their choice for region generation even if we allowed them to change the latter.

(In reply to comment #10)


>>> There is at least one cost - the initialised window would not be wide enough
>>> for the Audio Position spinbox, unless you widened the window. But there is a
>>> good case to widen the window to fit hh:mm:ss + milliseconds (circa 700 px,
>>> maybe needs more width for Linux and Mac). We can't go over about 780 px as we
>>> still try to support 800x600.
>>>
>> Done, r11885.
> On that specific, Mac looks fine, but Ubuntu 12.04 (default theme/font) has the
> Audio Position truncated. To give the merest border after Audio Position needs
> 762 px, so really I guess that means 780 px if we want a decent chance of not
> truncating on Linux.
> 

Done, r11889.

(In reply to comment #12)
>> Ubuntu 12.04 (default theme/font) has the Audio Position truncated.
>> ... I guess that means 780 px if we want a decent chance of not truncating 
>> on Linux.
> Done, r11889.
That tests fine for me. Accordingly, demoted to P4.

I fundamentally agree with James in Comment #2 from 2012, where he writes:

"It seems to me that all generators should simply use the Selection Format, set
in the Selection Toolbar"

-1

I can see a strong case for wanting to generate '1 second of sound' whilst the selection bar is being used in samples or frames.  I think we SHOULD persist the display format for each generator.  If we don't we could get 'unexpected' changes in duration for the saved time interval for generate effects when moving back and forth between different sample rates and between samples and seconds.


And this is the behavior that I see (and want) on Windows and Mac - therefore I am closing this as NOTABUG