LiveSPICE, a real time SPICE simulator for live audio

[dsharlet]

Hi all, I just posted a new release of LiveSPICE, which has been mentioned several times on this forum over the years. My apologies if this thread is a dupe, I actually thought I posted about it here but I can't find it now. I know this might seem like spam, but I'm not trying to sell anything I work on this for fun, and I hope it is interesting to some of you.

LiveSPICE is a tool that allows you to design an analog circuit schematic, and then simulate it in real time on audio signals. It can simulate many kinds of audio effect and amplifier circuits fast enough to run on live audio signals with low latency.

The most requested feature, a VST plugin, is finally here, thanks to a contribution from Mike Oliphant! This plugin allows you to design analog circuits, and then use them as effects in a VST host program, no development required!

There are some examples (including audio samples) that show what it is currently capable of simulating, as well as more information about the project here: https://www.livespice.org.

Feedback and bug reports are much appreciated, and apologies in advance if it takes me another 6 years to address them

[Richard_Synapse]

Wow, GREAT stuff - thanks so much for sharing! LiveSpice is already amazing but a VST plugin takes this to an entirely new level of usefulness!

Don't really have any feature requests yet to ask for. Regarding the VST specifically, exposing the knob parameters to the host would be cool for automation purposes. But it is already amazing as it is!

Richard

[mystran]

Some of the math-markup on http://dsharlet.com/2014/03/28/how-live ... equations/ doesn't seem to be loading correctly.

[mystran]

It is possible that by applying the rank reduction optimization to the Newton’s method system at circuit analysis-time, Gaussian elimination uses a pivot that would not have been the maximum pivot found at runtime, resulting in a less numerically stable solution. While this is a concern, I have not yet found a test circuit that produces a numerically unstable simulation when it should be stable. Unfortunately, I don’t have much more I can say about this issue.

