Re: [Audacity-devel] P3 Timer Record duration (was "cannot maintain scheduled duration if system clock changes")

[Ed M. <edg...@wa...>]

Cool! All that sounds good.

--Ed

> -----Original Message-----
> From: Vaughan Johnson [mailto:va...@au...]
> Sent: Thursday, October 22, 2009 3:04 PM
> To: aud...@li...
> Subject: Re: [Audacity-devel] P3 Timer Record duration (was "cannot
> maintain scheduled duration if system clock changes")
> 
> 
> 
> Ed Musgrove wrote:
> >> -----Original Message-----
> >> From: Vaughan Johnson [mailto:va...@au...]
> ....
> >>
> >>> As for the duration of the recording, it would be astronomically
> >>> time-consuming to run twenty-five five-minute tests.
> >> ...
> >> Why did you suggest 25 tests? I wasn't asking for that.
> > [Ed:]
> > There are multiple case scenarios.
> > *Set only the duration (starts automatically immediately runs for
> > duration) *set start time for the future, set duration (starts wait
> > timer...) *set start time for future, set end time (duration
> > calculated, starts wait
> > timer...)
> > *Set end time, set duration (starts immediately...) *Set start time in
> > the past...
> > *set start time in the future, set end time before start time...
> > *Set... (there are probably a couple other permutations)
> 
> But try it, or look at the code, and you'll see I've already prevented
some of
> those errorful usages (e.g., you cannot set start time in the past).
> 
> And what do those cases have to do with this specific bug we're
discussing?
> Or the number 25?
> 
> > ...
> >> So what do you suggest for a fix, based on your tests?
> > [Ed:]
> > Post-2.0 you and I should examine the code which controls timed
> > recording duration. In a discussion (here on this list, on the Wiki or
> > in the open
> > forum) with others we should determine design criteria -- how much
> > granularity is acceptable (-N milliseconds/+N milliseconds-- -0/+ 250
> > is my suggestion). Then, with me doing the bulk of the code writing
> > and you doing the peer review on the code and both of us doing beta
> > testing we did get Audacity functioning as close to design criteria as
> > possible and make a note in the documentation of what the expected
> granularity might be.
> 
> Wow, I hope you are kidding. It's a simple bug, in wxMilliSleep or UNow,
that
> we just have to figure out how to work around.
> 
> Yes, it should never record less than the specified duration. Obviously,
as
> written, it shouldn't because the loop exit condition is based on
comparing
> the most accurate current time from wx with the start time plus duration.
> Maybe we should use something other than UNow().
> 
> I don't see a big need for a discussion about whether it should be 250ms
> extra or 500 or whatever. Few people will ever know about it.
> 
> The fix will probably be not even a full line of code. I don't think there
is a
> "bulk of the code writing". All of it should take less time than reading
this
> email (!).
> 
> 
> >
> > Please be aware that I have opened a topic on the Audacity forum which
> > deals with some GUI aspects of time recording (but has nothing to do
> > with this bug nor with the granularity of duration issue:
> > http://forum.audacityteam.org/viewtopic.php?f=20&t=14621
> >
> Will answer those there.
> 
> Please don't interpret my terseness above as anger. I just think it's a
tiny little
> bug that doesn't need a big discussion of "design criteria".
> 
> - Vaughan
> 
> 
> 
> 
>
----------------------------------------------------------------------------
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
the
> only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel