Effect modules

[Paul-Licameli]

Resolves: (direct link to the issue)

Depends on

• #6221

Take user interface for the various third-party effect protocols, Vamp, and Nyquist out of the executable.

Take out the built-in effects and analyzers (but not the non-modal dialogs in the Analyze menu).

Audacity links fewer third-party libraries.

The graph of modules will be thus, with one new cluster, and addition to the Nyquist cluster:

(short description of the changes and the motivation to make the changes)

• [x] I signed CLA
• [x] The title of the pull request describes an issue it addresses
• [x] If changes are extensive, then there is a sequence of easily reviewable commits
• [x] Each commit's message describes its purpose and effects
• [x] There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

• [x] Each commit compiles and runs on my machine without known undesirable changes of behavior

[saintmatthieu]

I understand that modules allow making some functionality shippable independently on the rest of the application. The only real use cases I know of would be closed-source modules or modules that are just too heavy to be shipped with the normal executable. The libraries this PR modularizes don't meet any of these two criteria. Could someone please educate me on the use of this PR?

[crsib]

Audacity must depend on libraries for them to work. This makes little sense for features like effects or importers/exporters. They usually register themselves using a well known Registry. They don't need to have any public symbols and Audacity doesn't depend on them.

However, if Audacity doesn't have a symbol that it imports directly from the library - it will not load it.

Modules are loaded at runtime and do not have this limitation. They clearly state, that they extend Audacity functionality, but not the set of public APIs

[Paul-Licameli]

Factoring functionality into modules shrinks the executable and its link dependencies on third party libraries. It enforces non cyclic dependencies as the program and module evolve. It could allow an advanced user to find the modules preference page and disable modules not needed for their work, reducing the program’s memory footprint and startup time.

It was already decided to put each import/export format in its own module. Why not do the same for each effect protocol?

This is work I did in 2020-2021 still waiting for merge.

[saintmatthieu]

I can make sense of that, thanks for clarifying. I see that this PR also modularizes the built-in effect framework. Isn't that a bit too much, though?

[Paul-Licameli]

I can make sense of that, thanks for clarifying. I see that this PR also modularizes the built-in effect framework. Isn't that a bit too much, though?

It is not true that it modularizes the "framework" of built-in effects.

This PR only moves all the definitions of particular effect subclasses.

I don't think it is too much. What ends up remaining in the executable -- that is isolated as the difficult stuff still needing its rewrite for toolkit neutrality.

[Paul-Licameli]

I would like @crsib ’s concurring opinion of this PR first