Salt - tech preview / test demo

[aciddose]

Is it excessively difficult to get PNP transistors to work once you have the NPN model you're using?

I notice you're calling audioMasterAutomate 0 ... 3 with 0.0f, then 0 ... 2 again, but 3 with 1.0f inside main() before returning where the host has a chance to set the reserved host pointer. The plugin won't load in reaper, this may be why. I was able to get it working okay in my own host and it spits out the warnings for the host callback with null host pointer.

Going to try a waveshaper/amp using common base and see what kind of results come out.

[mystran]

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.

Yeah, you can also find simulators that do not. That said, currently it's not something I do automatically, it needs to be part of the component models. I probably should write code for some simple tagging though, so it would be less work to add those (just tag the pins you want it on).

[aciddose]

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.

When I mentioned this I wasn't very clear. What I meant was say your simulation is running at a rate of 2mhz, the oscillations will start to appear usually at 1mhz. Not something that would actually happen in the circuit but a consequence of some error being introduced. How long it takes these oscillations to settle has a major effect upon how quickly the rate can be adjusted back down in a variable rate simulation.

I have solved smooth variable rate re-sampling: minblep You can even use minblamp to handle anti-aliasing the integrators. This is of course the same as interpolation by convolution with a windowed sinc. Only you're convolving with a step or ramp rather than impulses and it's possible to ignore samples that have not changed significantly, which makes it amazingly efficient.

My implementation of this re-sampling is performing equally as well as higher order polyphase filters with 1/10th or less the cpu requirements.

The cutoff of course remains set by the sinc impulse regardless of how many impulses you mix per sample period. It doesn't ever become unstable because you're not having to integrate the result, and it is an excellent performer because it doesn't matter how many impulses you insert per sample, ten thousand or one ten-thousandth. The performance is instead related to the re-sampling ratio.

No need to worry about stacking polyphase half-band filters. Just insert more impulses.

[andy-cytomic]

And credits, since I forgot to include a README:
...
Oh and.. thanks to Andy (of Cytomic) for generally encouraging emails.
....
Seriously: the "zero-delay feedback" math is a freaking trivial thing in the grand scale of things.

You're welcome Mystran This is a really cool project, I hope it goes well!

In the long run, once you have sorted out the c code generation and licensing etc, I suggest that instead of using a jit you look into auto generating sse2 code and using llvm to dynamically compile a lib and re-load that. You will get stereo for free and much better performance and it won't make much difference at all to turnaround time between making and edit and hearing the change.

[mystran]

Is it excessively difficult to get PNP transistors to work once you have the NPN model you're using?

No. You turn the diodes the other way around.

I notice you're calling audioMasterAutomate 0 ... 3 with 0.0f, then 0 ... 2 again, but 3 with 1.0f inside main() before returning where the host has a chance to set the reserved host pointer.

Urgh? That sounds like weird behavior from the frame-work code.. nothing Salt specific should be happening at that point... unless you seriously managed to break something just recently.

The plugin won't load in reaper, this may be why. I was able to get it working okay in my own host and it spits out the warnings for the host callback with null host pointer.

Urgh.. sounds like I might have broken something then. I'll have to investigate.

Going to try a waveshaper/amp using common base and see what kind of results come out.

I sincerely hope that it actually works, at least in some sense.

[andy-cytomic]

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.

There are many good circuit simulators that are very efficient and that product excellent results, but I agree that the goals of music audio are very different to those of engineers designing integrated circuits. Inefficient is a relative term, the number of parameters they handle for components introduces large numbers of branches, and they are stuck using sparse matrix methods since they need to be able to handle thousands of components.

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.

As you probably know (but for those others reading that may not) good audio circuit designs actually do this sort of thing, they add extra components to reduce high frequency content like parasitic oscillations, for example adding by a capacitor in op-amp feedback paths to form one pole low pass filters with a cutoff around 30-60 khz (depending on the position in the signal chain). Such high frequencies are a problem for audio circuits since they can cause problems in the audio range as well due to a variety of effects.

Another possibility is to use different numerical integrators that already introduce "artificial" damping. For example backwards euler introduces no 1/2 nyquist wobbles like trapezoidal and so looks much better when you look at time domain plots. The most popular circuit simulation integration method that introduces damping is "gear", which is like RK4 but implicit.

...Spice unfortunately doesn't come close to what we really need to efficiently test audio circuits in software.

I completely agree. It's handy to have spice as a reference to double check some very short (1ms) test signals, but I do the majority of my work auto generating / fine tuning sse2 code and pressing compile and run.

[aciddose]

http://xhip.net/temp/itworks.mp3

This is a simple common-base amp between two buffers. What happens is the signal gets limited by the saturation of the transistors on either side, one at a time. You can adjust the input bias to adjust symmetry and of course input resistance to change the gain.

Great little saturating amp for dynamic mics, extremely low noise.

You can see the ability to fully rotate as well as mirror the transistors would be great (8 total positions) since otherwise you get that wire madness happening

Works anyway though. Not much effort at all. Compared to some schematic apps this is actually a breeze .

[mystran]

You can see the ability to fully rotate as well as mirror the transistors would be great (8 total positions) since otherwise you get that wire madness happening

