Proposal Easy cfg Reset

From Audacity Wiki
Revision as of 22:09, 14 April 2011 by Edgar (talk | contribs) (A "Reset Preferences" menu command)
Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This proposal page is about adding a "Reset Preferences" command to Audacity.
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 Problem

The audacity.cfg file can become corrupt leading to unexpected behaviours in Audacity that can only be fixed by "initializing" the contents of that file to NewPrefsInitialized=1. Trashing the file is not an option as Audacity may read previously-installed 1.2.x preferences and that preferences file may be corrupt. So the user must edit the audacity.cfg in a plain text editor and overwrite the file in its original location without changing the file extension. On Windows and Linux the user must show hidden files in order to open audacity.cfg.

Additionally:

  • VST plug-ins can stop Audacity starting properly, so a feature within Audacity, for example menu item or preferences reset-button might not work.
  • Display preferences can leave Audacity not appearing, i.e. underneath other windows, so again features to resolve this within Audacity might not be enough.


The Proposal

An easy way for users to reset the audacity.cfg file to a clean state - in effect setting the contents to "NewPrefsInitialized=1" or filling it with the default values that Audacity would use on first launch when it finds an audacity.cfg file that contains only "NewPrefsInitialized=1".


Developer/QA Backing

  • Peter 14Apr11: this was discussed earlier by QA folk on the Forum where there was almost unanimous support for this (with a couple of partial votes): Bill, Koz, Bruno, Peter, Ed 0.75, Steve 0.5 - see this forum thread: http://forum.audacityteam.org/viewtopic.php?f=20&t=55282&hilit=reset
  • Gale: +1. It has been discussed before that thread above as well.
  • James: +1 on a reset button.
    • Also +1 on making VST safer and +1 on safe-mode after an abnormal terminate or on special-launch.
  • Ed: +1 on the general concept (the +.75 was for the offered implementation)

Details

A "Reset Preferences" menu command

Where does it go in the menu structure and how does it behave? What warnings are given and how are they worded?

  • There is consensus that some warning at least should be given.
    • A UI Q&A site has some recommendations about 'are you sure' wording. The gist is to keep it short, be specific and label the buttons specifically, not just Yes/No.

Current suggested wording:

Title: Reset Audacity Preferences?
Reset Preferences?  
[Reset|Cancel]

We could have a hyperlink to online help. Specifically NOT local help in case the location for that is messed up. Hyperlink won't help if the user does not have a normal browser, but could help many users.

  • Bill: I prefer "Reset" over "Delete". It's what we're doing, and I believe most apps use that word.
    • +1. So do I. James 16:53, 14 April 2011 (UTC)
    • +1 Ed

Alternative suggested wording:

Title: Reset Audacity Preferences?
Reset Audacity preferences to default values?
[Reset|Cancel] where Cancel is the default
  • James: A bit wordy? 'Audacity' becomes 'verbosity'? See the tip in the UX link.
    • Gale: I think a little "verbosity" could be needed until we have a help system or specific help button. Thinking about it, "Preferences" is a little misleading. Cfg covers more than what is exposed in the Preferences. "Restore default settings?"
    • James: Then for consistency we should change 'preferences' to 'settings' throughout.... to me there is not enough in it to make the change. Would having the help hyperlink I suggested be enough to mollify you over the shorter prompt?

A "Reset" pane in Preferences

The avoids adding another menu command at the expense of a new prefs pane. What would this pane look like? What would it say and what steps would the user need to perform in order to reset preferences.

  • Gale: I think a Prefs pane would look pretty bare with just that. If we want more than an Edit menu button, then this Prefs pane could have e.g. save a copy of current .cfg. (and reload it), a bit like a "Theme" - could be e.g. a particular set of floated toolbars; or direct editing of .cfg.
    • James: Another option, we could put it on a general panel.

Plug-in Safety

