LiveSPICE, a real time SPICE simulator for live audio

 KVRer
 8 posts since 9 Mar, 2014
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
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
 KVRian
 1045 posts since 20 Dec, 2010
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
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
Synapse Audio Software  www.synapseaudio.com

 KVRAF
 6397 posts since 12 Feb, 2006 from Helsinki, Finland
Some of the mathmarkup on http://dsharlet.com/2014/03/28/howlive ... equations/ doesn't seem to be loading correctly.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

 KVRAF
 6397 posts since 12 Feb, 2006 from Helsinki, Finland
My experience on this suggests that simple partitioning of linear vs. nonlinear 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 12 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 straightline JIT code) can occasionally run into problems if the actual possible values of the Newton terms are not considered at all.It is possible that by applying the rank reduction optimization to the Newton’s method system at circuit analysistime, 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.
That said, doing a presimulation "testrun" with logic such that pivoting order is changed from the previous timestep 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 runtime and doing slower fallback if a problem is found.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.
 KVRAF
 9433 posts since 16 Dec, 2002
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.
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.
Last edited by VariKusBrainZ on Mon Nov 09, 2020 1:06 pm, edited 2 times in total.
Amazon: why not use an alternative

 KVRAF
 6397 posts since 12 Feb, 2006 from Helsinki, Finland
The solution file seems to be generated by VS2019, so you might need that.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

 KVRer
 8 posts since 9 Mar, 2014
Topic Starter
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
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 "testrun" 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 secondorder 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.
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
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.mystran wrote: ↑Mon Nov 09, 2020 12:37 pmMy experience on this suggests that simple partitioning of linear vs. nonlinear 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 12 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 straightline 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 presimulation "testrun" with logic such that pivoting order is changed from the previous timestep 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 runtime and doing slower fallback if a problem is found.
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 "testrun" 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 secondorder 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.
 KVRer
 17 posts since 6 Nov, 2020
There are a couple of issues with exposing the knobs as VST parameters to the host. Firstly, they are circuitdependent, and VST parameters are set up once at startup. Secondly, the simulation needs to be resolved when the knob values change, and this is currently way to slow to be done in realtime. The first issue could probably be worked around, but second issue currently makes this impractical.Richard_Synapse wrote: ↑Mon Nov 09, 2020 3:53 amDon'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!
Mike Oliphant
github.com/mikeoliphant
github.com/mikeoliphant

 KVRAF
 6397 posts since 12 Feb, 2006 from Helsinki, Finland
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.
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.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.
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 timestep (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) Astable BDF method somewhere that's slightly more accurate than the standard 2nd order BDF, particularly at higher frequencies.Another difference since that post, I'm using the secondorder backward difference formula instead of the trapezoid rule, and there are probably some other minor differences too.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

 KVRAF
 6397 posts since 12 Feb, 2006 from Helsinki, Finland
One can avoid a full solver on potchanges by partitioning the system into three parts rather than two: linear timeinvariant (solved once), linear varying (solved once per timestep with timevarying pots) and nonlinear (iterated). That's one or two dimensions per pot (depending on whether one side is connected to ground) that needs to be solved on pertimestep basis, which can then be modulated with full persample interpolation without too much runtime cost. To avoid having to deal with topology changes, simply restrict the potrange 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.ladron wrote: ↑Mon Nov 09, 2020 4:51 pmThere are a couple of issues with exposing the knobs as VST parameters to the host. Firstly, they are circuitdependent, and VST parameters are set up once at startup. Secondly, the simulation needs to be resolved when the knob values change, and this is currently way to slow to be done in realtime. The first issue could probably be worked around, but second issue currently makes this impractical.Richard_Synapse wrote: ↑Mon Nov 09, 2020 3:53 amDon'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!
As for the VST side of things.. no good solution other than reserving some parameters for the purpose.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

 KVRer
 8 posts since 9 Mar, 2014
Topic Starter
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.mystran wrote: ↑Mon Nov 09, 2020 5:00 pmI 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 timestep (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) Astable BDF method somewhere that's slightly more accurate than the standard 2nd order BDF, particularly at higher frequencies.
Are you referring to methods like TRBDF2? 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).
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 nonlinear 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.mystran wrote: ↑Mon Nov 09, 2020 5:08 pmOne can avoid a full solver on potchanges by partitioning the system into three parts rather than two: linear timeinvariant (solved once), linear varying (solved once per timestep with timevarying pots) and nonlinear (iterated). That's one or two dimensions per pot (depending on whether one side is connected to ground) that needs to be solved on pertimestep basis, which can then be modulated with full persample interpolation without too much runtime cost. To avoid having to deal with topology changes, simply restrict the potrange 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.
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.

 KVRAF
 6397 posts since 12 Feb, 2006 from Helsinki, Finland
My experience doesn't mirror this, but maybe I'm missing something. The idea with the trapezoidal is that in the fixed timestep 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.dsharlet wrote: ↑Tue Nov 10, 2020 11:26 amI 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.
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 realtime solution from inputs to outputs only.
I don't think that's the one. I'm referring to a BDF3 variant that is tweaked to be Astable. The result is no longer 3rd order accurate (the classic result says that no Astable method can be better than 2nd order accurate), but it remains 2nd order accurate and better than BDF2.Are you referring to methods like TRBDF2? 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 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.
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.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 nonlinear 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.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

 KVRAF
 1533 posts since 14 Oct, 2002
@dsharlet, great coming back! thanks and hope you'll not leave it alone for other 6 years