Completed Proposal Timer Record Improvements Phase-1

From Audacity Wiki
Revision as of 11:24, 25 February 2016 by PeterSampson (talk | contribs) (Details: Progress box resize completed)
Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This page is a proposal to improve Timer Record
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.


  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.

The Problems

There are many existing feature requests lodged in the Wiki relating to improvements to enhance the usability of Timer Record. For example:

  • AS TR is normally "unattended recording" an automatic Save on completion would be useful.
  • The current implementation of Timer Record operates as an "unattended recording" rather than a proper timed recording in that most of Audacity's recording controls are unavailable to the user once a "Timer Record" has been initiated. In particular the levels cannot be re-adjusted once Timer Record has been initiated but also but also the zoom level and resizing of tracks cannot be accessed. Also labels and markers cannot be dropped. This is a prominent feature request (see below).
  • TimeText controls do not interact intuitively with the Date controls.
  • It is possible to set a timer record event that will cause disk overflow.
  • The Cancel button in the "Progress" box can be dangerous and non-intuitive for users, causing them to lose data. (Fixed by Vaughan for v2.0.1.)
  • The "Progress" box is un-necessarily wide, inconsistently so compared with other Audacity progress boxes. (Fixed by Leland Presumably as part of his wx3 widgets work)
  • A Multi-event scheduler like a VCR or PVR

Proposed Features

  1. Add optional forced Save or Export on Timer Record completion.
    • 2.1.0 has an automatic/forced Save - the interface could benefit from improvement
  2. Improvements to the "waiting to start" dialog
  3. Re-size the "Progress" box smaller. (Fixed by Leland Presumably as part of his wx3 widgets work)
  4. Error handling (or warning) on potential disk full.
  5. Improvements to the time data-entry spinner controls.
  6. Add a Timer Stop to be available for manually initiated recording.
  7. Timer Record to enable access to the normal set of recording controls.
  8. Add a multi-event and repeat-event facility.
  9. Remove the Cancel button from the Progress box (still allow power user to cancel with window Close or ESC) (Fixed by Vaughan for v2.0.1.)

Developer/QA Backing

  • Peter Sampson: I no longer support access to the "controls" when Timer Record is active, as Steve pointed out on the Forum "Using TR, Audacity (rightly) locks you out, which prevents you from doing something that will mess up the recording" - this safety net is useful and valuable. I also no longer support the "Multi-Event Timer" as technology has moved on a bit since the proposal for this bit was written. Most PVR's will enable you to tune in to and record with multi-event timing radio programmes - and there are devices available that will reliably capture web "radio" broadcasts in multi-event mode (my Cocktail X30 is a good example).
    • Gale 25Feb15: I think the lockout while recording is over-enforced. I can see no good reason to dispense with metering and access to Mixer Toolbar. Perhaps, input/output sliders should be available in both the Waiting to Start and Record Progress dialogues. Perhaps a button in the Record Progress dialogue to Add Label at Playback Position.
  • Gale: Am in agreement with the general thrust of improvements here especially removing the risk of naive user cancelling an in-progress recording which removes it from the project.

Use Cases

  1. User sets up an overnight recording, some time after TR completion the computer crashes (or is rebooted by Microsoft due to updates). User then has to resort to Recovery.
  2. Access to controls: User uses Timer Record while they are active on their computer (on other tasks) so that they do not forget to start a live FM broadcast capture from the radio at a time in the future. In that case they need access to the recording controls.
  3. Timer Stop: User has activated a long recording process manually and then has to leave the computer unattended. Timer Stop would provide a safety measure so Audacity does not record endlessly until the hard drive is full and the recorded session becomes jeopardized.
  4. User is restricted to a single event timer - users will be familiar with the use of VRC/PVR all of which have multi-event and repeat-event timer functionality, and so expect similar in Audacity. Necessary for capturing audio while away on vacation/business trip.
  5. Once timer record has been invoked by a user all other use of Audacity (in different windows) is blocked.
  6. User unexpectedly needs to go out having manually initiated a recording, needs to set a stop time to prevent creating a very large project or disk overflow.
  7. Users find the spinner data-entry for time values to be confusing and un-natural, causing incorrect entry values.
  8. User inadvertently enters an erroneous date causing a timer record event for which there is insufficient disk space.
  9. While Timer Record is recording, user erroneously presses Cancel to halt the recording then presses record, their original one-off recording is irretrievably lost. See this thread in the forum. (Fixed by Vaughan for v2.0.1.)
  10. The "Progress" box is un-necessarily wide and thus has much empty gray space which adds nothing and is visually un-pleasing.

