Talk:Notes for Testers

From Audacity Wiki
Revision as of 14:01, 6 May 2015 by PeterSampson (talk | contribs) (report on c487b92 testing for Steve)
Jump to: navigation, search


  • Thank you to people who added to the main page.



  • James 01May2015:
    • The crash is terrible, and I think I know why it happens and what to do about it. We may be able to leave effects open.
    • 'More...' being too far down is (in my opinion) a fault of having too many effects at the top level, which is already a problem. More... reduces that problem very slightly as it makes it easier to have fewer effects, just the effects you use. I can put moving it to the top of the menu (possibly with a different name such as 'Manage Effects') to a vote on quality. It is not at all obvious/discoverable that you would look on a toolbar to do this.
      • Gale 02May2015: I think it's probably a misuse of Register Effects to use it in lieu of Menu Munger/Effect Favourites or some other Effect Menu organiser/grouping tool. Most users after first installation of Audacity will probably full rescan rarely. What they want to do IMO is add their new plugin(s) and ideally have them autodetected without restart or without need to select them, or autodetected on restart (definitely with an option not to have to select them). If they need to select them if not restarting, they do not want a default complete list to wade through to find what they added (or to hit OK and wait for un-necessary rescan of all).

        Those who have decided to hide some built-in or plugin effects as menu-management will mostly want to retain their existing subset for display, so showing the complete set selected by default (over-riding their current subset) does not seem helpful. Of course there may be interface changes planned but this does not look ready for 2.1.1 to me in the time we have.

    • James: It is possible to get the 'More...' good enough by the planned dates and I am convinced better than having the effect list right at the start. It is a poor man's menu munger (not enough time for that). When fixed it should be able to add and remove effects and open showing what you currently have selected.

      I'd be OK with adding More... to each of the effects, analyse and generate menus. Some plugins we won't be able to tell which list they belong in until we have loaded them. We can at least do it for any plugins we ship ourselves.


Peter 01May15: Following testing (on Windows 7), I have a few concerns about speed control with scrubbing:

1) I am concerned about the use of the setting of the transcription toolbar to set the initial scrubbing speed. For a start is not easily discoverable and it is not intuitive either. Furthermore users may wish to use Transcription Toolbar with their favorite setting for transcription play and not want to have to change it for scrubbing usage.

  • Gale 05May15: It has been suggested we could move the Play-at-speed slider into Transport Toolbar to make the connection (if we want it) more discoverable.

2) If the Transcription Toolbar is to be used to control that initial speed then surely as the user spins the mouse wheel when scrubbing to increase decrease the scrubbing speed than those changes should be reflected in the Transcription Toolbar GUI - i.e. the two should be properly linked not just casually linked. But note that the mouse wheel offers a greater speed range than the Transcription Toolbar.

  • Gale 05May15: I think it would be better not to have the wheel move the slider - the slider speed would remain as the starting speed of the scrub if we want that. I think it would be simpler to have the scrub speed always start at 1x. If we want to add a feature where the slider speed sets a different start speed for the scrub, let's think more about how to integrate the slider into Transport Toolbar and how we want to set a non-unity speed.

3) When rotating the mouse wheel while scrubbing to change the scrub play speed it is nigh on impossible with normal human dexterity to achieve the maximum and minimum speeds that are available to scrubbing - as once the centre button (wheel) is clicked and held down to facilitate scrubbing the rotation available while holding the wheel button down is minimal.

4) IMO the outer available extreme speeds are too extreme and probably not very useful to the user. At speeds greater than 5x for example it stutters in scrub play. The same lack of usefulness can actually be said of the low-end extreme for Transcription Toolbar, try it at 0.1x for example.

  • Gale 05May15: The stutter is a bit worrisome as I have no stutter at all on my 64-bit Windows machine at any scrub speed from 0.1x to 32x.

But having said all that I must say that the underlying technology here seems to be holding together very well - so props and kudos to Paul for that.

Also I must say that while I know that Gale has some misgivings about the backwards play I actually like it. And it is sure to delight those who were brought up in studios rocking reel-to-reel tape past the tape heads.

Paul L 01May15:

  • My intention is to change scrubbing to start with ctrl-(double-)click, not drag, and stop if you do that again or if you do anything else that would stop normal play like spacebar or the stop button. Then you don't need pressure on any button to control scrubbing and it should be easier to roll the wheel.
  • The interaction with Transcription is dispensable. I thought it was a good idea to have an easy way to specify your starting scrub speed limit to be other than 1 without going to Preferences.

