Salt - tech preview / test demo

[mystran]

So I suppose everyone must be wondering: what on earth is he REALLY working on?

Well, here's the answer (running in SaviHost, thanks arakula for making my life easier.. can you fix that wheel bug though, please):



It's not quite Spice, but still (hopefully) useful for cooking virtual circuits.

This is very much tech preview, not a product.

http://www.signaldust.com/files/salt-techdemo.zip <- feel free to try.

But yes, you can edit the circuits! No need to learn math or even programming, just drag-and-drop components and you can do it too (some basic EE knowledge might help, but experimentation works too). Virtual bread-boarding here we go.

Yes, it runs in a VST plugin, and processes audio on the fly (Windows 32-bit only for now; the code-gen back-end can't emit x64 code yet, so the JIT wouldn't work, and the REF solver is slow).

With regards to CPU use: this tech-demo runs at fixed internal samplerate of 150kHz (so aliasing isn't too ridiculous) and two-copies for stereo (unless you use the dry-right mode).. and doesn't currently split the channels to different threads so.. yeah it's not very light-weight, even if the tech should be fairly competitive.

Everything might not work correctly, but maybe it's not too badly broken right now.. since it might also be a bit different from your average plugin.

The component selection is "the absolute minimum that makes sense for a tech toy" and the GUI is basically "whatever allows me to test this during development."

There are no pots or control voltages available. There is no C-code export available. Both are things that will eventually become features: I actually started writing a tool for easier "zero-delay" type development, and it got a bit out of hand, and this is what I ended up with.

It should save the circuit in presets (the one on screen.. it will NOT save the one that is currently active in audio code, sorry) in theory, and there's some preset space and a few simple examples / test-circuits. It shouldn't crash too much either. But you're nuts if you try to use this for any production stuff.

There will in general be no support for this "version", and I might not even fix bugs, unless I think they are serious (or if they are too much pain to deal with). I just wanted to show what I'm currently wasting my time on.

I'll answer reasonable questions.

But since this is a bit geeky in general, I'll provide the following instructions:

---

What you need to know:

This tech-demo uses trapezoidal method, because it's the most well-tested integrator and generally works reasonably for audio. Non-linear components are solved by Newton's method (so I guess it might theoretically be possible to build stuff that doesn't converge.. just so you know).

Whenever changes are made to the circuit (including movement of the output when probing different points) you need to power-cycle for the changes to become active (so it can optimize and recompile the new circuit, which is pretty quick). Use the "process" switch on the GUI for power-cycling, not sure if it notices host-bypass.

There should be at least one "Signal In" if you intend to process some audio.
There should be at least one "Signal Out" if you intend to "extract" that audio.

There can be multiple inputs, they will just feed the same data to multiple points. Technically multiple outputs are also possible (this isn't checked), but which one you actually hear is damn-near random.. so just use one output. If there are no outputs at all, you will get pass-through signal.

For dry/wet comparisons (on scope, phase-plot, etc) use the "dry right" mode, which will mono-sum the input, process it once, put it into left channel, and put the latency-matched dry-signal on the right channel. You can also use this mode to save some CPU, since it runs in mono then.

The REF ("straight" reference solver) and JIT (native just-in-time compiler) solvers SHOULD give the same results, except REF uses about twice the CPU typically, and has a lower iteration limit (5 for REF, 10 for JIT). The main reason "REF" exists is to compare in case there's reason to believe that the JIT is doing something weird.. but that should not happen.

DC block .. will subtract the calculated VDC from the output. It's a simple one-pole filter, with quite a long time-constant, so it can take a second or so to get the rail-voltages back to IO levels after a reset.


---

Editing instructions:

Lots of patience required: the GUI is NOT very user-friendly. It's a "works for me" temporary design, as I've been trying to get the damn low-level tech to work reliably.

Draw wires with left-mouse from a "pin" of a component (no, they aren't visible, but they should be fairly obvious). Right-click on wire to remove them. Crossing wires over pins will auto-connect, but otherwise you can cross wires (click to connect a crossing point).

Right-click on empty-space to add components. Right-click on component to make it turn or flip around.. depends on the component what is possible. Shift+right-click to remove a component. You don't need wires if pins "happen" to be at the same position (not visually indicated, but works anyway).

To change values of resistors and capacitors (from a limited set right now): left-click to cycle through the selection.. or more realistically use a host where mouse-wheel works, and scroll with mouse. Haven't had time to add anything better yet, so sorry if that doesn't work for you. The value-label positioning sucks too, but it was the best I could do in the 5 minutes that I've spent on it.

You can NOT move larger groups at once, yeah I know it sucks. There is no undo either. Sorry. Those are just things that I have not implemented yet. Same with the limited working space.

---

Useful circuit details:

The external I/O is +/-5V for standard 0dBfs VST range (no selection, sorry).

The voltage rails are +/-15V and ideal.. hopefully good compromise, but see next chapter.

Resistors and capacitors are ideal. OPAs are near ideal (finite high gain), no slew-rate limiting and not limited by the voltage rails (so you need voltage higher or lower than +/-15V, use the OPAs). Both resistors and the OPAs are cheap in terms of CPU, so don't worry about those too much.. they mostly get simplified away anyway (it's not like this would work without optimizations), so resistor mazes are perfectly fine. Capacitors are handled individually right now (no circuit-theoretic simplification, sorry), and in general cost more, since they need to be solved for the integration to work.

The diode and BJT models are fixed "test models" that I used for getting the lower-level stuff to work.. they should behave like some hypothetical silicon devices, but if you need more details, you'll have to measure yourself. The basic model BJT model is the usual "two diodes + transport" simplification, plus a few small resistances to make it's harder to get the math to fail.

I won't add more components or better models, sorry. Yes, I know it's limited, but this stuff takes a BIT too much time to give it all away for free.

---

Troubleshooting:

If it says "VDC +big/-big" then you got a voltage more than 1kV (could be infinite too), either because the math failed, or you did something stupid (both are possible, since the OPAs are not supply-limited).

Note that capacitor charges can also "run away" if the caps have no path to any reference, which can make a seemingly "well-behaved" circuit fail after a while (standard SPICE-like advice applies here). If it says "iters: 0" (well, it might say other values if one channel is still running) then that means the simulation failed "hard" and could not find a solution. If "iters" is negative, then please check the power button.

Components that are part of the "solution" for the output need to have a path to a reference voltage (ground or rails). In other cases it mostly doesn't matter; standard SPICE-like precautions apply... but Salt solves only the parts that it really needs to solve, so it might not notice that there is a problem, if those problems are irrelevant in terms of the output.

---

This is why I don't like doing "zero delay feedback" math manually.

[mystran]

And credits, since I forgot to include a README:

I use AsmJit for final code-assembly, which saved me from writing an assembler (the compiler in AsmJit 1.0-beta4 is horribly broken though, so couldn't use that).

Copyright (c) 2008-2012, Petr Kobalicek <kobalicek.petr@gmail.com>

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.

I use Freetype for font-rendering as usual, and picopng for loading pictures. (see README in any of my other plugins).

Qucs technical manuals proved very helpful with the circuit basics originally. Various technical documents explaining Spice strategies also proved useful, as did a lot of other papers on circuit simulation, Newton-type methods and ODE solvers. Inkscape was helpful for drawing some symbols. SAVIhost has saved me from going totally nuts.

---

Oh and.. thanks to Andy (of Cytomic) for generally encouraging emails.

---

Now.. on to the remaining pieces of the puzzle: getting the C-code generation to work in a more practical way, adding GUI support for pots, adding better component models, getting the GUI to a more user-friendly state, adding integrated analysis tools, maybe add vectorization to the compiler... sigh.

Seriously: the "zero-delay feedback" math is a freaking trivial thing in the grand scale of things.

[mystran]

Oh and.. if you think this whole thing is interesting at all, please post a message.

Sometimes I really feel like I'm just wasting my time with this whole project.

[cron]

Oh my word! What an idea.

I've just installed this and I'll give it a crack. It's been a long time since I mangled electronics and I was never particularly good at it. The furthest I got was feeding the output from a few LDRs into Max via a BasicATOM (with considerable help), plus the obligatory circuit bending.

This is a fascinating project. Time to brush up on potential dividers.

[aciddose]

I've thought about doing this many times, although my experience with spice simulators is that the output of a spice simulator is about as far as what you'd want from audio as possible.

Inefficient, inaccurate, prone to aliasing and uncontrollable oscillations (failure of convergence) that would not occur in a real circuit.

I have thought that making modifications and using specific solutions to these issues might help. There is a very large difference between the goals of an electronic simulation and a tool designed to approximate the audible output of a circuit.

For example I've often thought that automatically reducing the slew-rate would solve most issues with convergence, and it does. These elements need to be manually inserted in a spice circuit and other adjustments made to make up for their presence.

Although I've felt it should be possible to conduct this compensation process automatically it goes against the goal of a simulator as it introduces unacceptable error. For audio however what really matters isn't accuracy but audibility!

Unfortunately I'm perfectly aware of the complexity of such a project and this prevented me from ever trying

Although I do regularly use gamma and omega functions to get approximations of RC-diode circuit responses, the results need to be stored in a table to make them sane as the audibility factor once it comes into play means that the difference between a cheap approximation with a few multiplications and the amazingly complex RC-diode approximation are an insignificant number of decibels apart

It's great to see some kind of effort going toward this. In the very least it might become a reference point to use when designing other approximate solutions. There is nothing quite like using a system in real-time to observe what are truly audible differences and the amazing complexity you can achieve by turning a few controls. Spice unfortunately doesn't come close to what we really need to efficiently test audio circuits in software.

[mystran]

Oh my word! What an idea.

I've just installed this and I'll give it a crack. It's been a long time since I mangled electronics and I was never particularly good at it. The furthest I got was feeding the output from a few LDRs into Max via a BasicATOM (with considerable help), plus the obligatory circuit bending.

This is a fascinating project. Time to brush up on potential dividers.

Don't get too excited yet.. this is pretty limited preview, and it might take a whole lot of time before it becomes a production quality tool.

But it's a milestone for me: most of the core-technology is now working.

[Frantz]

So you can find the schematic of any classic analog filter, spend an hour drawing the circuit in Salt, and voilà - the perfect VST emulation? I suspect it can't be that powerful.

What do you envision the capabilities of the finished product will be? A rough prototyping tool or something more?

[mystran]

So you can find the schematic of any classic analog filter, spend an hour drawing the circuit in Salt, and voilà - the perfect VST emulation? I suspect it can't be that powerful.

Well, I suppose that depends on how carefully you want to emulate.

The real problem of modelling circuits is modelling the components and making trade-offs on what needs to be included in the model and what is just useless detail. Salt just solves the easy part: turning the final model into efficient executable code.

Basically I think that anyone writing circuit simulation code manually is just wasting their time, and lots of it. There are plenty of optimizations that are trivial for a computer, but ridiculously time-consuming and error-prone to do manually. That's why you use compilers, and under the GUI editing there is really just an optimizing compiler, designed for one specific purpose: solving small-scale analog circuits fast.

But if your idea of circuit modeling is just taking a schematic and figuring out how to implement the calculation in the first place.. then yeah.. I suppose it's supposed to obsolete that kind of stuff.

What do envision the capabilities of the finished product will be? A rough prototyping tool or something more?

I honestly don't know. That depends on what type of interest there happens to be.

[Frantz]

Basically I think that anyone writing circuit simulation code manually is just wasting their time, and lots of it.

It will be interesting to get Andy's reaction to this.


Although I know nothing about DSP, I suspect you are underestimating some of the difficulties that aciddose mentioned.

[aciddose]

I think that if solutions can be found to some of the more common problems this will make an absolutely great tool for anyone doing any sort of audio-rate electronics, period.

Ideally the goal of the project would be: find a solution for the output of a circuit that is audibly identical to the real circuit, regardless of any error in the inaudible range.

From that point you could go on to add various features like oscilloscope, fourier transform, noise analysis (identifying sources of noise and inserting them into the circuit) and real-time parameter adjustment.

The last two are some of the most difficult things to accomplish using spice. While possible, real-time parameter adjustment is generally impractical once you have many elements in the circuit operating in the mhz range as the simulation will become so bogged down by this it will no longer be possible to execute in real-time.

The solution as I said is generally to modify the circuit to eliminate such oscillations for example with slew-rate limiting and minor adjustments which will not match the real circuit anymore (since the mhz++ oscillations will be gone) but will have little to no influence on the audible range.

If that sort of system would work accurately enough for me to prototype an audio circuit like a new amp, compressor, distortion or filter and make changes and conduct analysis in real-time I'd buy it right now. $300 minimal. I would consider $500.

Something capable of taking into account noise generation inside the circuit which would allow me to fine-tune the current through various components to minimize noise in real-time without having to spent an hour doing equations, make some changes, test the result, rinse and repeat would be a god-send.

Furthering that with other features like simulation of EMI would be amazing.

I believe these are not attempted often in spice because it is so difficult to get accurate results. What we want in audio however is just a rough impression - what is the noise level in decibels accuracy and likewise for its spectrum as it passes through the circuit.

Such a tool would not only be extremely valuable as a circuit simulating VST plugin, but it would be the ultimate tool for anyone designing any sort of audio-rate circuits for any purpose.

[mystran]

Inefficient, inaccurate, prone to aliasing and uncontrollable oscillations (failure of convergence) that would not occur in a real circuit.

I also suspect that some popular simulators have some serious bugs in their implementations, since sometimes you can get convergence failures that make no sense.

You can get uncontrollable high-freq oscillations in this Salt build too.. just connect a capacitor so it's floating without a reference path (eg with the opamps, which are physically impossible), trapezoidal method will take care of the rest. You won't actually see it because of the oversampling, but it'll make stuff fail after a while. There are some ways to get Newton to fail too..

For example I've often thought that automatically reducing the slew-rate would solve most issues with convergence, and it does. These elements need to be manually inserted in a spice circuit and other adjustments made to make up for their presence.

Yeah. I don't actually do slew-rate limiting in these models here, because adding additional poles does have a non-trivial CPU cost, but you're right. Another thing (that I do here a bit, since it's cheap) is that sometimes adding tiny resistances allows solution of circuits that would be singular otherwise, because you need a voltage difference for calculation, even if Newton then converges to some tiny value that is irrelevant.

It's great to see some kind of effort going toward this. In the very least it might become a reference point to use when designing other approximate solutions. There is nothing quite like using a system in real-time to observe what are truly audible differences and the amazing complexity you can achieve by turning a few controls. Spice unfortunately doesn't come close to what we really need to efficiently test audio circuits in software.

Well, sadly I'm not exactly EE which means that some of this work is a bit slow, as I keep having to learn more electronics at the same time. Hopefully it gets a bit easier now that I can hopefully rely on the low-level stuff to actually work most of the time.

But yeah, one of the motivations really was the fact that my own personal experience with Spice has been a bit mixed. I find it great for sanity checking stuff to reduce the chance of magic-smoke when bread-boarding (are my currents within sensible limits), but then other times you really wish you could just throw it some audio and hear the results instantly.

[mystran]

Basically I think that anyone writing circuit simulation code manually is just wasting their time, and lots of it.

It will be interesting to get Andy's reaction to this.

Andy certainly knows that I'm doing work on generating code for circuits. I'd imagine he probably did not realize quite what I was after, but he knows my opinion for manual vs. automated already.

[bungle]

Pop iPlug project export on this and this could be some serious prototyping kit down the road.

[aciddose]

Yeah. I don't actually do slew-rate limiting in these models here, because adding additional poles does have a non-trivial CPU cost, but you're right. Another thing (that I do here a bit, since it's cheap) is that sometimes adding tiny resistances allows solution of circuits that would be singular otherwise, because you need a voltage difference for calculation, even if Newton then converges to some tiny value that is irrelevant.

As far as I'm aware many circuit simulators do have a constant resistance which is inserted between any component pin/terminal and the nets to help with this.

One thing I've thought about here quite a bit is finding some way to simulate the reactance of traces or wires. The only problem is that really a wire-length in schematic may not have anything to do with a real world circuit wire or trace length.

Part of the EMI simulation I suggested might involve using a "wire" component. That way the wire network could be constructed separately from the core schematic by using terminal pins.

Terminal pins and sub-circuits are of course another really useful feature.

That is all a long way off of course after getting all the basics, but it is interesting to consider.

[mystran]

Ideally the goal of the project would be: find a solution for the output of a circuit that is audibly identical to the real circuit, regardless of any error in the inaudible range.

Yeah, that was pretty close to the original idea, except in some cases I'm even willing to accept some audible error if that means it'll run in real-time.

From that point you could go on to add various features like oscilloscope, fourier transform, noise analysis (identifying sources of noise and inserting them into the circuit) and real-time parameter adjustment.

Scope and FFT are stuff that just need to be added. Dust Analyzer has it all anyway (at least in some form), it's just that it should be integrated so you could work on the internal rates, rather than second guess the output resampling.

At least limited forms of parameter adjustment will certainly happen, since I want to have knobs to tweak (essential for audio IMHO). It's only partially implemented, but it's in the general design, and I know that it'll work.

How general I can make that, I don't know. Power-cycling doesn't take long though, unless the circuit has a particularly long warm-up time, and preserving state of components through simple recompiles of the same circuit might also be possible, though I haven't tried it (could be cool for moving the output probe too though, have to think about it).

The last two are some of the most difficult things to accomplish using spice. While possible, real-time parameter adjustment is generally impractical once you have many elements in the circuit operating in the mhz range as the simulation will become so bogged down by this it will no longer be possible to execute in real-time.

Yeah, well I don't think MHz range is reasonable any time soon, maybe for very trivial circuits. The problem is the fixed sampling, and while I could probably run with adaptive too.. that runs into the problem of clean resampling from variable rates (that is important for audio quality, because you don't want resampling noise) and that's a problem I've yet to solve. I believe that's also the main reason Spice FFT plots are usually pretty limited in terms of SNR.

Such a tool would not only be extremely valuable as a circuit simulating VST plugin, but it would be the ultimate tool for anyone designing any sort of audio-rate circuits for any purpose.

Well some of the features you mention generally go a bit beyond the current scope, so at this point I don't even want to speculate whether they would be possible. I want to try and stay realistic and get one thing to work at a time.. but yeah, I can see why such stuff would be useful.