Details

  • Optional forced Save or Export on Timer Record completion: (If the Multi-event scheduler is not implemented) add tools to optionally auto-save/export and optionally close down the computer and/or input stream. Would require extensions to the setup dialog box.
    • An option to auto-save or auto-export at successful completion of the recording event, to a user-specified name and location (and specified format for export). Would need to be specified at event set-up which would require extensions to the setup dialog box.
    • Optionally disconnect the internet stream (if appropriate) on successful event completion.
    • Optionally shut down the computer on successful event completion.
  • Peter 24Feb15: For 2.1.0 Vaughan has provided an automatic Save on TR completion if the user has Saved the project prior to starting the timed recording, otherwise on completion the user is invited to make the save. This interface need a little more work for the next release as the behavior is somewhat opaque and not very discoverable. This recent Forum thread has discussions which relate to this.
    • Indication (text probably) on the set-up dialog that the user must have pre-saved the project to get an automatic forced save (aids discoverability)
    • Checkbox/radio button to turn on/off automatic forced save, default "on" if project is pre-saved, otherwise "off"
    • If no project pre-saved and user sets the checkbox/radio button to "on" then Save dialog appears on successful TR completion
    • Automatic/forced export: If, and only if, the user has a pre-saved project then a further control to be displayed facilitating an automatic forced export on completion. This could either always be WAV format - or maybe the user could choose through a drop-down menu. Filename and location for the export location to be derived from the pre-saved project.
    • Possibly add a "Save Project" button in the TR dialog, with a note saying that saving the Project will effect an automatic save of the recorded session on completion.
    • On successful completion of the forced save and/or export, a message to be displayed showing the user what was saved and where at.



  • Waiting for Start dialog enhancements:
    • Add duration and scheduled stop time, above the progress bas
    • Rename "Remaining Time: hh:mm:ss" to "Recording will commence in: hh:mm:ss"
    • Remove "Elapsed Time: hh:mm:ss".


  • Re-size the "Progress" box smaller
    • The "Progress" box is un-necessarily wide at 22 cm
    • Reduce the width of the "Progress" box to 10.5 cm to match the width of the "Waiting for Start" box
    • This would still leave the progess bar wide enough to be useful (cf. progress boxes for Effects and Analyze tools which are only about 8.25 cm wide).
      • This has been completed.


  • Error handling (or warning) on potential disk full situation
    • When a single Timer Record event is created (or set of Timer Record events if the multi-event feature is added) that would exceed the potential remaining available record time that Audacity calculates (and which would lead to a full disk and a failed recording) generate either an error message (or possibly a warning to enable the user to free up disk space).


  • Improvements to the time data-entry spinbox controls
    • Simplified spinner controls for time entry with hh:mm only (I doubt that anyone uses seconds except when testing).
    • hh (and mm) to be a single field rather than separate digits of units and tens. Thus the up/down arrows would operate on hh (and mm) as an entity.
    • No ripple-through interaction from the hours field to the date field.
    • No ripple-through interaction from the minutes field to the hours field.
    • The minutes field to be limited to its logical maximum of 59 minutes.
    • The hours field to be limited to its logical maximum of 23 hours.
      • Gale: There are at least two cases where the Start and End spinboxes interact unintuitively with Date:
        • You cannot type a spinbox character that results in a time in the past; the input is ignored and the selected digit is advanced. In particular there is a clearly expressed expectation that setting hours to the past would advance the date forwards.
        • The hour spinbox increments the date perfectly in a forwards direction by typing or up arrow (even incrementing by a day and changing hours to "07" if you have 21 hours and increment the "2" to "3"). However incrementing hours backwards with down arrow does not move the date backwards when you reach "00" hours (even if the previous day would still be a time in the future); moreover a further down arrow from "00" hours zeroes all the digits.
        • The above are not apparently bugs but arguably reasonable behaviour for TimeText controls as used in Selection Toolbar. Perhaps these are not good behaviours in a Timer and may suggest using another type of control integrated with the date. Or perhaps time controls should increment date backwards and a time in the past can be set, but it greys out OK.


  • 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.
    • Store last-used settings to facilitate recording on a daily or weekly basis.


  • Ability to minimize the Timer record Window
    • Timer Record to behave like a proper Windows window so that it can be minimized to the Applications bar with the minimize button in the Audacity window.
      • Gale: Bug 104 relates to this.
      • Gale: It would be quite odd on Windows to be able to minimize an app having a modal window (though Ubuntu allows it). So making Timer Record dialog modeless (for the current project) would be one solution.


  • Controls: Timer Record to facilitate availability of all the normal set of Audacity recording controls:
  1. use of the sliders to adjust the signal level
  2. zoom in/out,
  3. change the track size,
  4. drop markers with Ctrl+B and Ctrl+M,
  5. change the waveform display type,
  6. rename the track
  7. pause and un-pause recording (Note that this merely temporarily interrupts the recording; it does not extend the recording time.)


  • Multi-event scheduler: Timer Record to be enabled to set multiple timed recording events.
    • Existing dialog box should easily accommodate this with some minor upgrades (see below).
    • Would need to check for and block any recording overlap.
    • Would probably require an additional window listing the queued recording events with tools to manage and manipulate the event entries. This would also apply to a single, sole, event.
    • Would really require an auto-save at the successful completion of a recording event, to a user-specified project name and location. Would need to be specified at event set-up which would require extensions to the setup dialog box.
    • Some users may prefer to force an Auto-Export to WAV format, to a user-specified file name & location, on successful completion (in preference to Saving a project). We should endeavour to accommodate this. Would also require extensions to the setup dialog box.
    • Repeat-event functionality to be added to the setup dialog to enable recording events at regular repeat intervals (e.g. daily, weekly, etc.).


  • Remove the Cancel button from the Progress box
  • (Fixed by Vaughan for v2.0.1.)
    • Simply remove this button from the box
    • The box has a de facto cancel already in the X in the top-right corner
    • A second de facto cancel is available by use of the ESC button
    • User can achieve the same effect by using the Stop and then optionally deleting the recorded track if required (this is safer).


