Page 2 of 3
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Sat Nov 22, 2014 11:14 pm
by Gale Andrews
Edgar wrote:Gale Andrews wrote:
hh:mm:ss + microseconds? I think that's what most want (what 1.2.6 had).
Therein lies the rub! My guess is that anyone interested in examining the seconds out to six decimal points will not be looking at audio that is many hours long. My personal choice would probably be mmmm:ss + micro (i.e. 4 places for the number of whole seconds). Note that by choosing hh:mm:ss we limit the ability to display more than 99 hours + 59 minutes + 59 seconds – probably a most reasonable limit.
Code: Select all
Index: src/widgets/TimeTextCtrl.cpp
===================================================================
--- src/widgets/TimeTextCtrl.cpp (revision 12198)
+++ src/widgets/TimeTextCtrl.cpp (working copy)
@@ -400,6 +400,10 @@
/* i18n-hint: Format string for displaying time in frames with CD Audio
* frames. Translate 'frames' and leave the rest alone */
BuiltinFormatStrings[15].formatStr = _("01000,01000 frames|75");
+ /* i18n-hint: Name of time display format that shows time in seconds and microseconds */
+ BuiltinFormatStrings[16].name = _("seconds + microseconds");
+ /* i18n-hint: Format string for displaying time in seconds and microseconds. */
+ BuiltinFormatStrings[16].formatStr = _("010000.01000000 s");
mDigitBoxW = 10;
mDigitBoxH = 16;
Index: src/widgets/TimeTextCtrl.h
===================================================================
--- src/widgets/TimeTextCtrl.h (revision 12198)
+++ src/widgets/TimeTextCtrl.h (working copy)
@@ -134,7 +134,7 @@
* needed to create that format output. This is used for the pop-up
* list of formats to choose from in the control. Note that the size will
* need adjusting if new time formats are added */
- BuiltinFormatString BuiltinFormatStrings[16];
+ BuiltinFormatString BuiltinFormatStrings[17];
double mTimeValue;
wxString mFormatString;
Now that the index isn't hardocded I tried adding ss + microseconds and hh:mm:ss + microseconds but it certainly does not work as well as it did in 1.2.6.
In an empty 44100 Hz project window we see that TimeText controls start at 1 microsecond instead of 0 (as per your image above), and start at 3 microseconds at 1000000 Hz.
Generate doesn't let you generate exactly 1.000000 seconds when the selection format is in microseconds.
Is this expected?
Gale
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Sun Nov 23, 2014 4:56 am
by Edgar
Gale, this thread is a year old and the underlying code has changed drastically in the last couple weeks. Are you trying to patch SVN HEAD or are you seeing strange results with SVN HEAD and no patch? There's a much more current thread (
http://forum.audacityteam.org/viewtopic ... 20&t=82163 ) which discusses adding a new format; on that thread suizokukan offers to submit a patch - is that the code you're discussing?
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Sun Nov 23, 2014 10:42 am
by Gale Andrews
Edgar wrote:Gale, this thread is a year old and the underlying code has changed drastically in the last couple weeks. Are you trying to patch SVN HEAD or are you seeing strange results with SVN HEAD and no patch? There's a much more current thread (
http://forum.audacityteam.org/viewtopic ... 20&t=82163 ) which discusses adding a new format; on that thread suizokukan offers to submit a patch - is that the code you're discussing?
HEAD doesn't include microseconds. Yes I tested Suizokukan's patch to add seconds and milliseconds (which is fine) and also added seconds and microseconds and hours, minutes, seconds and microseconds (attached).
Gale
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Sun Nov 23, 2014 3:51 pm
by Robert J. H.
Gale Andrews wrote:Edgar wrote:Gale, this thread is a year old and the underlying code has changed drastically in the last couple weeks. Are you trying to patch SVN HEAD or are you seeing strange results with SVN HEAD and no patch? There's a much more current thread (
http://forum.audacityteam.org/viewtopic ... 20&t=82163 ) which discusses adding a new format; on that thread suizokukan offers to submit a patch - is that the code you're discussing?
HEAD doesn't include microseconds. Yes I tested Suizokukan's patch to add seconds and milliseconds (which is fine) and also added seconds and microseconds and hours, minutes, seconds and microseconds (attached).
Gale
Thanks Gale
It occurred to me that there is another format that is actually missing: Percentage
This is especially useful for "Player" mode.
It is arguable though if it should apply to the track's length or the project length.
Yet another thing, why has the Audio position to show a value of 0 in stop mode? In this case, it should take the value of the left boundary of the selection in my humble opinion.
In my accessibility extension, it always reports the maximum of those two values. Thus, one hotkey less to belay.
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Sun Nov 23, 2014 4:29 pm
by steve
Robert J. H. wrote:It occurred to me that there is another format that is actually missing: Percentage
There's an infinite number of formats "missing".
Julian days : hh : mm
tP x 10^nn
ss + nanoseconds
moments
beats at 120 bpm
4/4 bars + 120 bpm
3/4 bars + 120 bpm
5/4 bars + 120 bpm
6/6 bars + 120 bpm
4/4 bars + 121 bpm
3/4 bars + 121 bpm
....
....
I don't believe that adding this one or that one in an ad hoc manner is the correct approach because there will always be some situation that requires units that are not available. Imo what we need is a general solution that allows the user to define "ticks" and "tick multipliers".
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Sun Nov 23, 2014 8:27 pm
by Robert J. H.
steve wrote:Robert J. H. wrote:It occurred to me that there is another format that is actually missing: Percentage
There's an infinite number of formats "missing".
Julian days : hh : mm
tP x 10^nn
ss + nanoseconds
moments
beats at 120 bpm
4/4 bars + 120 bpm
3/4 bars + 120 bpm
5/4 bars + 120 bpm
6/6 bars + 120 bpm
4/4 bars + 121 bpm
3/4 bars + 121 bpm
....
....
I don't believe that adding this one or that one in an ad hoc manner is the correct approach because there will always be some situation that requires units that are not available. Imo what we need is a general solution that allows the user to define "ticks" and "tick multipliers".
Percentage can't be defined like that.
The actual problem is that the entire project length or the total length of a track are nowhere available on the screen (e.g. in the status bar).
Of course, I can simply take the selection length and calculate the percentage according to that. This makes at least sense for a (screen reader) real time report of the audio position per hotkey.
However, the decoding is only simple when the format is whole seconds or samples.
You did not answer the second question, any opinion on that?
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Sun Nov 23, 2014 9:30 pm
by Gale Andrews
steve wrote:I don't believe that adding this one or that one in an ad hoc manner is the correct approach because there will always be some situation that requires units that are not available. Imo what we need is a general solution that allows the user to define "ticks" and "tick multipliers".
Well one could say it is a lottery what requested formats get added. Are the "ticks" the ticks on the Timeline and is the "tick multiplier" a sliding scale of some sort?
Robert J. H. wrote:You did not answer the second question, any opinion on that?
Why has the Audio position to show a value of 0 in stop mode? In this case, it should take the value of the left boundary of the selection in my humble opinion.
Isn't the left edge of the selection displayed by Selection Start?
Gale
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Mon Nov 24, 2014 8:56 am
by Robert J. H.
Gale Andrews wrote:Robert J. H. wrote:You did not answer the second question, any opinion on that?
Why has the Audio position to show a value of 0 in stop mode? In this case, it should take the value of the left boundary of the selection in my humble opinion.
Isn't the left edge of the selection displayed by Selection Start?
Sure it is, I don't say that any of these controls should be removed.
However, the 000000 values are absolutely meaningless.
Audio Position should somewhat represent the cursor position, shouldn't it?
This would mean that it takes the same value as the left edge of the selection.
There's one exception to this rule: the left selection edge can start before zero, whereas the audio position can not.
By the way, the display for negative time values is broken in the 2.0.7 alpha builts (not related to the patch). The screen reader reports only dashes.
This worked before, at least with NVDA.
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Mon Nov 24, 2014 9:28 am
by steve
Robert J. H. wrote:Why has the Audio position to show a value of 0 in stop mode? In this case, it should take the value of the left boundary of the selection in my humble opinion.
I'm unsure what you are observing. As far as I can see it appears to be working correctly. Could you give steps to reproduce the issue (I have NVDA installed on a virtual machine with Windows XP)
Re: Will 2.0.03 measure seconds to 6 decimal places?
Posted: Mon Nov 24, 2014 3:37 pm
by Gale Andrews
Robert J.H. wrote:the display for negative time values is broken in the 2.0.7 alpha builts (not related to the patch). The screen reader reports only dashes.
I think NVDA is reading what is displayed correctly.
On Windows 7 If I have exactly one second of audio behind zero, 2.0.0 shows for Selection Start:
2.0.6 shows
2.1.0-alpha shows all dashes
Gale