My experience on this suggests that simple partitioning of linear vs. non-linear parts (which is a very old technique; I'm pretty sure I've seen this in papers from 60s or 70s, but can't seem to find an example right now) doesn't always work perfectly (depending a bit on the component models; simple "idealized" components tend to cause more issues than more realistic models with parasitic resistances and such; usually at most 1-2 linear dimensions need to be preserved in the iterated solution though) and in general any statically chosen pivoting order (such as what you would want for straight-line JIT code) can occasionally run into problems if the actual possible values of the Newton terms are not considered at all.

That said, doing a pre-simulation "test-run" with logic such that pivoting order is changed from the previous time-step only if a significantly better choice is available (and possibly with the addtional condition that the current choice most be obviously poor) seems to usually (with a suitably chosen heuristic of "significantly better") find an order that is stable after a couple of corrections early on (ie. once the "dynamically very bad" pivots are found and rejected).

For what I can tell though, there isn't any obvious truly robust solution to this, other than detecting problems at run-time and doing slower fall-back if a problem is found.

[VariKusBrainZ]

Tried to load the VST bridge plugin in Bitwig on Win10 but it got stuck on trying to load it, passed the plugin scan though.

Changed plugin loading sandbox option to 'within Bitwig' and it loads.

When a section of audio is looped it works fine until the loop starts again and then breaks up into unusability.

[juha_p]

Got lots of syntax errors (with brackets etc.) with VS 2013 ... which version of VS is needed (if I don't want to install VS 2019)?

[mystran]

Got lots of syntax errors (with brackets etc.) with VS 2013 ... which version of VS is needed (if I don't want to install VS 2019)?

The solution file seems to be generated by VS2019, so you might need that.

[dsharlet]

I recently updated the solutions from VS2012 to VS2019. I don't think that involved changing the code, so it's a bit surprising to see syntax errors, but, I think VS2019 is probably necessary to load the solution/projects correctly. The free version works fine BTW, if you are concerned about updating for that reason...

I'll have to try Bitwig and see if I can find issues. If you find issues like this, please do report them on Github

My experience on this suggests that simple partitioning of linear vs. non-linear parts (which is a very old technique; I'm pretty sure I've seen this in papers from 60s or 70s, but can't seem to find an example right now) doesn't always work perfectly (depending a bit on the component models; simple "idealized" components tend to cause more issues than more realistic models with parasitic resistances and such; usually at most 1-2 linear dimensions need to be preserved in the iterated solution though) and in general any statically chosen pivoting order (such as what you would want for straight-line JIT code) can occasionally run into problems if the actual possible values of the Newton terms are not considered at all.

That said, doing a pre-simulation "test-run" with logic such that pivoting order is changed from the previous time-step only if a significantly better choice is available (and possibly with the addtional condition that the current choice most be obviously poor) seems to usually (with a suitably chosen heuristic of "significantly better") find an order that is stable after a couple of corrections early on (ie. once the "dynamically very bad" pivots are found and rejected).

For what I can tell though, there isn't any obvious truly robust solution to this, other than detecting problems at run-time and doing slower fall-back if a problem is found.

Like I said, I doubt this is a new technique, it was just really hard to find a reasonable description of it, and I still haven't found one.

I found a nice solution to the pivot problem since writing that description of the solver: use the initial conditions (steady state analysis) when selecting pivots, but keep the original symbolic expressions! It's rare for the ideal pivots to change significantly during simulation. Even if the exactly largest magnitude pivot changes, it's usually not by a lot.

This is probably functionally the same thing as using a "test-run" as you mention, but the initial conditions are needed anyways, some circuits cannot converge without starting from a reasonable steady state condition (even with arbitrarily small timesteps). The initial condition solver is much more robust (and slower) than the dynamic simulation solver, which is why it solves this problem.

Another difference since that post, I'm using the second-order backward difference formula instead of the trapezoid rule, and there are probably some other minor differences too.

Sorry about the broken math markup, I had to port my website a while back and I guess this got broken then, I'll have to take a look at it, and I'll try to fix the out of date things too.

[ladron]

Don't really have any feature requests yet to ask for. Regarding the VST specifically, exposing the knob parameters to the host would be cool for automation purposes. But it is already amazing as it is!

There are a couple of issues with exposing the knobs as VST parameters to the host. Firstly, they are circuit-dependent, and VST parameters are set up once at startup. Secondly, the simulation needs to be re-solved when the knob values change, and this is currently way to slow to be done in real-time. The first issue could probably be worked around, but second issue currently makes this impractical.

[mystran]

Like I said, I doubt this is a new technique, it was just really hard to find a reasonable description of it, and I still haven't found one.

Like I said, I can't find a reference either. I'm pretty sure it's one of those things that has been invented and reinvented a number of times, I've "reinvented" it myself as well, before realizing that a couple of decades earlier other people have used it already.

I found a nice solution to the pivot problem since writing that description of the solver: use the initial conditions (steady state analysis) when selecting pivots, but keep the original symbolic expressions! It's rare for the ideal pivots to change significantly during simulation. Even if the exactly largest magnitude pivot changes, it's usually not by a lot.

If you do the "steady state analysis" using transient simulation (rather than pure DC analysis, which is a reasonable initial condition, but doesn't always result in the best choice of static pivots) then sure, that's basically similar to what I was suggesting.

Another difference since that post, I'm using the second-order backward difference formula instead of the trapezoid rule, and there are probably some other minor differences too.

I played around with these at some point as well, but trapezoidal is slightly more efficient computationally, especially if one optimizes with the assumption of a fixed time-step (so that a TDF2 formulation is valid). That said, if you don't mind the extra state, there is also a 2nd order accurate 3rd order (in the sense that it uses 3 delays, even if it's not 3rd order accurate) A-stable BDF method somewhere that's slightly more accurate than the standard 2nd order BDF, particularly at higher frequencies.

[mystran]

Don't really have any feature requests yet to ask for. Regarding the VST specifically, exposing the knob parameters to the host would be cool for automation purposes. But it is already amazing as it is!

There are a couple of issues with exposing the knobs as VST parameters to the host. Firstly, they are circuit-dependent, and VST parameters are set up once at startup. Secondly, the simulation needs to be re-solved when the knob values change, and this is currently way to slow to be done in real-time. The first issue could probably be worked around, but second issue currently makes this impractical.

One can avoid a full solver on pot-changes by partitioning the system into three parts rather than two: linear time-invariant (solved once), linear varying (solved once per time-step with time-varying pots) and non-linear (iterated). That's one or two dimensions per pot (depending on whether one side is connected to ground) that needs to be solved on per-timestep basis, which can then be modulated with full per-sample interpolation without too much run-time cost. To avoid having to deal with topology changes, simply restrict the pot-range such that there is always at least 1ohm (or some such similar small value) at each end of the pot; it's basically irrelevant for a typical 10k or larger pot, but keeps the matrix from going singular.

As for the VST side of things.. no good solution other than reserving some parameters for the purpose.

[dsharlet]

I played around with these at some point as well, but trapezoidal is slightly more efficient computationally, especially if one optimizes with the assumption of a fixed time-step (so that a TDF2 formulation is valid). That said, if you don't mind the extra state, there is also a 2nd order accurate 3rd order (in the sense that it uses 3 delays, even if it's not 3rd order accurate) A-stable BDF method somewhere that's slightly more accurate than the standard 2nd order BDF, particularly at higher frequencies.

I found BDF2 to be quite a bit faster overall than the Trapezoid method! I saw a ~10% bump on most circuits, and that improvement grew more significant with more complicated circuits. The cost of the extra delay is really small relative to the cost of the rest of the arithmetic in evaluating y'. But the main reason I switched to BDF2 is it made some circuits stable where they were not with the trapezoid method.

Are you referring to methods like TR-BDF2? I've been considering implementing that, but it requires generating quite a bit more code (or being clever with reuse, neither of which my compiler pipeline would be good at right now).

One can avoid a full solver on pot-changes by partitioning the system into three parts rather than two: linear time-invariant (solved once), linear varying (solved once per time-step with time-varying pots) and non-linear (iterated). That's one or two dimensions per pot (depending on whether one side is connected to ground) that needs to be solved on per-timestep basis, which can then be modulated with full per-sample interpolation without too much run-time cost. To avoid having to deal with topology changes, simply restrict the pot-range such that there is always at least 1ohm (or some such similar small value) at each end of the pot; it's basically irrelevant for a typical 10k or larger pot, but keeps the matrix from going singular.

Hmm, the problem I had is the symbolic expressions grew really large when doing row reduction to solve for the differential equations and to isolate the non-linear equations. I'm not actually sure which of those caused the problem (if it was just one of them), or if there were simplifications being missed that would have helped. Or possibly the solution is to not try to simplify the expressions at all.

It was years ago when I gave up on this approach, I need to try it again to refresh my memory on the problems I had.

[mystran]

I found BDF2 to be quite a bit faster overall than the Trapezoid method! I saw a ~10% bump on most circuits, and that improvement grew more significant with more complicated circuits. The cost of the extra delay is really small relative to the cost of the rest of the arithmetic in evaluating y'. But the main reason I switched to BDF2 is it made some circuits stable where they were not with the trapezoid method.

My experience doesn't mirror this, but maybe I'm missing something. The idea with the trapezoidal is that in the fixed time-step case one can rearrange it into a TDF2 form, which then only needs a single combined delay, which means one can put the whole thing into the MNA matrix and solve for the new state directly, skipping the separate integration step. In contrast, with pretty much any other rule (well, other than Euler) you either need extra dimensions or a separate integration step.

This is not profitable if you want a full solution of all the nodes (because now you need extra work to decode the voltage over your capacitors), but it is profitable when doing a real-time solution from inputs to outputs only.

Are you referring to methods like TR-BDF2? I've been considering implementing that, but it requires generating quite a bit more code (or being clever with reuse, neither of which my compiler pipeline would be good at right now).

I don't think that's the one. I'm referring to a BDF3 variant that is tweaked to be A-stable. The result is no longer 3rd order accurate (the classic result says that no A-stable method can be better than 2nd order accurate), but it remains 2nd order accurate and better than BDF2.

I really can't seem to find a reference, but if I remember correctly the basic idea is that BDF2 is somewhat overdamped in the region of the imaginary axis where BDF3 is unstable, so one can take a linear combination of the two that brings the stability limit closer to the axis without going over and since both of the methods are (at least) 2nd order accurate, the linear combination remains 2nd order accurate while improving the constant terms.

Hmm, the problem I had is the symbolic expressions grew really large when doing row reduction to solve for the differential equations and to isolate the non-linear equations. I'm not actually sure which of those caused the problem (if it was just one of them), or if there were simplifications being missed that would have helped. Or possibly the solution is to not try to simplify the expressions at all.

What I've always done is just design component stamps directly in such a way that no symbolic manipulation is necessary and dimensions can be directly tagged based on the evaluation stage requestion (eg. linear, varying, iterated), then do a purely numerical solution.

[lalo]

@dsharlet, great coming back! thanks and hope you'll not leave it alone for other 6 years

[Ivan_C]

Great work here! Playing with it at the moment.