LiveSPICE, a real time SPICE simulator for live audio

[dsharlet]

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.

...

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.

I've been thinking about this and I see how you can construct the integrated system of equations directly. However, I don't see how you get from there to a smaller non-linear system of equations?

After stamping out a matrix with MNA component stamps, the non-linear equations will depend on other parts of the circuit, and can't be solved by themselves I don't think? Or maybe I'm missing something? It would be funny if so, I spent quite a lot of time and effort on my current approach because I couldn't find a simpler way...

[dsharlet]

Great work here! Playing with it at the moment.

Glad to hear it, I hope it is working well for you

[mystran]

After stamping out a matrix with MNA component stamps, the non-linear equations will depend on other parts of the circuit, and can't be solved by themselves I don't think? Or maybe I'm missing something? It would be funny if so, I spent quite a lot of time and effort on my current approach because I couldn't find a simpler way...

After a block-LU pass the lower-right sub-matrix is a linear sum of the original lower-right block (eg. the non-linear block) and whatever the LU process added from the rows above it. Since it's a linear sum, it doesn't matter if you stamp there before or after the block-factorization. So you can minimize the stateful and non-linear dimensions at the cost of additional algebraic equations, because you can block-factor all the algebraic equations out of the system in a preprocess. You just need to keep the stateful, the non-linear and the potentially time-varying dimensions. Anything else need not exist at runtime at all.

[S0lo]

This is really nice. Thanks!!

[Richard_Synapse]

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.

Yeah I noticed the recalculation of course, for my purposes it does not matter though. I'd use LiveSpice to compare its results with my own models, which is a lot easier with the VST Plugin than doing it all offline. So the CPU usage is rather irrelevant for me. Of course if it can be fixed like mystran suggested, it is even better, but even in its current state, automation would be useful

Richard

[dsharlet]

After a block-LU pass the lower-right sub-matrix is a linear sum of the original lower-right block (eg. the non-linear block) and whatever the LU process added from the rows above it. Since it's a linear sum, it doesn't matter if you stamp there before or after the block-factorization. So you can minimize the stateful and non-linear dimensions at the cost of additional algebraic equations, because you can block-factor all the algebraic equations out of the system in a preprocess. You just need to keep the stateful, the non-linear and the potentially time-varying dimensions. Anything else need not exist at runtime at all.

I found viewtopic.php?f=33&t=498122 (and a copy of Halite.cpp), is this an implementation of the strategy you are describing?

[mystran]

After a block-LU pass the lower-right sub-matrix is a linear sum of the original lower-right block (eg. the non-linear block) and whatever the LU process added from the rows above it. Since it's a linear sum, it doesn't matter if you stamp there before or after the block-factorization. So you can minimize the stateful and non-linear dimensions at the cost of additional algebraic equations, because you can block-factor all the algebraic equations out of the system in a preprocess. You just need to keep the stateful, the non-linear and the potentially time-varying dimensions. Anything else need not exist at runtime at all.

I found viewtopic.php?f=33&t=498122 (and a copy of Halite.cpp), is this an implementation of the strategy you are describing?

If I recall correctly, the stamps in Halite are designed in this way (ie. with some extra algebraic dimensions), but the solver is as simple as possible (ie. completely brute-force) to keep it as simple as possible.

ps. This also goes for non-linearities. For example, with a diode between two (non-ground) nodes, you can iterate a system with the two nodes, but you can also use an ideal transformer with one side connected to the two nodes and one side connected to a ground-referenced diode. If the Halite stamps look "weird" then this is what is going on. While it would seem that this results in a large system, the ideal transformer can be factored out in the preprocessing stage (in a more realistic solver) and now there is only one dimension to iterate for the diode. The same can be done with an Ebers-Moll BJT, resulting in two dimensions to iterate for the two dimensions, no matter how the transistor is connected to the circuit.

[S0lo]

@dsharlet

If possible. it would be great if it can show the final C like code that runs the circuit.

[KrupaX]

I just found this app the other day and have been having fun trying to build valve based oscillators with varying degrees of success - mostly failing as many of the designs I'm stealing use pentodes rather that the triodes that are included in the package - has anyone figured out how to add more models to this?

