Re: [Audacity-devel] Timer Recording Improvements

[Peter S. <pet...@gm...>]

Gale wrote:
>1: We want to say "Quit Audacity" not "Close Audacity" in the
"AfterRecording"
>option. "Close" has a specific meaning of closing projects without quit.

Are you saying ths Gale because it is possible to set up TR to just export
an audio
file on completion and then "Close" without saving, or being prompted to
save, the
project?

Even if so I think "Close" is more appropriate than "Quit".  We have no
"Quit" command
in Audacity - not in the menues nor in keyboard shortcuts.  The only "quit"
is the
operating system "quit" surely (the X at top right in windows and the red
blob at top left
on Mac) ?



Gale wrote:
>2: It would be nice to write the last used "After Recording" option to
audacity.cfg
>so that option gets offered on next Timer Record.

Big +1 to this

It would ne *more* than nice - it is our usual modus operandi for Audacity
to remember
last-used settings and restore them on next use.

Cheers,
Peter.

On Wed, Mar 16, 2016 at 9:47 AM, Peter Sampson <
pet...@gm...> wrote:

> Mark wrote:
> >As a quick aside, is there a release schedule of when you would intend to
> release 2.1.3?
> >So I know if I have a timescale for inclusion in that build?
>
> At this point in time we don't yet have a plan for 2.1.3, or a schedule -
> so I'm guessing that it is
> at least theree months away from now - so that should allow plenty of time
> for inclusion of
> your enhancements in 2.1.3.  *Gale (as Quality Manager) will correct me
> if my guestimate is wrong ...*
>
> And that is certainly something that I (from a QA perspective - and as a
> major user of timed
> recordings) will be *strongly* pushing for.
>
> Cheers,
> Peter.
>
> On Wed, Mar 16, 2016 at 9:41 AM, Peter Sampson <
> pet...@gm...> wrote:
>
>> Gale wrote:
>> >* It's too restrictive to forbid "automatic save" Timer Record into an
>> >already saved project. That is too much of a regression on now.
>>
>> My understanding of what Mark is intending is that
>> IF the user is working ina project that is already Saved ("clean" or
>> "dirty")
>> THEN the *only* project that the TR can be Saved to is that current
>> project
>> ELSE the user can select any (new) project name
>>
>> The problem I encounter is that there is a bug which wont let me save to
>> the existing sole open project even though the target path field is
>> populated
>> in gray.  I can't tell if tis the correct path as I can only see the very
>> first part
>> of the path.
>>
>>
>>
>> Gale wrote:
>> >* Not allowing Timer Record with other clean projects open seems
>> >an un-necessary regression to me, though not major.
>>
>> Please see my prvious email where I argue that accepting this very minor
>> regression may yield us big benefits (such as access to the controls
>> during
>> a Timer Recording).
>>
>>
>>
>> Gale wrote:
>> >* When you overwrite an existing project there should be a warning
>> >before Timer Record starts, even if we also want an error message
>> >afterwards.
>>
>> I strongly believe that Timer Record should *not* be allowed to overwrite
>> any existing projects.
>>
>> We explicity preclude "Save As" in Audacity from overwriting existing
>> projects - so why on earth should we expect TR to be able to do this?
>>
>>
>> Cheers,
>> Peter.
>>
>> On Wed, Mar 16, 2016 at 9:28 AM, Peter Sampson <
>> pet...@gm...> wrote:
>>
>>> Stevethefiddle wrote
>>> > Also, I presume that if there is only one project open when
>>> > Timer Recording is waiting to start, it would not be necessary to
>>> > completely lock the user out of that project - for example, could the
>>> > timer dialog remain open so that the user can adjust the start / end
>>> > times (would be useful if recording an event that has been
>>> > unexpectedly delayed).
>>> Gale replied
>>> > +1 though not relevant to Mark's changes.
>>>
>>> And big +1 from me too.
>>>
>>> This may not be relevant to Marks existing changes - but it is extremely
>>> relevant
>>> to enhancments requested in the long-standing proposal:
>>> http://wiki.audacityteam.org/wiki/Proposal_Timer_Record_Improvements
>>>
>>> Where it says:
>>> *Ability to change the event times:*
>>>
>>>    - Add the ability to change (extend or shorten) the recording stop
>>>    time during recording. Would require a modification to the "Audacity Timer
>>>    Record Progress" dialog box.
>>>    - Add the ability to change (extend or shorten) the recording stop
>>>    time or the start time while waiting to record. Would require a
>>>    modification to the "... Waiting for Start" dialog box.
>>>    - Provide a *Timer Stop* to be available for a manually initiated
>>>    recording to be stopped after a settable time, possibly implemented by
>>>    making the Timer Record dialog available after recording has been
>>>    initiated.
>>>
>>> This would be an incredibly valuable feature at time, e.g on Monday
>>> night at midnight when setting a TR in a hurry I inadvertently started an
>>> important TR accidentally setting the record time to 20 hours rather than
>>> 2.  I knew I had enough disk space to safely let it run till I woke and
>>> stopped it bit it would have been extremely useful to be able to adjust the
>>> end-time or duration.
>>>
>>>
>>> Both this and the other major enhancement request in that proposal "*Timer
>>> Record to enable access to the normal set of recording controls*"
>>> should probably be readily achievable with safety if we agree to retain
>>> Mark's decision in his current implementation to have the Timer Record as
>>> the only open project - as then we can safely make the TR dialogs modeless
>>> and this should enable us to get access to the recording controls.
>>>
>>>
>>> The more I think about it, having absorbed Mark's reasoning and read
>>> Steve's arguments in favour, I am strongly in favour of a Timer Record
>>> being allowed only in a sole open project (as Mark has it now - *in the
>>> process, forcing the user to close all other projects and in the process
>>> Save the "dirty" ones" if required*).
>>>
>>> a) For a start, Timer Record is mainly intended as a tool for
>>> "unattended recording" i.e. the user is not present at the computer for all
>>> or most of the recording.
>>>
>>> b) As Steve points out, when TR is waiting/active (in current Audacity)
>>> the user is denied editing/recording access to all other Audacity projects
>>> open at the same time.  So there is no real tangible benefit in keeping
>>> them open *(apart from the short-term memory issue of remembering which
>>> projects you are currently worling on).*
>>>
>>> c) If the user wants/needs to copy all or part of their timed recording
>>> on completion to other projects then it is no real hardship to have to
>>> re-open those projects (they should be in the "Recent files" list
>>> permitting ready and easy access).
>>>
>>> Cheers,
>>>
>>> Peter
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Mar 16, 2016 at 7:08 AM, Mark Young <ma...@ti...> wrote:
>>>
>>>> Good morning Peter, Steve and Gale.
>>>>
>>>> A lot to digest here, I'll have a proper read over these points as soon
>>>> as possible.
>>>>
>>>> One point, about not being able to access Timer Recording with other
>>>> open projects: I agree that my change to warn the users is a benefit rather
>>>> than the previous functionality which didn't allow you to access the other
>>>> project windows anyway. Personally, I think this should stay, with the
>>>> relevant changes to messages etc.
>>>>
>>>> As I said, I'll read through all this again and get some code down soon.
>>>>
>>>> As a quick aside, is there a release schedule of when you would intend
>>>> to release 2.1.3? So I know if I have a timescale for inclusion in that
>>>> build?
>>>>
>>>> Mark
>>>> On 16 Mar 2016 01:51, "Gale" <ga...@au...> wrote:
>>>>
>>>>> Thanks, Mark for working on the suggestions.
>>>>>
>>>>> My summary:
>>>>>
>>>>> * It's too restrictive to forbid "automatic save" Timer Record into an
>>>>> already saved project. That is too much of a regression on now.
>>>>>
>>>>> * Not allowing Timer Record with other clean projects open seems
>>>>> an un-necessary regression to me, though not major.
>>>>>
>>>>> * When you overwrite an existing project there should be a warning
>>>>> before Timer Record starts, even if we also want an error message
>>>>> afterwards.
>>>>>
>>>>> Details:
>>>>>
>>>>>
>>>>> Stevethefiddle wrote
>>>>> > On 14 March 2016 at 17:03, Peter Sampson &lt;
>>>>>
>>>>> > petersampsonaudacity@
>>>>>
>>>>> > &gt; wrote:
>>>>> >> Testing Mark's latest build Audacity-tip2tail-20160314 on W10.
>>>>> >>
>>>>> >> 1) The basic functionality continutues to wook as expected,
>>>>> Automatic
>>>>> >> Saves
>>>>> >> and Automatic exports work.
>>>>> >>
>>>>> >>
>>>>> >> 2) The nomenclature in the dialog is "Automatic Save" and Automatic
>>>>> >> Export"
>>>>> >> as Gale suggested.
>>>>> >> BUT one of the error messages I encountered (see below ) still has
>>>>> "Auto
>>>>> >> Save" and "Auto save"
>>>>> >>
>>>>> >>
>>>>> >> 3) You can now only use Timer Record if you have onlya a single
>>>>> current
>>>>> >> project open.
>>>>> >> Otherwise you get the error message:
>>>>> >> "Timer Record cannot be used with more than one open project.
>>>>> Please
>>>>> >> close
>>>>> >> any additional projects and try again"
>>>>> >>
>>>>> >> Now while I (personally) am probably happy with this behaviour, it
>>>>> is a
>>>>> >> regression on all previous Audacity versions that had Timer
>>>>> Record.  In
>>>>> >> 2.1.2 for example you can have several projects open and then
>>>>> either open
>>>>> >> a
>>>>> >> new project for Timer Recording or set a Timer Recording in any of
>>>>> the
>>>>> >> existing projects.
>>>>> >
>>>>> > Timer Record is not a feature that I personally use, but looking at
>>>>> > the behaviour in 2.1.2, Marks decision to allow only one project when
>>>>> > using Timer Record, looks very sensible, and no real down-side to it.
>>>>> >
>>>>> > Currently, if there are multiple projects open, initiating Timer
>>>>> > Record locks all other projects so the user can do nothing in the
>>>>> > other projects. If the other project(s) have unsaved work, then the
>>>>> > user must either abort the Timer Record, or wait until the recording
>>>>> > is completed before they can save their work. That seems to me to be
>>>>> > an unnecessary risk for the user - imo it would be better to prompt
>>>>> > the user to save and close all other projects before starting the
>>>>> > Timer Record.
>>>>> >
>>>>> > In addition, if there are multiple projects open, I assumed that
>>>>> > recording would occur in the project in which Timer Record was
>>>>> > initiated, but that is not the case. Example:
>>>>> > 1) Launch Audacity and create some audio in it, perhaps do a few
>>>>> edits.
>>>>> > 2) "File > New" to crate a new project
>>>>> > 3) Set Timer Record to start in 5 minutes and record for 1 minute.
>>>>> > 4) Alt+Tab to the first project to try and save it - you can't.
>>>>> > 5) Alt+Tab back to your web browser and browse the Internet - after
>>>>> > about 6 minutes you will be prompted to save the project. Accept and
>>>>> > save the project.
>>>>> > What have you done?
>>>>>
>>>>> I don't understand what Steve wrote. Timer Record (now) does take place
>>>>> in the project it was initiated in.  In the example given we are being
>>>>> invited
>>>>> to save only the Timer Record project.
>>>>>
>>>>> Windows 7 does not switch you back to Audacity with the prompt to save
>>>>> the Timer Record. That does happen on Ubuntu with Unity. I "think"
>>>>> GNOME
>>>>> does the switch too.
>>>>>
>>>>> On Ubuntu with Unity (but not on Windows) you can actually ALT + TAB
>>>>> to the
>>>>> project in step 1. But even if I ALT + TAB to that first project, then
>>>>> ALT +
>>>>> TAB
>>>>> to Firefox, then when I get switched back to Audacity I am looking at
>>>>> the
>>>>> Timer Record project and not the first project.
>>>>>
>>>>> In any case, that behaviour will be history when we commit the final
>>>>> version
>>>>> of Mark's changes.
>>>>>
>>>>>
>>>>> Peter Sampson wrote
>>>>> > This has presumably been done to protect the user from having
>>>>> additional
>>>>> > "dirty" unsaved projects when a Timer Record is set to close
>>>>> Audacity or
>>>>> > the
>>>>> > computer on completion.   But this is perhaps too restrictive - if
>>>>> the
>>>>> > user
>>>>> > has other open projects none of which are "dirty" and then elects to
>>>>> set
>>>>> > up
>>>>> > a Timer Recording with an automatic close of Audacity or the
>>>>> computer then
>>>>> > probably they should be able to do that.
>>>>>
>>>>> Yes. This isn't like the case with Chains applied to files where we
>>>>> require
>>>>> that
>>>>> all projects are saved and closed first (and even in that Chains case
>>>>> I am
>>>>> not
>>>>> sure why in principle we can't run a Chain on files with other clean
>>>>> projects
>>>>> open).
>>>>>
>>>>> The only case I can think of where we might want to close other clean
>>>>> projects
>>>>> is when Timer Record has been set to "close" Audacity, the user could
>>>>> somehow
>>>>> task switch and interact with the other projects in the split second
>>>>> between
>>>>> the
>>>>> modal dialogue disappearing and Audacity quitting. That edge case
>>>>> would not
>>>>> worry me.
>>>>>
>>>>>
>>>>> Stevethefiddle wrote
>>>>> >> I thought that what we had agreed was that IF other "dirty"
>>>>> projects were
>>>>> >> open AND IF the user tries to set up a Timer Record which
>>>>> automatically
>>>>> >> closes Audacity or the computer THEN they get an error message
>>>>> telling
>>>>> >> them to save or close the saved projects
>>>>> >> first.
>>>>> >>
>>>>> >> So we have to decide whether or not we accept this regression ...
>>>>> >
>>>>> > I'd call it a "feature enhancement" in that it makes Timer Record
>>>>> > safer.
>>>>>
>>>>> I suggested the message "Please save other open projects first".  Not
>>>>> "close".
>>>>>
>>>>> Suppose you want to copy some of your Timer Record when complete to
>>>>> other projects you had open?
>>>>>
>>>>> But, my main issue is that you cannot "automatic save" Timer Record to
>>>>> the
>>>>> same name as an already-saved project, clean or dirty. Surely quite a
>>>>> few
>>>>> people will currently be Timer Recording into an existing clean or
>>>>> dirty
>>>>> project.
>>>>> This restriction makes no sense given you can properly "automatic save"
>>>>> Timer Record into a dirty project that was never saved.
>>>>>
>>>>> So I would like to allow "automatic save" Timer Record into an
>>>>> already-saved
>>>>> project, clean or dirty, even with the "quit-on-completion" option
>>>>> enabled.
>>>>> This was not a problem in Mark's earlier builds.
>>>>>
>>>>> Similarly you cannot now "automatic save" Timer Record into an existing
>>>>> clean or dirty project and save as a new unused project name.  Ideally
>>>>> this
>>>>> should be allowed too, IMO, though not as important as automatic save
>>>>> to an existing project. Just to remind, the problem I saw with this was
>>>>> orphan
>>>>> files in the Timer Recording when saving to a new name and the current
>>>>> already-saved project was dirty.
>>>>>
>>>>> If the existing project is dirty, we could possibly save it for the
>>>>> user
>>>>> (with
>>>>> progress dialogue) before commencing Timer Record. But the correct fix
>>>>> to
>>>>> me seems to be after Timer Record finishes.
>>>>>
>>>>> The other complaint I have is that when you choose a project name to
>>>>> save
>>>>> to that already exists, Timer Record should warn you explicitly at that
>>>>> point
>>>>> that it won't overwrite that project. The warning could have "OK" which
>>>>> would
>>>>> let you record and "Cancel" which would let you stay in Timer Record
>>>>> and
>>>>> choose another name.
>>>>>
>>>>> Otherwise, you could be trying to overwrite a project numerous times
>>>>> before
>>>>> the penny drops as to what the generic save error after recording
>>>>> really
>>>>> means.
>>>>>
>>>>> Two Asides:
>>>>>
>>>>> 1: We want to say "Quit Audacity" not "Close Audacity" in the "After
>>>>> Recording"
>>>>> option. "Close" has a specific meaning of closing projects without
>>>>> quit.
>>>>>
>>>>> 2: It would be nice to write the last used "After Recording" option to
>>>>> audacity.cfg
>>>>> so that option gets offered on next Timer Record.
>>>>>
>>>>>
>>>>> Stevethefiddle wrote
>>>>> > Also, I presume that if there is only one project open when
>>>>> > Timer Recording is waiting to start, it would not be necessary to
>>>>> > completely lock the user out of that project - for example, could the
>>>>> > timer dialog remain open so that the user can adjust the start / end
>>>>> > times (would be useful if recording an event that has been
>>>>> > unexpectedly delayed).
>>>>>
>>>>> +1 though not relevant to Mark's changes.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> Stevethefiddle wrote
>>>>> > BTW, I'm aware that this work is addressing some very long-standing
>>>>> > feature requests, so thanks to Mark for taking this on.
>>>>> >
>>>>> > Steve
>>>>> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> 4) I cannot set up a Timer Record to save to a "new" "clean"
>>>>> project.
>>>>> >>
>>>>> >> a) Open Audacity
>>>>> >> b) File>Save As to new valid project name
>>>>> >> c) empty project ssaves ok
>>>>> >> d) Set Up a Timer Record
>>>>> >> e) "Save Project As" field is pre-poulated and grayed out as
>>>>> >> inaccessible/unalterable
>>>>> >> f) you cannot see the full path/name to check the target destination
>>>>> >> g) check the "Enable Automatic Save"
>>>>> >> h) set timers
>>>>> >> i) click "OK"
>>>>> >> j) Error message is displayed:  "Error in Auto Save - Auto save
>>>>> path is
>>>>> >> invalid"
>>>>> >> Auto should be Automatic in full and the lower-case S in save
>>>>> should be
>>>>> >> capitalized.
>>>>> >> but I really shouldn't be encountering this "error".
>>>>> >>
>>>>> >>
>>>>> >> 5) The Timer Record dialogue enables me to set the Automatic Sve
>>>>> path to
>>>>> >> an
>>>>> >> existing Audacity Project/
>>>>> >>
>>>>> >> With "Do nothing" on completion selected
>>>>> >> a) I get the warning message
>>>>> > <project>
>>>>> > .aup already exists. Do you want to
>>>>> >> replace it?"
>>>>> >> b) Pressing the Ok in the warning dialog takes me back to Timer
>>>>> Record
>>>>> >> dialog
>>>>> >> c) Click on OK in the TR dialog
>>>>> >> d) Timer Record starts and completes
>>>>> >> e) Error message: "Timer Recording completed.  Error saving
>>>>> recording"
>>>>> >> (no
>>>>> >> clue as to what the error actually is ...
>>>>> >> f) click OK in the error dialog.
>>>>> >> g) returns ok to unsaved project with timed recording
>>>>> >>
>>>>> >> Alternatively if I set up TR to Automatic Close/shutdown at step e)
>>>>> I get
>>>>> >> the error message:
>>>>> >> e) Timer Recording Completed.  Error saving recording.  Selected
>>>>> after
>>>>> >> recording action "Close Audacity" has beencanceled due to the
>>>>> error(s)
>>>>> >> noted
>>>>> >> above."
>>>>> >> Now for a start what on earth does that mean or convey to the user
>>>>> about
>>>>> >> what really went wrong?
>>>>> >>
>>>>> >> But, more importantly, the user should be *prevented* at step a)
>>>>> from
>>>>> >> having
>>>>> >> the opportunity to overwrite any exiting Audacity project.
>>>>> >>
>>>>> >> Normal Audacity does not allow that.  If you try to "Save As" to a
>>>>> >> pre-existing project you get the error message:
>>>>> >> "Error Saving Project.  The project was not saved because the file
>>>>> name
>>>>> >> provided would overwrite another project.
>>>>> >> Please try again and select an original name."
>>>>> >>
>>>>> >>
>>>>> >> 5)  Thus far in testing I have not encountered any orphan files.
>>>>> >>
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Peter.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Mon, Mar 14, 2016 at 1:48 PM, Mark Young &lt;
>>>>>
>>>>> > mark@
>>>>>
>>>>> > &gt; wrote:
>>>>> >>>
>>>>> >>> Hi all,
>>>>> >>>
>>>>> >>> I have deleted the old builds from the website, cleaned my Audacity
>>>>> >>> build
>>>>> >>> directory and rebuilt the entire Solution.  The dates on the files
>>>>> show
>>>>> >>> as
>>>>> >>> today, so hopefully this time we will have the right version! ;-)
>>>>> >>>
>>>>> >>> http://www.tip2tail.scot/Audacity-tip2tail-20160314.zip
>>>>> >>>
>>>>> >>> Thanks,
>>>>> >>> Mark
>>>>> >>>
>>>>> >>> On 14 March 2016 at 10:41, Peter Sampson &lt;
>>>>>
>>>>> > petersampsonaudacity@
>>>>>
>>>>> > &gt;
>>>>> >>> wrote:
>>>>> >>>>
>>>>> >>>> OK then - back and ready for testing - but I'll hold off till Mark
>>>>> >>>> reposts his latest build
>>>>> >>>>
>>>>> >>>> On Mon, Mar 14, 2016 at 7:22 AM, Mark Young &lt;
>>>>>
>>>>> > mark@
>>>>>
>>>>> > &gt; wrote:
>>>>> >>>>>
>>>>> >>>>> Hmmmmmm, very odd!
>>>>> >>>>>
>>>>> >>>>> I will check later today what happened there.
>>>>> >>>>>
>>>>> >>>>> Thanks,
>>>>> >>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://audacity.238276.n2.nabble.com/Timer-Recording-Improvements-tp7572689p7572885.html
>>>>> Sent from the audacity-devel mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Transform Data into Opportunity.
>>>>> Accelerate data analysis in your applications with
>>>>> Intel Data Analytics Acceleration Library.
>>>>> Click to learn more.
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>>>>> _______________________________________________
>>>>> audacity-devel mailing list
>>>>> aud...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Transform Data into Opportunity.
>>>> Accelerate data analysis in your applications with
>>>> Intel Data Analytics Acceleration Library.
>>>> Click to learn more.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> aud...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>>
>>>
>>
>