> um, it's a semantic thing that i just wrote about in response to Urs. i > don't use the term myself, but i am defining "nodal analysis" the way i see > virtually all other lit doing it. when spice is modeling non-linear > circuits, it is using Kirchoff's current law on every node, Kirchoff's > voltage law on every loop, and the explicit volt-amp characteristic on every > device connected between those nodes. those are the physical axioms. if > you wanna call that "nodal analysis", fine by me (but i don't use that term, > myself). > > but if you're using Spice to give you a quickie frequency response to an > ideal op-amp circuit with resistors and capacitors, it's doing what we call > the "node-voltage method" (in the s-domain) which **is** limited to > independent and dependent sources and impedances. and it solves a system of > linear equations. you need to count each of these parts between nodes as > something that obeys the s-domain version of Ohm's law. that's the only way > you can write the linear equations and solve them to get a meaningful and > consistent frequency response which is a function only of the circuit with > respect to its input and output terminals. that frequency response is not a > function of the applied signal or anything outside of the circuit.
Few! And I thought I would have to pull all my products from sale because the didn't work! ;) Another slight possible confusion is that most circuit simulation isn't "nodal analysis" but "modified nodal analysis" which is just done so they can stick everything into a matrix form. > i'm no more an "expert" on DF-anything. i am just saying that, when it's > LTI (and i am referring to some hand-written papers i've seen of yours a > couple years ago) it's gonna boil down to an H(z). then there is, as far as > the input-output behavior and frequency response goes, an equivalence of the > various topologies that get the same H(z). the different topologies have > different behaviors regarding clipping and quantization noise and > time-varying behavior (less worried about the occasional knob twist than for > the filter modulated with a tremelo signal). it is *for* *those* *reasons* > i have an interest in the different topologies, but not for calculating > coefficients to get a desired frequency response. LTI = no changes in parameters, so sure, then it comes down to the numerical properties of the realisation >> You just store a single state per capacitor actually, please read these >> for >> some examples: www.cytomic.com/technical-papers >> >> > > i've been there a while ago. are there new papers now? I have updated a few of them, and added a breakdown showing how a one pole active / passive low pass is solved and leads to an identical implementation when using "nodal analysis" which has been around for ages and compare this to some "newly invented" methods. >> I would guess that for guitar circuits if the cutoff frequencies are >> around >> 80 hz at the lowest then after two seconds of not moving any knobs the >> that >> any linear filter that hasn't blown up would settle to sound the same >> given >> infinite processing resolution, but I have not done research into this so >> I >> would not bank on it, especially when direct circuit simulation is so >> straight forward, and then the non-linear case can also be handled with >> identical machinery at the cost of more cpu. > > > 1/(2 seconds) is about 1/2 Hz. two orders of magnitude between 0.5 Hz and > 80. i'm would be surprized, outside of a chaotic system (which is > non-linear on steroids), if there was any transient left after even a half > second. If time varying behaviour is important then even 1/2 is too long. It depends on the specific project as to what is an appropriate tradeoff of accuracy and cpu use. For a non-modulatable linear tone stack I would say a double precision 3 pole DF1 is a good low cpu solution and but there should be decent bandwidth limiting of automation to prevent problems. The thing with music is that fast automation can sound really cool too, so if it's only a slight cpu overhead then I think it is worth supporting that. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