'Rogue' VST plug ins are a problem. It isn't the scanning for them that causes a problem, rather it is the loading of an incompatible DLL.

  • A framework with zillions of plug-ins, Eclipse, developed by IBM, has the concept of a textual 'manifest' that lists the plug-ins that the framework will load. If a plug-in crashes the framework, it is marked as don't load in the textual manifest.
  • Work is planned on a GUI plug-in framework for Audacity that will have exactly the same problem of rogue plug-ins. Audacity will create a manifest as a way to deal with this.
  • The effects menu can have an item 'more...' which only shows when additional VST plug-ins have been found (but not loaded). Clicking on 'more' could take the user to a dialog that allows them to review the found plug-ins and possibly load them all.
    • Gale: This looks mainly outside the terms of this proposal as worded. We do need a plug-in manager that lists the effects that are loaded/loadable and can selectively enable/disable them (or disable selected paths). But scanning is expensive for Audacity and user, so once scanned I think all plug-ins must be available by default. Manifest to block forbidden plug-ins sounds a good idea but blocked plug-ins should be marked in red in the user-accessible list (i.e. whose main data is plugins.cfg).
    • James: So I've added a new issue for it. If we need to discuss that issue we can do so here and later cut and paste to a new page if there is a lot in it. There is anyway likely to be a proposal page for GUI plug ins in due course so the more advanced extensions of plug-in management will go there, and probably subsume VST plug-in management and safety.

Some kind of 'reset' before getting into Audacity

To handle the 'additionally' case (where the user might not successfully launch Audacity due to VST and other .cfg issues):

  • Googlable i.e. online help that explains how to delete the config/remove the problematic VSTs is a partial solution. It has to have the symptoms as far as a user is concerned', or they will not find the help. It should also explain what is going on.
  • If Audacity was exited unexpectedly, i.e. was started but was not closed properly, we could/should start in safe mode. That could mean disabling all plug ins, disabling simplified-audacity, using English language, default positioning and showing of toolbars and similar measures.
    • Gale: +1 but since this sounds as if there would be a dialog to inform the user, a dialogue with "safe" or "initialised" cfg options could also appear on CTRL + execute the app (or Option - execute on Mac). Maybe a command-line switch on Linux? If the interface solution is only to be basic we might be able to get by with just this "reset at launch".

Discussion

  • James believes that we should address cases of fail-to-start actually within Audacity start up.
    • We should not be killed by dud VST plug-ins when not using them. We will need this kind of protection when we have other kinds of plug-ins too. In general we should not load plug-ins merely because they are there - so we should have a mechanism to show plug-in effects on the menu and delay loading the DLL until the effect is used. That's just one example.
  • Bill If Audacity starts and finds no, or an empty, plugins.cfg it will scan for VST effects, regardless of the setting of the "Rescan for VST effects" preference. This is convenient on first installation as Audacity will load all the user's VST effects. It's bad if Audacity chokes on a particular VST and crashes.
    • Gale: To clarify (well on Windows), if there is no or empty plugins.cfg and audacity.cfg has:

        [VST]
        Enable=0
        Rescan=0

        then Audacity will not scan for VST plug-ins. It will if those lines are "1" or missing.
    • Options to deal with this:
      • Only scan for VST effects if the user specifically asks (by setting the Rescan preference)
        • Bad side effect: "Why doesn't Audacity find my VST effects?"
        • Gale: Probably an unacceptable side effect.
      • Hold alt/option on launch to disable all effects (except Nyquist?)
        • Shortcoming 1: the problem may not have to do with effects
        • Shortcoming 2: a bit esoteric, and not discoverable.
      • Hold alt/option on launch to reset preferences and disable all effects
        • Shortcoming: the problem may have to do with effects and not any of the other prefs that will be reset
        • Gale: Or that and more is in James' safe mode.
      • Gale: Would an aggressive timeout per effect help?
        • James: Please clarify. A timeout on loading each effect? We can do more to be crash-resistant on effect loading, but crash-proof isn't possible. A rogue effect can always write anything anywhere in Audacity memory and so cause crashes later. A time out on effect loading won't stop that. An extreme solution is for Audacity to launch a separate test program (that might crash) to load and test each VST plug-in, before Audacity risks loading it itself. Only the test program crashes, not Audacity. That's more work than I think we are likely to do. Anything less than that is in Audacity's workspace and could crash Audacity.