Circuit modeled filter, how to?

[aciddose]

regarding "dull and lifeless" vs. "warm and living", or "analog" vs. "digital";

this is where i was talking about the completely different mediums. many times working with analog gear you should find yourself wanting a clean signal, yet it isnt possible. many times working with software you find yourself looking for a dirty signal, which isnt possible. we should work with our medium to take advantage of it's properties, not try to model one medium with another.

you started out saying that this filter of yours was a model of a sh-101 filter, and now you say strobe isnt meant as a sh-101 emulation, and the filter is only based upon the general function of filters like the sh-101's IR3109, aka 'ota series lossy integrator with clamped negative feedback' filters. this was the error that lead me to misinterpret the things you have said. if you had said this is a generic filter not intended to be a circuit model, i wouldn't have assumed these things about the meaning of your posts.

so, ultimately though you're working from a point where you have a generic filter, not a model. so, if we are saying the same things about not bothering to model circuits exactly due to diminishing cost vs. benefit it's odd that we have managed to take our time to mention these points. i wish you would have pointed out that your code was not a circuit model in the first place.

ultimately the only point we seem to really disagree upon is the direction from which modeling should begin. i prefer a top-down modeling method, while you appear to prefer a bottom-up method.

[andy_FX]

When I started work on strobe I was getting the diode clipper in the feedback section right - for which circuit modeling really helped, the shape generated just sounded right, since the basic diode model works just fine for audio clippers like this. I generated the audio examples from this and a basic cascade filter model with asym tanhs using a looped sample of an actual sh-101 oscillator as the input, which are the sweeps on the self osc page I posted.

I had a little synth which I called sh-101 since the filter started out there, but I have now changed loads and is called Strobe and is not a model of an sh-101. I'm lazy at naming things. I you happened to browse public directories on the vellocet sight I'm sure you would have found this plugin.

Thanks for your input on circuit modeling, I hope between us we didn't confuse people too much and we have started on making a decent resource. I would like to dispel some myths around circuit modeled plugins as the marketing hype is really offensive. I suppose the best approach is just to release better plugins which is what I'm trying to do. Some people in the field write amazing stuff - eg UAD stuff, so I hope between us all we can raise the bar and help each other make better dsp.

Thanks for posting in the other thread as well with some useful tips on what is going on inside oscillator cores.

For anyone still reading this thread I will post some qucs schematics for some simple audio circuits to get you started, and quick run downs on how to do the same thing in c++.

For people that want to check out some pwm examples look here: http://www.kvraudio.com/forum/viewtopic.php?t=208234

[andy_FX]

I believe in any type of medeling (*modeling*), be it top down or bottom up. You always have to listen to things to double check as you're going as well, and get other people to listen to your results since they have fresh ears.

When it comes to circuit components I have no idea about I have found it best to use a circuit simulator and graph them to work out what the hell they do. Once I have an understanding of what certain components in certain combinations do I can start making simplifications much more quickly, but it's really hard starting from scratch to make these types of really informed decisions.

I find the slog of playing with the models really educational. Playing with other peoples circuits is really cool since they have worked hard at this stuff and come up with some amazing stuff, and I hope to learn more of it.

In the end there is no right and wrong, there is only learning the way you work best, and knowing how to learn more.

[mystran]

I believe in any type of medeling, be it top down or bottom up. You always have to listen to things to double check as you're going as well, and get other people to listen to your results since they have fresh ears.

This reminds me of a couple of years back when I was working on my earlier oscillator designs, and used headphones to listen to high-frequency details of different unfiltered low-frequency saw-waves for several hours a day, for several days in a row, and at some point I could listen to the same sample multiple time and hear different things every time.

[andy-cytomic]

Mytran has written a cool tool that does MNA type circuit analysis as a plugin, so this basically is an automated version of what I suggested earlier in this thread: http://www.kvraudio.com/forum/viewtopic ... 6&t=398728

In it aciddose seems quite excited about this sort of tech, but in this thread he previously said is wasn't needed, which I find curiously contradictory. Here is my post to mystrans thread, which I designated as off topic, but mystran wanted it taken elsewhere so I figured this was the best place:

OT: I am curious though aciddose, why are you so excited about this stuff? I recall discussions right here on KVR me outlining this standard circuit simulation (eg forming MNA matrices and then simplifying those to be solved in real time which is exactly what mystran is doing) and you saying it was a waste of time and pointless for audio. For reference here is a good summary thread of your opinions on the topic in response to standard circuit solving methods: url to this thread

[aciddose]

Spice isn't needed. An audio-specific spice-like tool is.

My statements have been that to do anything to the level of accuracy most spice simulators are designed for is ludicrous for audio purposes.

My interest in this tool is for dedicated multi-core circuit simulation of individual circuits, not audio. I would likely never use such a tool for audio work as it would be far too inefficient.

For example I can imagine it might be possible given eight cores to run eight circuits, enough for one monophonic synthesizer at a reasonable although not "audiophile" quality level. Just good enough to get a feel for what circuit changes sound like without hitting the workbench.

The current implementation demonstrates this, unfortunately. I do not see it as very likely that even a specially designed spice-alike simulator could optimize the simulation down to the level of the equations which make practical sense for use in real-time audio.

At least not without a ridiculous amount of investment from what seems like it might be inevitably an unholy source of expertise.

If you've signed a deal with the devil by all means...

[andy-cytomic]

Spice isn't needed. An audio-specific spice-like tool is.

My statements have been that to do anything to the level of accuracy most spice simulators are designed for is ludicrous for audio purposes.

My interest in this tool is for dedicated multi-core circuit simulation of individual circuits, not audio. I would likely never use such a tool for audio work as it would be far too inefficient.

For example I can imagine it might be possible given eight cores to run eight circuits, enough for one monophonic synthesizer at a reasonable although not "audiophile" quality level. Just good enough to get a feel for what circuit changes sound like without hitting the workbench.

The current implementation demonstrates this, unfortunately. I do not see it as very likely that even a specially designed spice-alike simulator could optimize the simulation down to the level of the equations which make practical sense for use in real-time audio.

At least not without a ridiculous amount of investment from what seems like it might be inevitably an unholy source of expertise.

If you've signed a deal with the devil by all means...

I would say that spice is needed to double check results against, as are real circuits, but I'm more talking about the underlying math involved for simulation rather than the implementation. For audio dsp a more optimised implementation is required, which is what I've been doing. I've written a circuit solver that takes a spice like netlist and auto generates highly optimised SSE2 code. I've used this for my new plugin The Drop, if you would like to have a go then please email me for an NFR: www.cytomic.com/contact .

[aciddose]

No, I'm not really interested in that sort of thing though. Not unless you allow me to write the netlist?

Also I've found the SSE3 horizontal instructions to be crucial in these situations, have you looked at utilizing them?

What I'm talking about is a software tool that can be used to aid hardware development, not a software tool for software development or as a plugin for use on a DAW... I'm not interested in music really, not as anything more than something to make the gear work. Software has always been a solution for "hardware is too damn difficult" for me.

Tools that take a lot of the guesswork and mod after mod after mod while breadboarding would be an absolute godsend in my opinion. That would get me interested in hardware design again while the last few years I haven't had the drive to motivate myself over those breadboarding speed bumps.