Yeah, just a GUI limitation really.

Works anyway though. Not much effort at all. Compared to some schematic apps this is actually a breeze .

I'm glad that it works. Does it work as expected too?

I was a bit worried about what you are going to throw at it exactly, but yeah that looks simple enough that it should work.

As for the trapezoidal vs. Gear.. I have BDF2 working as well [but no automatic order-selection], but it's not well-tested and there's no interface for changing it (so it's still #ifdef only) so I didn't try to include it here as I figured trapezoidal would work well enough.

[camsr]

I had a bug with the solver quit working. Was just messing with some diodes for a half wave rectifier, changing their polarity. I set it back to how it worked previously and still no audio.

Is there a way to delete components?

[mystran]

In the long run, once you have sorted out the c code generation and licensing etc, I suggest that instead of using a jit you look into auto generating sse2 code and using llvm to dynamically compile a lib and re-load that. You will get stereo for free and much better performance and it won't make much difference at all to turnaround time between making and edit and hearing the change.

I don't know. I'm not terribly excited about the whole "stereo by SIMD" thing, since it means accepting the worst-case iterations for both channels. I have some plans of trying to vectorize the actual reduction code by detecting structurally similar patterns and scheduling them together... so I could then run the other channel in another thread parallel (for a whole block, to ideally average out the iteration differences).

I looked into LLVM before I went with the custom compiler strategy. I could try and see if it can extract something out of my output, but I suspect it, since I already work at floating-point instruction level.. [so basically it can maybe schedule instructions better.. register alloc it probably could match but probably not do much better]

Just to make clear, I have no plans of emitting "high-level" C-code because.. there is no high-level code that would make sense. Rather the whole point is to emit C code is just to be able to include it projects, because it is portable where the JIT is not (it'll still look like portable assembler).

The remaining issues with that have to do with things like handling sample-rate changes: with the JIT I can just recompile, but for external code I need to include the logic to rebuild the constant pool, because that stuff is constant folded (because otherwise it could prevent a lot of other constant folding). It's not exactly rocket science, but it's not done yet.

[mystran]

I had a bug with the solver quit working. Was just messing with some diodes for a half wave rectifier, changing their polarity. I set it back to how it worked previously and still no audio.

Is there a way to delete components?

Shift-right-click.

Urgh.. can you maybe send me a screenshot (teemu@signaldust.com) of the circuit where you had trouble [if you still have it]. In general though.. power-cycling SHOULD fix any situation where the simulator gives up. If you found a way to permanently break it, then .. that would be a bug (and not just a simulation problem).

[mystran]

About the Reaper problem.. in v4.402 that I have installed, it appears to load just fine.. debugger shows no exceptions either.. no idea what might be the problem..

edit: It must be something to do with the factoryBank loading.. but hmmh.. the initial clear is from August this year, but the fact that it send automation (if there's a factoryBank, but Tila has had it back then) has been there at least since 2010 (my git log seems to end there) and this is the first time I hear about the problem.. So I really doubt Reaper would be crashing on that, it must be something else.

[camsr]

I had a bug with the solver quit working. Was just messing with some diodes for a half wave rectifier, changing their polarity. I set it back to how it worked previously and still no audio.

Is there a way to delete components?

Shift-right-click.

Urgh.. can you maybe send me a screenshot (teemu@signaldust.com) of the circuit where you had trouble [if you still have it]. In general though.. power-cycling SHOULD fix any situation where the simulator gives up. If you found a way to permanently break it, then .. that would be a bug (and not just a simulation problem).

Will do the next time it happens, and thanks!

[mystran]

I would like to remind everyone though, that this is not exactly production quality yet: there's a bunch of things that are glued together in pretty ugly ways just to get something wrong.

[aciddose]

About the Reaper problem.. in v4.402 that I have installed, it appears to load just fine.. debugger shows no exceptions either.. no idea what might be the problem..

Some bug in their 64->32 bit bridge apparently. Or something in salt that only shows up with the bridge in use.

If it would be mostly trivial to get a basic pnp model working that would be great. fets I suppose can be roughly done by replacing them with an opamp before the base of the npn, at least in some use cases in amplifiers.

A rough fet implementation though would be required to get accurate oscillator and sample&hold models going. You can just very, very roughly approximate it using a non-linear voltage controlled resistor I believe. Doing a fet I assume would be non-trivial though of course

Even without it I'll see if I can do anything a little more interesting. I think rather than additional components, input control voltages and variable resistors are far more important.

An input voltage should be identical to a signal generator shouldn't it? Then the more GUI related stuff would be showing knobs for those, specifying voltage range or resistance range although it would also make sense to just take the value from automation inputs.

One thing I'm noticing is that although restarting the simulation makes sense when you're changing components radically, small changes should be possible to cope by starting the next cycle with the previously known values. Then having a "reset" or "panic" button to actually zero and start from scratch would be needed of course for cases where that fails but making minor changes wouldn't result in the whole circuit having to settle back into its stable state.

Another thing that might come in very handy is an ability to create wires, maybe in a different color to mark them to show the initial dc operating point calculated for the net they belong to. That's another completely GUI related thing though. (Or probably you've already thought of using additional 'test points' to do this.)