Enable dynamic parameters

[Federerer]

This enables dynamic parameters in LiveSPICE, so there is no need to resolve a circuit after pot change. Current state is WIP, so there is a lot of stuff there that should not be here and needs to be reverted or separated to another PR.

TODO before merging:

• [x] Rebase on master
• [ ] Switch back to AudioPlugSharp nuget packages
• [ ] Merge a PR with changes to the ComputerAlgebra
• [ ] Switch to master branch of the ComputerAlgebra
• [x] Set the default value of the Dynamic property to false in all components.
• [x] Fix the failing tests
• [ ] Add a feature flag
• [ ] Do a code cleanup and add comments in tricky places
• [ ] Check for unwanted changes

[dsharlet]

If you merge master into this, we could at least consider merging this with Dynamic defaulted to false (and maybe not Browsable at first), then it might not be such a headache to track master.

[Federerer]

If you merge master into this, we could at least consider merging this with Dynamic defaulted to false (and maybe not Browsable at first)

That would be great. I wanted to set a default to false anyway, as it's a breaking change. Just did a second rebase, plus fixed some bugs related to initial conditions. I'm adding a checklist to the original description in order to keep track of the progress.

[dsharlet]

I think maybe the best way to go is peel off parts of this into separate branches that can be merged one by one. For example, adding the ability for components to Analyze as dynamic or not would be a good change to just make by itself. Just using the value of the pot during simulation but not actually hooking it up to a dynamic control seems like it shouldn't break anything and would actually exercise that code path, so it's not just dead code.

This is both how I'd prefer to work on the feature myself, and also how I'd prefer to review the changes.

[dsharlet]

Also, there is quite a bit of stuff in this branch that I don't recognize from last time I previewed this change. IIRC, it looked pretty familiar from the way I had it before giving up on dynamic parameters last time, this time there is quite a bit more other stuff. For example, two different Simulation class implementations. Are those changes necessary?

[Federerer]

For example, two different Simulation class implementations.

Those are mostly related to the asynchronous build pipeline, plus some performance stuff. I just wanted to keep the original algorithm for A/B comparisons in CLI. So that's why there are two simulation classes. But I think this probably can be separated into a separate PR. There are not that much changes new related to dynamic components. From what I can remember, I've changed how the pot curves are applied in order to keep parameters normalized to 0-1 linear range. There are also some variables added into the MNA, so the parameters are extracted into the linear part and didn't end up in the newton iterations. Also, parameters are now applied once per Run call, and what we should do is probably allow for per-sample changes, but that requires more changes in VST, so we might skip it for the v1.