Modular Architecture Initiative

Registration Scheme
Needs thinking about:
 * Modules in the Preferences panel.
 * What information should all modules provide? (name, description, version information, URL? ... )
 * Interaction between modules, if this is desirable

Need for an API

 * Modularisation before creating a well defined API will just mean even more work later to make those modules compatible with the API.
 * Considerable care is essential, otherwise we have risk of destabilising Audacity.
 * We should at least discuss the idea of start-from-scratch re-architecting, so we have a clean API, and clean internal structures. It's a major effort, but a ten-year-old codebase is ripe for such an effort.
 * This is not something to rush into, and really there is little point in actually moving things outside the main source until well after the API has settled down.

Specific Points

 * We should aim to get rid of the LoadModules function, as nearly everything it does is done better by the ModuleManager. The only reason it's still there is because it checks modules for specific scripting/panel-hijack functions, and ModuleManager doesn't provide a way to do this at the moment. It may be possible to just move all of this module-specific stuff out into the modules themselves, though.
 * TimerRecordDialog is a good candidate for making into a module since it has very few hooks into Audacity.

Stay on non-core features for now

 * Attempting to modularize any part of Audacity that is considered "a core feature" is a mistake. The core Audacity code is not ready for any kind of modularization initiative since we do not have a clean API.

End User Perspective
"'Equally important is working out how we present the idea of loadable modules to end users. That includes how we give modules a community rating so that users know how stable (or unstable) the plug-ins are'"