Peter 02May15:

  • Personally, if you do change the interface I would also like to be able to additionally retain the mouse wheel click and drag too. As a temporarily one-armed person I found it useful to be able to access the scrubbing without access to a modifier that would require my out-of-action left hand. It may mean that we consider releasing it with the current UI and then change the UI for 2.1.2, but for my money I would prefer not to do that - unless we retain the mouse wheel/drag gestures in addition to your new "intention" UI - that could work.
  • If you do provide a UI where the mouse scroll wheel can be rotated more freely as pressure is not required on it - then I think it is far less necessary, indeed unnecessary, to provide a starting speed other than 1x - thus negating the need for reliance on the Transcription Toolbar or additional Preferences (additional Preferences are usually frowned upon).

Gale 05May15: I'm inclined to agree with Peter that for those with a middle mouse button, a single- or double-click on that button then release to initiate scrub (then being able to scroll the wheel without holding it down) will probably be thought more convenient. We may have to provide duplicated methods with or without middle button, but it's probably the right thing to do. Speed change other than with the wheel - however we do it - is likely to be more uncomfortable and less flexible.

Paul L 03May15: I had hoped to change to ctrl-click much sooner as at least two votes on the team were against middle click, but then my computer croaked and the shipment of my new one did not arrive at the promised date. And it is rumored not to work well on two Macs, which I can't debug on. If all this means it is too late and risky for 2.1.1, so be it, sadly. I can hope for 2.1.2.

Peter 03May15:

  • My "mystery shopper" (Mrs S) doesn't much like that use of the mouse wheel either, particularly the double middle click. She commented that she had never encountered that in any another application that she uses. She also commented that holding the wheel down while simultaneously rotating the wheel and dragging the mouse was an extremely difficult skill to manage ("requires the skills of a drummer" she said).
  • Question: is your proposal to use Ctrl+click a good choice for Mac users. For example Bill wrote in the Quick_Play section: " 'CTRL' should be translated to 'CMD' on Mac but it is not. One cannot use 'CTRL + Left-Click' on Mac since that is the system binding to display the context menu (or, equivalent to a right-click)."

Paul 03May15: Ctrl or Cmd - left click already does something (start or resume playback at the click) but that is redundant with clicking in the time ruler, so it was agreed it would be all right to repurpose it for scrubbing.

  • Gale 05May15: COMMAND - click in the waves to perform Quick-Play works on Mac now, the bug is that it does not work in the Timeline.
  • Peter 03May15: It is "potentially" redundant with the improved Timeline behavior of Quick-Play. The key advocate for retaining it previously was Gale, I'm not sure that he has finally agreed to relinquish it yet, as far as I remember he said he was minded to consider it. @Gale: what is your current position on this?
    • Gale 05May15: As long as there remains an option to draw a vertical line from the Timeline down through the tracks, I can live with CTRL + click toggling scrubbing instead of Quick-Playing, but Timeline Quick-Play remains less convenient than waveform Quick-Play if you are working on a track at the bottom of the project and have to move the mouse up to the Timeline.

      I was a fan of the previous scrubbing attempt (apart from the messing with the selection). I could CTRL-click Quick-Play in the waves, *or* scrub (by holding the left mouse button down). The disadvantage with requiring to hold the left button down is that it is then much harder to use the middle button to change speed (or to zoom).

      I know that you can use SHIFT to move the playhead to the pointer and so combine scrub with Quick-Play that way. Unfortunately there are two major issues with that:

      • SHIFT currently takes too long to respond
      • because we have backwards play, playback stops when the playhead meets the pointer, requiring dragging the mouse to resume playback, or using the harder to initiate double-click scroll scrub.

      Backwards scrub is great fun, but if we have the option I requested to disable backward scrub then SHIFT becomes much easier to use because (forwards) playback could automatically resume as soon as the playhead met the pointer. If we get that option and SHIFT is made responsive I will be 100% for removing CTRL-click Quick-Play.


  • Peter 04May15: Tested FLAC export on Windows 7 Home Premium 64-bit, export worked fine. Re-imported the file into a new Audacity project also worked fine.
    • Gale 04May15: Thanks, Peter. Just to double-check, did you check 24-bit as well as 16-bit, and did you check that the seven standard metadata fields were present in the re-imported file? To check, File > Close before reimporting the file.

Timeline Quick-Play

Peter 06May15: Steve's changes in commit c487b92 "Improve selection handling in Quick-Play " appear to work well on W7 HP 64-bit

Steve requested testing on:

  1. "The main change here is that selection dragging is deferred until the mouse is clicked and dragged in the Timeline. This allows quick-play to be instigated at the same point multiple times without losing the current selection. Grabbing an end of the current play region should now be more accurate and robust."
    • The Quick-Play selection can now be moved from either end without losing the TQP selection. Grabbing the end does appear to be more robust.
  2. Please check if "Cut Preview" in Quick-Play now works on all platforms (I've only tested on Linux).
    • "Cut Preview" in Quick-Play works well on W7 - I was bold and tried Ctrl+Shift+Click+drag in the Timeline and was pleasantly surprised to find that it happily loop-played the cut preview.