Using LiveSPICE to train ML models

[mikeoliphant]

Lately I've been using (and assisting with the development of) Neural Amp Modeler - a framework for training and real-time playback of NN-based models of amplification equipment. It works really well.

A while back it occurred to me that LiveSPICE could be used to generate training data, and I finally got around to doing it:

https://blog.nostatic.org/2023/04/this-boss-sd-1-pedal-does-not-exist.html

Any thoughts on improvements to LiveSPICE to facilitate this use case?

A few thoughts I had:

• automated generation of output files for a range of knob values for training parameterized models
• more accurate (but presumably less performant) component models for offline rendering

[Federerer]

I think that we can utilize the Test project for that, as after merging my latest pr it should be quite easy to add a new functionality there. It might evolve into some kind of "LiveSPICE CLI" for testing, benchmarks, offline processing, and so on. I'm currently using it to find most performant solution for a given circuit using a genetic algorithm. 😉

* more accurate (but presumably less performant) component models for offline rendering

That's what we have already 😁 I'm actually trying to do the opposite. I've currently loosen the Newton iteration relative delta condition from 1e-4 to 1e-3 without any noticeable negative impact on stability, but in your case you might want to try the opposite. We should probably make it a settable parameter.

[mikeoliphant]

That's what we have already

Any feeling on potential accuracy differences between LiveSPICE and something like LTspice? My understanding was that LiveSPICE made some additional tradeoffs in order to achieve real-time playback.

[Federerer]

LiveSPICE uses fixed-time step, in opposite to variable time step in most of other spice software, this limits the frequency bandwidth that can be processed accurately. This usually can manifest in differences on transients and I also noticed some stability problems when using very small capacitor values, but I'm not 100% sure if it's caused by this. It might be worth to use a higher oversampling to mitigate this, especially when a lot of saturation is involved, as it produces a lot of higher harmonics.

[dsharlet]

There are a few cases where LiveSPICE uses a much simpler model than (probably) something like LTspice. The only actual example I am aware of is op-amps. When I implemented op-amps, I used a model that had far fewer non-linear components than the "full" model I referenced. That full op-amp model would push the limits of real time performance all by itself, let alone as part of a larger circuit. edit: for example, here's a possible implementation of a common op-amp that uses a lot more non-linear components than the model I implemented.

The impact of those extra components was probably marginal for the audio range of frequencies... but without actually putting them in and testing them (in either LiveSPICE or LTspice), it would be hard to say that for sure.

That said, there aren't actually that many cases like that that I'm aware of. Tube models are questionable, but which ones aren't :)

[dsharlet]

Very cool idea and work!

Agreed that some kind of command line interface is probably the most useful tool here for batch processing lots of data. We can either add audio file IO support to our own command line tool, or perhaps the more expedient approach is to leverage your VST work and use existing software/workflows to generate lots of files.

The first option is really easy to get something quickly working. .wav files are trivial to read/write, and libraries for other formats are probably readily available. The tests already run circuits on buffers of data, it doesn't take much code, and adding a way to set circuit parameters via command line arguments doesn't seem hard either.

The VST approach would probably offer a lot more features and tools, but I don't know if we actually need them for this...

[dsharlet]

My inclination would be to leave parameter sweeps to the caller of such a command line tool. That gets complicated really quickly with more than a few (or even maybe just 1) parameter. If the "CLI" is exposed via C# library code (void RunCircuit(string InputPath, string OutputPath, Dictionary<string, double> Parameters), then configuring sweeps could be done by writing small C# programs.

If you wanted to get really clever about it, you probably want some feedback between NAM and LiveSPICE. You could fill in the parameter space with some algorithm like:

1. Run parameter values a and c, model circuit from these two parameters
2. Run parameter value b, and check NAM's prediction quality vs. simulation
3. If the error is large, add parameter = b to the training, and subdivide intervals a, b and b, c again.

Basically, a binary search on where training data is necessary. Extending it to multiple dimensions (parameters) is doable, but with many parameters/high dimensionality, it might simply be infeasible to model the whole space no matter how clever you get.

[mikeoliphant]

Agreed that command-line tools are likely the best way forward here, and also agreed that knob twiddling combinatorics can easily get out of hand.

[Federerer]

I started playing around with our test project and put all command handlers to the separate files, then added some parameter parsing for Quantity and added support for key=value parameters, so the only thing left is to add some kind of .wav file read/write. Do we want to use some library or write a poor man's version that only supports a limited subset of formats? NAudio looks quite heavy for our needs.

This is how it looks like currently:

> livespice test ".\Fender Princeton AA1164_test.schx" --plot --parameters volume=1 treble=0,6 bass=0,4 nfb=0,5 --amplitude 9V --simulationTime 100ms --preRunTime 2s --oversample 1 --sampleRate 44100
Opening .\Fender Princeton AA1164_test.schx
Schematic loaded from '.\Fender Princeton AA1164_test.schx'
Building circuit...
Build: 0 errors, 0 warnings
Testing circuit with parameters: Volume=1, Treble=0,6, Bass=0,4, NFB=0,5
Building solution for h=2,2675736961451248E-05
Performing steady state analysis...
Failed to find partition initial conditions, simulation may be unstable.
Performing transient analysis...
System solved, 2 solution sets for 75 unknowns.
Newton iteration size: 17
Saving output file: Fender Princeton AA1164_dz2_optimized_optimized.bmp

[mikeoliphant]

I don't think NAudio is necessarily a bad dependency.

I've also written wav file read/write code numerous times over the years, and could contribute a "poor man's" version if that was preferred.