Proposal Reorganizing Preferences, Track control menu, and View Settings

From Audacity Wiki
Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This proposal is about per-track setting of spectrogram parameters and related changes, such as a shortened Track Control Panel dropdown menu including a "View Settings" item. This proposal also bears on another Proposal about the best way to enable and disable spectral selection.
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.

Problems

  • There are unexploited opportunities, in track controls and vertical rulers, for more right mouse pop-up menus to aid discovery for users new to Audacity and expecting an interface more like other applications.
  • The overlong Track Control menu can be faulted for many reasons.
    • Intimidating for the new user
    • Too hard to read with its many often gray items
      • One view type is always gray -- the chosen one, confusingly.
      • One or another half (roughly) of the choices in the section for channels is always gray, because some apply only to stereo tracks, some to mono.
      • All Move choices are gray and waste space if you only use one track at a time, as the novice likely will.
    • Too long for easy dragging of the mouse or use of arrow keys
    • Inconsistent style for showing mutually exclusive choices
      • Radio buttons for mono channel type, format, and rate
      • Graying-out for track view type
    • Too many letters are taken for keystroke accelerators, resulting in several choices hard to remember and hard to locate visually.
  • We want a better way to turn spectral selection off to avoid confusing the user, but also keep the feature discoverable for the sophisticated user who wants it. There should be a checkbox, but there is no good home for it yet in menus and dialogs.
    • The 2.1.1 solution involves making spectral selection enablement part of the view type, doubling the track drop-down items for spectrograms to express a binary choice that is independent of scale type. This is inelegant. More criticisms here.
    • The more sensible solution would be to have a checkbox. But where? Putting it in the track drop-down would lengthen it less, but the choice would be uselessly present in waveform tracks. Putting it in Preferences would seem most sensible, but that buries the choice in a place not readily discoverable.
  • There are other useful spectrogram scales to be implemented, besides linear and logarithmic. The old menu organization, even without the doubling of view types for spectral selection on and off, still requires more menu length. So the choice of scale wants to be moved off the menu.
  • Pitch view could be easier to understand and use, and subsumed as a sub-type of Spectrum view, shortening the menu one item more.
    • Variation of vertical scale of the display, just as for spectrogram
    • Labelling the ruler
    • Allowing spectral selection
  • If you move spectrogram scale choice (and Pitch choice) elsewhere, as subsidiary to the major choice of spectrum type views -- then this suggests doing the same for the linear/dB scale choice for Waveforms, for consistency and for a still shorter menu.
  • Some Preference choices are unnecessarily global, not per-track. For instance the grayscale choice (or in future, more varied palette choices) for spectrograms should not apply to all tracks or none. But again, lengthening the drop-down to solve this is undesirable.
  • Some Preference choices related to waveform display styles are scattered among Preferences pages and menus. It might be argued these should moved to, or replicated in, one place that is more easily found by users new to Audacity.
    • Show Clipping in View menu
    • Bottom of dB range in Interface preferences (which could be decoupled from the choice for Meters)
    • Automatically fit tracks, Default View Mode in Tracks preferences
  • Effects of spectrogram settings can be seen only by opening and dismissing the Preferences dialog -- inconvenient if you want to find a good choice by trial and error.
  • The labelling of the ruler is coupled unnecessarily to the choice of scale for waveform, and shows only Hz in case of Spectrum while other information like musical pitch might be of use.
  • Zooming-in the vertical ruler is not independent enough for different tracks.
    • In case of waveform, there is independent variation of top and bottom of scale, but not for the dB bottom limit.
    • In case of spectrum, there is independent variation for tracks in linear view and tracks in logarithmic. But all tracks in linear have the same bounds, and all in logarithmic have the same bounds.
  • Choices affecting track views are not preserved when the project is saved, closed, and reopened.
  • The left pane of the Preferences dialog is perhaps too long.

Proposed Feature

Many more or less related but independent ideas for more rational organization, orthogonality, and discoverability of settings. You may +1/-1 the line items.

