Talk:Proposal Reorganizing Preferences, Track control menu, and View Settings
James (talk) 17:47, 19 June 2015 (EDT): I like the ideas described here. I think the flexibility to have different parameters on different tracks has most value when Audacity also supports multiple views on the same track (without the workaround of making a copy). I am also keen to allow superimposed tracks, e.g. wavetrack drawn on spectrogram. Even if we don't implement that for 2.1.2 it is worth thinking about how we set the parameters for each layer when we have moved to layers.
- Paul: What do you mean by "layers"? Does that mean something like clips that can be dragged partly over each other, one hiding the other (which would have its uses)? Or do you just mean graphical superposition of views of one sound.
- James (talk) 05:03, 20 June 2015 (EDT): I mean graphical superposition of views (with optional translucency rather than just over-write). Separately I too would like clips that can be dragged partly over each other. I would still like to be able to set a max-overlap for dragging, which of course is currently zero. Clips then raises the question of whether one wants per-clip configuration.
Where do Parameters Belong?
The same parameter can be
- Audacity wide.
- Per User
- Per Project
- Per Track
- Per Clip
- Per View
- Per Label
It is close to being a hierarchy but not quite. It is crazy to use different mechanisms in Audacity for each different level. To keep the UI simple for beginners we need to be over conservative on the parameter granularity and have the default for each parameter being at a higher level than we experts might use. For example we could change the colors per-clip, but initially make the colors a global setting. Also the same setting at multiple levels may be confusing to users. We maybe need a setting (disabled by default) that enables settings being multi-level. With it disabled they are locked to their default level.
We also need to consider parameters that are expressions rather than constants. I may want all clips that are of me talking in blue, and all clips that are of my interviewee talking in red. That is possibly down to a separate mechanism for setting parameters in multiple objects, rather than for setting an expression as a parameter.
Reducing the total number of menu items without reducing functionality is generally a win. For example rather than menu items x1 x2 x5 x10 x50 x100 for magnification, a setting, or a +/- button or a slider can be better.
Menus can be long and shallow or short and deep. Configurable menus, e.g. for effects, may allow either choice, but there will still be a decision to make over the default choice. There is an argument that short deep menus must have configurable shortcut keys because they are less accessible. Configurable short cut keys are good. Even without them, short deep menus may be faster for navigation for VI users who already know the menu layout. Without shortcuts it may take 50 key strokes to reach the middle of a 100 element menu, whereas if it is split as 10 top level items each with 10 items in it, then it takes 11 key strokes to reach the middle.
One plan for audacity-4-blind is to enter audacity via scripting, rather than via customized wxAccessible widgets. Audacity-4-blind could have a customized command line to drive it. The mouse could be dynamically bound to specific values the user chooses. There would no longer be a need to click on specific positions on screen that a blind user cannot see.