Talk:Proposal Easy cfg Reset

Thanks for starting this - our current best shot at working around bugzilla limitations. James 15:34, 14 April 2011 (UTC)

What Gets Reset?

 * Gale: I'm still concerned about the "settings" / "Preferences" distinction. I think the important extras in settings are open/export file paths, recent files and toolbars but those are going to be important to people. Even if the Prefs button said "Restore default settings", it's inside the Prefs so could easily be taken as only meaning what's in the Prefs window. I think my vote would go for an Edit menu item, maybe "Clear all settings" or similar unless the Prefs button text is much clearer. How about "Initialize .cfg" or "Initialize .cfg file" (with link)?
 * James: But we are also going to get people who don't want to lose some presets... Resetting preferences is pretty drastic, and really I think to solve the issue at hand we need to reset everything.  We can't add a smart reset that just resets anything that might be a problem - though that is what we want if we could.  Logically the preferences panel should contain ALL settings.  We could add a panel with information such as '15 built in effects have user configured presets', 'default export path is...', '7 toolbars have user configured positions' and so on.  Then preferences and settings are the same thing.  I don't want to be explaining to users that preferences and settings are two different things.
 * Gale: There are possibly two different objectives. 1) "Return (currently listed) Prefs. to defaults" which is a quite common feature we don't have. 2) "Initialising the .cfg" which resets more settings and is needed to cure a corrupted Prefs file (or reset some setting that has created an issue). As I stated in bug 358, perhaps another issue we should consider is how the .cfg file gets "corrupted" and why/how this affects program behaviour. Should Audacity check the syntax of the .cfg contents and try and "repair" it?  We know there are cases where user claims to have never even known about Preferences; yet initialising .cfg solves the problems. As for presenting to user, yes I quite like the idea of a panel that lists all the other current settings, whatever we decide about this Proposal. I still feel a high proportion of users will not realise the implications of initialising .cfg if we put our control in Preferences (however we label it and whatever Prefs contains). That's why I think initialisation is better done outside the interface (if that's possible). It also solves the "When?" problem (next section). There is an argument that doing this outside the interface might be less discoverable. However I don't feel many users will consider resetting preferences (in reality, initialising .cfg) as something likely to help. They are far more likely to pointlessly and repeatedly reinstall the app. So if we had a "repair.exe" they would I think discover that very easily and understand this might "start from scratch".

When Reset?

 * Gale: Will Audacity restart itself when this button is pressed or when Prefs is OK'ed? Also I wonder if a checkbox isn't better so you can see the current state (warning appears when you check the box)?
 * James: I don't know. It depends on who implements it.
 * Gale: This raises when do we reset? If we don't restart Audacity, that gives user the chance to change their mind if we have a checkbox (unless requesting the reset already resets the preferences in the dialogue, so that if you did not restart you would e.g. be warned about all actions again). I guess it's easier for user to understand if requesting reset does the Prefs reset at once?

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.
 * Ed+1
 * 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".
 * Ed: A bit of work, but doable--we can have a separate script/app which cleans the 1.2 registry entries and/or initializes audacity.cfg (and if desired plugins.cfg). I vaguely understand how on Windows but know nothing of Mac & Linux!

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.

Discussion
[VST] Enable=0 Rescan=0
 * 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:

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.
 * Gale: Yes a timeout on loading. I was thinking more of slow loading effects than crash prevention, primarily extreme slow loading of third-party Audio Units. Slow loading can be a predictor of crashes though.