"TODO:" denotes items not yet addressed in the latest prototype, linked below.

  • TODO: Right mouse button anywhere in Track Control area, not hitting any of the other controls, will bring up the menu just as left-click on the track name does.
    Steve 22Jun15: What is the user benefit?
    PRL 22Jun15: Audacity needs more right mouse popups to be consistent with users' expectations formed with other programs. We have it for labels and meters and timeline -- why not more places? I rate this small suggestion as less important than the others.
  • Track Control menu with fewer items, and more mnemonic key accelerators once more letters are available.
    • One possibility (note that initial letters are all non-conflicting as accelerators, for English at least):
      • &Name...
      • &Move > (shortened name)
        Steve 22Jun15: It sounds as if this will require an additional click each time a track is moved up or down. Using the current shortcuts of Context Menu button ("CM") and "U" or "D" ("Up" / "Down"), a track may be quickly and easily moved up (or down) with two finders: "CM, U, CM, U, CM, U...." or "CM, D, CM, D, CM, D....". If "Up" and "Down" are in a sub-menu it will be significantly less user-friendly / convenient, especially when moving a track several places.
        PRL 22Jun15: Not necessarily another click -- a short hover to open the sub-menu, on Windows certainly. I think your "CM" means shift-M with default keystrokes. Yes, the keystrokes would become Shift-M, M, U/D, one more.
        Steve 23Jun15: I used "CM" as an abbreviation for the "Context Menu" key (see: https://en.wikipedia.org/wiki/Menu_key)
        PRL 22Jun15: I move tracks by clicking and dragging, which makes the sub-menu a redundancy, but of course one must consider accessibility. I also don't do it often, do you? I think lengthening keystroke sequences for infrequent operations should be a tolerable tradeoff for a less cluttered pop-up menu that is less intimidating to new users, and more mnemonic keystroke sequences for other commands, but maybe my opinions about what is a frequent operation don't agree with everyone's. Maybe your objection would be overcome by customizable single keystrokes for these sub-menu items, but I think that requires more code support than we have now.
      • &View Settings...
        Steve 22Jun15: Again I am concerned that quickly switching from say Waveform to Waveform dB then back again, becomes significantly less convenient.
        PRL 22Jun15: In my usage the important switch is between Waveform and Spectrogram. I decided I didn't like shortening the menu too much, and left that as a binary radio choice in the menu.
        PRL 22Jun15: I don't switch between Waveform and Waveform dB so often. But I am considering making that switch easy too, by a right mouse pop-up in the vertical ruler (which might be discoverable to new users, but might also need another shortcut key than Shift-M).
        PRL 22Jun15: I think it makes sense to treat the switch of vertical scale between linear and log (or others) as different from the more fundamental switch between spectrum and waveform. Just as (below) stereo-only Channels choices should be hidden for Mono tracks, spectrogram-only choices of vertical scale (there are more useful ones than the present two) should not be in the context menus for waveform tracks.
      • &Waveform and &Spectrum, as a radio group
      • &Channels > (showing completely different sub-menus for mono and stereo cases, avoiding lots of gray items)
        Steve 22Jun15: +1 for not showing mono track options in stereo tracks or stereo track options in mono tracks.
      • &Format > (shortened name)
        Steve 22Jun15: I'd be concerned that "Format" is less clear than "sample format". If it is necessary to shorten the menu item, how about "bit format"?
      • &Rate > (shortened name)
  • "View Settings..." will reuse Preferences code to bring up a dialog with only the relevant pages. Those pages will also appear in global Preferences, for setting defaults.
    Steve 22Jun15: -1 for including global setting in a "per-track" menu. The track provides the context for the menu and menu items should relate directly to that context. Including global options in context menu is inappropriate, confusing, and at odds with standard design principles.
    PRL 22Jun15: I have at least three objections to that principle here. First, I have long thought that Audacity makes some settings unnecessarily global, like spectrogram grayscale setting or window size and type. But they can remain in their familiar place in Preferences too, as default specifications, while also being overridable per-track: thus the duplication of dialogs makes sense.
    PRL 22Jun15: Secondly, once you allow that default but overridable settings make sense, it also makes sense that you might want to reload defaults or save a set overrides as defaults, even though in a context menu -- hence the "Defaults" checkbox, below.
    PRL 22Jun15: Thirdly, I agree that the enabling of spectral selection should be easily discoverable from the context menu (at one remove anyway, in View Settings...) -- the objection to putting it (only) in Preferences (which I would have much preferred to the present multiplication of view types) was exactly that. But -- oppositely to my first objection -- this is something I think should be global, not per-track as now. I do not imagine users wanting it to be per-track.
    Gale 22Jun15: I don't think Paul's ideas are bad or that we should be restricted by a context menu never being able to access clearly marked global settings. Whether the benefits of all Paul wants to do are worth the extra complication is another matter.
    • Steve23Jun15: including global settings in a local context menu goes against the principle of a context menu in every design guide that I can find.
      "A context menu offers a limited set of choices that are available in the current state, or context, of the operating system or application." https://en.wikipedia.org/wiki/Context_menu
      Gale 24Jun15: The very article you cite shows a Mac context menu for a file that has a menu option to set global view settings for Finder. "Screen resolution" and "Personalize" in the Windows 8 context menu in that article are global settings. Third-party Windows apps that attach items to context menus for a file or folder often have in their cascade a menu item that opens that app's global settings - examples are TortoiseSVN and Git extensions. My only objection is that a global item in a context menu should be clear that it is global.
      PRL: 23Jun15: What I am insisting on is that many of the settings Audacity now makes global, ought not be global. All the details affecting track appearance should be available for independent variation. Grant that, and your definition of "context menu" is not a relevant objection. The exception might be the spectral selection checkbox. On that topic, I would rather compromise with you and make that a per-track setting too, than keep the imperfect solution we now have, with extra view types and extra global variables in Nyquist.
      PRL: 23Jun15: But I admit you have a remaining fair objection. As proposed, global defaults can sometimes be changed from View Settings. I will revise the proposal.
      Gale 24Jun15: To me, "View Settings" sounds like global settings so perhaps we should think of another name. Making it easy to toggle Spectral Selection on and off globally, without having to go into Preferences, IMO far outweighs any benefit from allowing some tracks to have spectral selection on and some off. No one asked for or made a case for that. That said, we don't have to use the Track context menu to globally turn off spectral selection. It just makes most sense and makes it most discoverable to do it there.
      PRL 30Jun15: How about "Appearance..." ?
    • At most two view type choices: Waveform or Spectrum. All else now encoded in the drop-down choice will be in other menus or checkboxes in the pages. The selected page at time of last Apply or OK will determine the view type of the track.
      • Steve 22Jun15: +1 for allowing the options to remain open if it can be done without incurring usability disbenefits elsewhere.
        PRL 22Jun15: By options "remaining open" I hope you mean you like the Apply button, which the prototype has, but not that you want a non-modal dialog.
    • New Waveform page with choice of scale (at least)
      • TODO: choice of dB Range
    • Renamed Spectrum page (not "Spectrograms," if Pitch (EAC) view is not properly called a "spectrogram")
    • "Apply" button in each page, to commit settings changes and see their effects, but not dismiss the dialog
  • Enabling spectral selection will be by a checkbox in the Spectrum page, accessible in View Settings too but not per-track in its effect.
    • TODO: Other global choices like "Show Clipping" and "Show track name in waveform display" might be moved into the Waveform page.
      Steve 22Jun15: Global settings do not belong in a per-track menu.
      PRL 22Jun15: Again I ask, does the benefit of easier access and discoverability of all view-related settings trump that? Or, are some of these things unnecessarily global when they might be more usefully per-track?
  • Each track may store its own independent settings for anything mentioned in Preferences that is not global, or default its settings.
    • Settings that should not be (as now) global include spectrogram scale limits, Waveform db scale limit, color choices, window size and type and padding.
    • When the pages appear in "View Settings...", not Preferences, there will be a checkbox marked "Defaults".
    • TODO: (Advanced) How granular should defaulting be? Each page will have a checkbox, so a track might have default Waveform settings but independent Spectrum settings. Should there be further subdivision of each page into sections, and other Defaults checkboxes?
      • Vertical scale limits for Spectrograms might be convenient to individualize or default, independently of the rest of the settings. This would make zooming-in on the vertical scale behave more analogously with waveform views, where independence of tracks is the rule. The present behavior is instead that there is one setting for all linear spectrum views and one for all log spectrum views. Zooming one ruler changes the views of other spectrogram tracks with the same scale type.
        • Do that, and you should probably group scale type with the scale bounds.
        • Therefore: another static text box for Scale, enclosing another Defaults checkbox, a type drop-down, and two fields for top and bottom.
      • Analogously for waveform, a separate section for the db/Linear choice, and lower dB limit -- if there is anything else on the page.
      • Color choice on each page might be another section if it becomes more elaborate.
    • Turning "Defaults" on will load all default settings associated with that checkbox into the dialog. Turning it off will have no effect on the displayed settings.
      Steve 22Jun15: I'm not sure of your intent, but it sounds risky. Specifically, users cannot be expected to realise that changing a local setting in a track menu will affect global settings.
      PRL 22Jun15: Please try the prototype. The Defaults checkbox is in a prominent place at the top, and the Apply button is new. I think it makes sense, and the users who try Apply with multiple tracks open might figure it out easily enough.
      PRL 23Jun15: You have persuaded me that global settings may be loaded but should never changed in this dialog.
    • Apply or OK with "Defaults" on will save defaults, write preferences, and leave the track's settings non-independent.
    • Changing any setting while "Defaults" is checked will cause "Defaults" to clear and the track settings to become independent. Unchecking "Defaults" directly will do the same with no change of any settings.
    • Apply or OK with "Defaults" off will make the track settings independent, with effects on that track's appearance only.
    • Stereo channels of one track will always have the same settings.
  • TODO: spectrum/waveform choices, and any per-track view settings, saved and restored when project is reopened
    Steve 22Jun15: Please clarify.
    PRL 22Jun15: Clear now?
  • Pitch view and other spectral algorithms
    • Pitch will be independent of the Frequency Gain preference and documentation will say so. That it was otherwise, was just a bug in Frequency Gain from its beginning. https://bugzilla.audacityteam.org/show_bug.cgi?id=1041
    • The Pitch view can be transformed as here: http://audacity.238276.n2.nabble.com/More-understandable-pitch-views-2-1-2-tt7569845.html
    • Thus Spectrogram (maybe call it "STFT") or Pitch (EAC) will become a choice of algorithm in the Spectrum page, orthogonal to other choices. (Except perhaps to gray out gain, range, zero padding, and frequency gain settings for Pitch. With some work, strike zero padding from that list.) Future algorithm choices may include:
      • TODO: Reassigned spectrogram
      • TODO: All the other choices that are now in the Plot Spectrum window
  • Scale choice in each View Settings page
    • Waveform
      • Linear vs Logarithmic (don't call it "dB") will be a choice of scale. Bottom of dB scale will be a parameter, grayed when inapplicable.
        Steve 22Jun15: +1 for an option to show dB in the "linear" waveform view.
        PRL 22 Jun15: Did you show an implementation of this on the Forum once? Or was that just a mock-up image?
    • Spectrum
      • Log or linear (or other) is a choice of scale. Future scale choices may include:
        • Mel https://en.wikipedia.org/wiki/Mel_scale
        • Bark https://en.wikipedia.org/wiki/Bark_scale
        • Erb https://en.wikipedia.org/wiki/Equivalent_rectangular_bandwidth
        • "Undertone," if that is the right name? The output of the Pitch algorithm naturally maps a frequency to height a - b / f for certain constants a and b. It causes the "undertones" of any given frequency to be evenly spaced, just as overtones space evenly on the linear scale. Once vertical scales have been generalized, there is no special difficulty in mapping spectrogram onto such a scale, and in labelling the vertical ruler by that scale -- just as Pitch output can be mapped onto the more usual scales. The ruler could zoom and spectral selection could work. Is there any scientific or pedagogical reason to want to include this unusual scale?
  • TODO: Labels choice, independent of scale, in each View Settings page
    • Waveform
      • Level or dB (so let's not confuse terminology of "dB" labels and "logarithmic" scale)
    • Spectrum
      • Hz (no kHz choice, keep logic as now that adapts)
      • Bold decades (as now in log scale ruler), which make sense for not-exactly-log scales too like mel
      • Bold octaves? Which origin?
      • Pitch
      • I see dormant code in TrackArtist.cpp for drawing a little piano keyboard as the vertical ruler of Note tracks. It would be cute to enable that on wave tracks.
  • TODO: Merge with Luciano Boggino's color choices in Spectrum page -- his working prototype (which destroys the UI for the Zero Padding preference, however): https://github.com/LBoggino/audacity/commit/0c0280589308c8382820c39a265469ffc865b8a5
  • TODO: Color choices in Waveform page too, perhaps custom -- though there have been other theming proposals
    • Background, envelope tool background
    • Envelope lines
    • Peak or individual samples vs RMS color for non-mute
    • Same for mute (why don't we distinguish them?)
    • Clip lines
  • Repurposed right-click in vertical ruler
    • It does exactly the same as shift-left click now, so no loss of capability.
    • A menu instead that allows easy switching of scales, and
    • TODO: labels,
    • and makes the zoom in and out commands discoverable
      Steve 22Jun15: Assuming that these are "per track" settings, +1
    • How much else should be replicated in this right click menu? The Waveform vs. Spectrum choice?
      Steve 22Jun15: As it is a "context menu" it should only carry items that relate directly to the context of the track vertical ruler. If we have this then I don't think that the same settings should be duplicated in the track drop-down menu. It will be necessary to provide a visual hint that there is a right click menu associated with the vertical scale, such as a black "menu" triangle, or a tool-tip.
      PRL 22Jun15: Glad you agree. As mentioned above, though, we might need another shortcut key like ctrl-M to open this. Another possibility might be that when the Track Control is open, right arrow pops up this other menu -- just as when a main menu is open, right arrow opens the next menu instead. Be aware that I don't want the Waveform vs Waveform dB choice in the track control menu any longer -- I want it here instead.
      PRL 22Jun15: You are aware that View Settings... is meant to replicate the Spectrum/Waveform choice, and all these otherwise reachable scale choices, while also presenting other settings. That is redundancy but it makes sense as the less frequently used advanced control panel that lets you change everything related to the view.
  • TODO: No more "Meter/Waveform dB range" in Interface preferences
    • The available scale of Sound Activation level in the Recording Preferences page is also affected by this setting now.
    • The choice for tracks will be in the Waveform preferences page.
    • The choice for Meters will be separate and in the Preferences... accessible by right-click on the meters.
      • By the way, why "Preferences..." for input/output meters but not also for Mixer Board meters? Add another access then.
  • TODO: The left hand pane of Preferences should have some tree structure so it is shorter in collapsed state. Candidates for regrouping:
    • Extended Import under Import/Export
    • Keyboard and Mouse under Interface
    • Libraries and Modules and Directories under a new node (Environment?)
    • Playback and Recording under Devices, which is perhaps renamed Input/Output
    • Quality, Spectrum, and Waveform under Tracks
    • Collect Interface "behaviors" and Tracks "behaviors" in a new Behaviors subtree, with Warnings and Projects

Developer/QA backing

  • Paul Licameli
  • James Crook
  • Peter I like the idea of a shorter/tiered Track Control Panel dropdown menu. And of course I like "Enabling spectral selection will be by a checkbox ..." as that sounds like the "simple switch" that Steve and I have been asking for.
  • Gale: In general I like the ideas here but the items moved to cascades in the Track Control Panel dropdown will be less accessible than now. Thus I think this proposal should address being able to add shortcut bindings to any item in that menu, even if there are no bindings by default.
    • Paul: See my comments above.

First Prototypes

https://github.com/Paul-Licameli/audacity/commit/ab89806944222c6863098b1b1f0753ea35a17f04

Further Ideas

Related

https://wiki.audacityteam.org/wiki/Proposal_Menu_Reorganisation