[Miles1981]

Interesting, looks like a better version than my dynamic ATK modelling free code.
Do you build a static solver on the fly, or is it fully dynamic? (compared to something like https://github.com/AudioTK/ATK-MT2/blob ... haping.cpp, but this is C++, and I don't read C# fluently )

[KrupaX]

Sorry, I missed the notification of your reply! This builds a new solver each time you change the circuit, variable resistors do seem to change live, but I think that also prompts some sort of rebuild as well. Hard to know, I’ve moved on to hardware with that project now, loving it!

[synthgeek]

Cool to see this project is still going!

[Plugins!!Plugins!!]

How ya doin'! I'm wondering if LiveSpice is totally royalty-free to use for my productions, and are there any restrictions for using it? Can I take the models I build and use them in another plug-ins creating software like JUCE or Blue Cat's Plug'n Script?

[dsharlet]

Interesting, looks like a better version than my dynamic ATK modelling free code.
Do you build a static solver on the fly, or is it fully dynamic? (compared to something like https://github.com/AudioTK/ATK-MT2/blob ... haping.cpp, but this is C++, and I don't read C# fluently )

I looked at the C++ code you linked. It appears to be constructing the system of equations you need to solve at each timestep, and then solving it, which LiveSPICE is also doing.

However, the system of equations it solves is hardcoded by the C++ code itself. LiveSPICE is doing basically the same thing, but with two major exceptions:

First, it generates the program dynamically. If you do this fully dynamically, it will be quite slow. To avoid this, LiveSPICE generates this program, and then compiles it (while the program is running!) so it's still pretty fast. This is something pretty easy to do in C#, but not so easy in C++ However, it is not fully dynamic. If you change a parameter of the simulation (e.g. a potentiometer), it will hiccup while it recompiles the circuit. I've been trying to find a way to make parameters like that variables in the compiled circuit, but that has proven very difficult.

Second, your code appears to use a non-linear solver on the entire system of equations. LiveSPICE does some math to make it so it only needs to solve a smaller non-linear system of equations, which is much faster. In your example, it looks like you have a 5x5 system of equations, but only 2 of the variables are non-linear. LiveSPICE would refactor this into a 2 variable non-linear system, and a 3 variable linear "update". For only 2 vs. 5 variables, this isn't a huge deal, but in a large circuit, often maybe 1/10th of the variables are non-linear, which is a huge speedup (maybe even thousands of times faster!) if the total number of variables is large.

How ya doin'! I'm wondering if LiveSpice is totally royalty-free to use for my productions, and are there any restrictions for using it? Can I take the models I build and use them in another plug-ins creating software like JUCE or Blue Cat's Plug'n Script?

If you are asking about the source code of LiveSPICE, it uses the MIT license, which is pretty permissive.

If you are asking about the simulations it generates, I would say that depends on the source of the circuits you are simulating. I certainly wouldn't claim ownership of the generated simulations, so if you developed the circuit yourself, it's all yours. If you copied a circuit from somewhere, I would ask the owner of that circuit.

However, I'm curious how you plan to actually get the simulation out of the thing I've been intending to try to generate C source code from the simulation engine, but haven't actually done that. It does spit out the code it uses to run the simulation if you ask it to, but it's not just a copy/paste job to turn that into a simulation, it's missing some of the numerical solver logic needed to make it work.

[mystran]

However, it is not fully dynamic. If you change a parameter of the simulation (e.g. a potentiometer), it will hiccup while it recompiles the circuit. I've been trying to find a way to make parameters like that variables in the compiled circuit, but that has proven very difficult.

Instead of partitioning the solution into just linear and non-linear parts, you can go further and partition the solution into "static", "dynamic" and "non-linear" where you factor out the static parts in precomputation, then compile code that factors the dynamic parts (eg. pots) once per time-step and only iterates the non-linear part (and similarly for the back-substitution part, where you only need to generate code to solve the nodes you actually need for things like capacitors and output).

I don't know what the LiveSPICE solve looks like, but if you use something like LU this is literally just a matter of ordering the rows and columns and then reordering/staging the factorization.