GUI Examples

TBP



=======================================================================================================

Previous Feature Requests relating to this proposal

Correct as at Jan 2012.

Timer Record enhancements

  • Many of the below requests could be implemented (I think) by enabling automation support for tcp/unix sockets
    • Multi-event scheduler (19 votes) for future recordings (like a VCR), not just scheduling a single recording for now
    • Access to progress or record controls:
      • Both dialogs should be modeless for current project, allowing access to same controls available during standard recording (14 votes) This lets you change levels, pause manually, drop a label, zoom in/out or resize tracks. Paragraph 2) above refers to this
      • Waiting for Start dialog should be modeless for all (or at least, other) projects: (4 votes) allowing to work normally until recording starts
          This raises all manner of issues about what happens if user is in the middle of playing / exporting when recording is due to start.
      • Change/extend recording stop time during record or waiting to record (4 votes)
      • Stop a manually started recording automatically (2 votes) by extending recording stop time in Timer Record - use case "something unexpected makes me have to go out"
          Could be considered user error not to have started Timer Record in the first place, though lack of access during Timer Record might be discouraging its use. However this requires more menu access than is currently allowed during recording. Can be achieved if user scripts a scheduled task before leaving, or it "would" be possible with Audaremote on Windows except it does not recognise the Audacity Beta window title.
      • Some method to close the timer without stopping it - Cancel? (2 votes)
    • Perform system shutdown after recording. (7 votes)
    • More intuitive/simpler timer controls: (9 votes):
      • Type any hour before present time to stop timer/advance date: (5 votes) instead of input before present time being unintuitively ignored.
      • Simple set of independent combo boxes for start and end (2 votes) having month, day (both pre-selected), hour, minute and seconds.
      • More like a hardware timer: (2 votes) Get rid of "Duration" and "Dates" as editable controls and get rid of interlinking of start and end time
          Needs thought - the basic suggestion of "type an hour before present to advance date" (applied on top of current implementation) would only work well for advancing date by one day and moving only one of either Start Date or End Date. Maybe disallow typing in spinboxes to make it more obvious that incrementing already works like a hardware timer. This may imply not using TimeText spinboxes at all or modifying how they work.
    • Auto Save:
      • to a pre-defined project name/location set in an in-situ dialog (6 votes)
      • to a pre-defined file name/format and location set in an in-situ dialog (5 votes)
    • "Waiting for Start" dialog enhancements:
      • Add duration and scheduled stop time (2 votes)
      • Rename "Remaining Time" to "Recording will commence in: hh:mm:ss" (2 votes)
      • Remove "Elapsed Time" and Progress Bar (2 votes)
    • (Windows) Minimise Audacity while Timer Record in progress (2 votes) Gale: Bug 104 relates to this.
    • Store last used settings to start recording on a daily basis (2 votes)
    • Disconnect internet stream as well as stop the recording (1 votes)

New/Modified Preferences

    • Timer Record Duration (3 votes) - although Timer Record now remembers its last duration across sessions, a "use default/use last value" preference would allow flexibility to change duration in Timer Record for specific purposes but still have it initialise back to the most commonly required default.