Look the filter on the schematic of the BBE Sonic Maximizer 482i :
<snip-pic>
The filter is a pseudo state variable filter composed of two integrators and a subtractor like in my filter. There are two cutoff frequencies at 224Hz and 2443Hz and not only one at 700Hz !!!
no intent to slate you over public discussions, such as forums, but i think you are terribly confusing a very common, active component, state variable topology (that has been around for ages) with something else...if you are not an electronic engineer - please excuse me.
lets start with the filter "network" itself. this is a design based on a KHN state variable filter - which is pretty much one of the most common out there.
i do not know where "224Hz and 2443Hz" come from in your calculations, so please correct me if you are running some simulations, but i can certainly point out that this filter is a _biquad_ state variable filter.
mind that, for example, the two integrators that you mention, feedback to the summator forming a biquadratic transfer function:
Code:
(in the case of the HP)
this obviously results in two poles and two zeroes on the complex plane:
Vout(s)/Vin(s) = (A*s^2)/(s^2 + s*w/Q + w^2)
therefore the filter will be of second order...
by definition, as a "state variable" filter it has only one parameter (Fc) that controls the target frequency of all possible outputs (lp, hp, bp (+ ap, br if available)). i didn't even had to calculate it when wrote the above plugin, but to be pedantic and based on the circuit...lets go:
Code:
angular frequency squared for this filter topology:
w^2 = R22/(R69 * R23 * R27 * C17 * C16)
convert all to "native" units and get the value:
w = sqrt(21500/(21500 * 21500 * 21500 * 0.0000000033 * 0.000000033))
w ~= 4457.050965705961
but we have by definition:
w = 2*pi*Fc
evaluate for Fc:
Fc = w/(2*3.1415926535) ~= 709.3616928248844 Hz
looks pretty darn close to 700 Hz.
so lets enter the schematic in circuit simulation software and look at things a bit more:
this bellow is using LTSpice. i'm mostly a QUCS user, but both programs suck in some aspects to be honest. i do like however how one draws the schematic itself in LTSpice - reminds me a little of ORCAD and CADSTAR for DOS...
notice the 180deg phase shift cased by the HP output. your HP filter would result in 90deg, since its only formed by one pole.
lets examine what happens if we reduce the impedance of R19:
we get a nice boost of the HP band, but there is a "dip" (marked in yellow), due to phase cancelation. same would not be present when summing the input with a first order high pass.
lets also examine the phase of the output node:
we get a 180 to -180 deg. phase shift. this will cause a group delay, where low frequencies are delayed (see "manual quote" in previous post).
i can sum the filter as follows:
overall, apart from the choice of Fc, the Q parameter is quite odd. they are using a more "passive" (or "constant") parameter state (notice all the R values), where the only goal is to provide lower Q, for less steeper curves. i haven't calculated a really accurate Q value in the above plugin, while only approximating, but then again the Q calculation itself is quite complex...i can say that its a based on a ratio of R25 and R26 and ends up near ~0.23.
the filter itself isn't really a "pseudo" in my opinion. they probably should have used your design instead, with a passive component topology (with first order filters), but i do think there are a couple of possible reasons behind this:
1) audiophile frequency "dip" when boosting a "band" - a bit questionable, but apparently people tend to like it.
2) longer delays for lower frequencies on the group delay plot. this in fact is used in sub-woofer design quite a lot as a compensation. the circuit design in question does that, for which i must say it does it to a certain extent in theory.
i do something "different" myself in my plugin version above though...
instead of summing the inverted output of the LP and HP with an non-inverted output of the BP, i sum non-inverted outputs of a AP, HP, LP filters, which results in pretty much the same thing (ignoring the prewarp issues caused by the bilinear transform) and it has the same performance.
Quote:
Originally Posted by domino49
In the schematic the input buffer gain is setting at +3dB and the Band-pass gain at -3dB. I set the input buffer gain and the Band-pass gain at 0dB and the low-pass and high-pass gain at +3dB. it's the same...
you might be correct on these parts, but please note that i haven't examined the exact attenuations at all. the reason behind that is i do think such a design, not providing unity gain by default, is quite _poor and lacking_...a good control interface should give the user a flat frequency response curve (unless doing something very explicit), controlled by both input and output gain, on which he can have his frequency specific manipulations. this pretty much falls in as an epitome of a correct way to do things, user interface wise for audio controls in my opinion. in this particular case, i do not care if the circuit is modeled correctly or not as i disregard the model composition completely (or so...).
zenith (my new framework, this time in pascal) has "easy porting of js plugins to vst" as an "important" feature, and these was/is nice for testing it in a more "real-life" scenario. things went pretty well, the porting took about an hour or so, mainly just blindly converting the code to pascal, and then restructuring it a little to fit the zenith framework.. some more clean-up and tweaking could be done, of course, and (at least in theory) it should be possible to just re-compile for 64bit without any changes (except compiler command line arguments), but i haven't tested this yet. ladspa is also coming..
- ccernn
and, i haven't studied the licensing agreements, so if you don't want me to port your plugins, let me know, and i'll remove it, no problem..
there's some other plugins too: (fx_clipper, fx_eventhorizon, fx_filter_rbj, fx_hallreverb, fx_pitchshift, fx_tempodelay, fx_tilteq, midi_fibonacci, midi_transpose), i'll make them available soon (and a bunch more is coming), when i have double- and triple-checked everything a few times more... always have this creeping feeling that there's some stupid bugs or problems i haven't found yet.. so if anybody find any in the above plugins, please let me know!!
btw, the math talked about in this thread is waaay over my head, so i'll let you continue your discussion without any more interruptions :-)
i do not know where "224Hz and 2443Hz" come from in your calculations, so please correct me if you are running some simulations, but i can certainly point out that this filter is a _biquad_ state variable filter.
Not a simulation but a calculation :
f1=1/(2*pi*R23*C17)=2243Hz and f2=1/(2*pi*R27*C16)=224Hz
You can obtain your value with fc=sqrt(f1*f2)=708.82Hz
You can verify in your simulation, look the -3db cutoff frequency of your HP output is at 2243Hz. You now can simulate your BP output to find the -3db cutoff frequency at 224Hz.
Quote:
Originally Posted by liteon
by definition, as a "state variable" filter it has only one parameter (Fc) that controls the target frequency of all possible outputs (lp, hp, bp (+ ap, br if available)).
Sorry it's wrong, it's only true if C17=C16 (f1=f2) this is not the case here. In fact why the designer choice two different frequencies if he want only one cutoff frequency at 709Hz. There is a infinity solution to have sqrt(f1*f2)=709 why not f1=50Hz and f2=10054Hz. Probably because you don't obtain the same filter !!!
Quote:
Originally Posted by liteon
notice the 180deg phase shift cased by the HP output. your HP filter would result in 90deg, since its only formed by one pole.
I run a simulation of my digital filter and look the phase shift caused by the HP output is in 180deg.
In red you can look the simulation of the summator output with no boost, in green with bass boost and black with High frequency boost.
Look that the junction of the bass boost and the high boost is at 709Hz !!!
Because of the scale it's not easy to read, but you can look the same "dip" in the HP boost simulation and the same phase shift (at 180deg for low frequencies).
Quote:
Originally Posted by liteon
the Q calculation itself is quite complex...
Because all resistors is a 21.5kOhms it's not so hard.
Q = ((R+R25)/(3*R))*sqrt(R23*C17/(R27*C16)) with R=21.5k
with R25=R
Q = (2/3)*sqrt(f2/f1) = 0.21068
You thought that my filter does not work because I only use a first order, you have forgotten the "state space theory" which allows the representation of any physical linear system only with a first order integrator and feedback. http://en.wikipedia.org/wiki/State_space_%28controls%29
Otherwise I think your plug is a good job and I do not claim that mine is better, only that my approach is different but not necessarily false.
zenith (my new framework, this time in pascal) has "easy porting of js plugins to vst" as an "important" feature, and these was/is nice for testing it in a more "real-life" scenario. things went pretty well, the porting took about an hour or so, mainly just blindly converting the code to pascal, and then restructuring it a little to fit the zenith framework.. some more clean-up and tweaking could be done, of course, and (at least in theory) it should be possible to just re-compile for 64bit without any changes (except compiler command line arguments), but i haven't tested this yet. ladspa is also coming..
- ccernn
and, i haven't studied the licensing agreements, so if you don't want me to port your plugins, let me know, and i'll remove it, no problem..
there's some other plugins too: (fx_clipper, fx_eventhorizon, fx_filter_rbj, fx_hallreverb, fx_pitchshift, fx_tempodelay, fx_tilteq, midi_fibonacci, midi_transpose), i'll make them available soon (and a bunch more is coming), when i have double- and triple-checked everything a few times more... always have this creeping feeling that there's some stupid bugs or problems i haven't found yet.. so if anybody find any in the above plugins, please let me know!!
btw, the math talked about in this thread is waaay over my head, so i'll let you continue your discussion without any more interruptions :-)
zenith (my new framework, this time in pascal) has "easy porting of js plugins to vst" as an "important" feature, and these was/is nice for testing it in a more "real-life" scenario. things went pretty well, the porting took about an hour or so, mainly just blindly converting the code to pascal, and then restructuring it a little to fit the zenith framework.. some more clean-up and tweaking could be done, of course, and (at least in theory) it should be possible to just re-compile for 64bit without any changes (except compiler command line arguments), but i haven't tested this yet. ladspa is also coming..
- ccernn
and, i haven't studied the licensing agreements, so if you don't want me to port your plugins, let me know, and i'll remove it, no problem..
there's some other plugins too: (fx_clipper, fx_eventhorizon, fx_filter_rbj, fx_hallreverb, fx_pitchshift, fx_tempodelay, fx_tilteq, midi_fibonacci, midi_transpose), i'll make them available soon (and a bunch more is coming), when i have double- and triple-checked everything a few times more... always have this creeping feeling that there's some stupid bugs or problems i haven't found yet.. so if anybody find any in the above plugins, please let me know!!
btw, the math talked about in this thread is waaay over my head, so i'll let you continue your discussion without any more interruptions :-)
Hi,
It doesn't work, because "libcairo-2.dll" can't be found... !?
My god I wish I could understand this discussion. If they'd told me at school that mathematics was the language of the universe, I would have paid more attention. Now when I try to teach myself stuff like this it just won't stick in my head.
Not a simulation but a calculation :
f1=1/(2*pi*R23*C17)=2243Hz and f2=1/(2*pi*R27*C16)=224Hz
You can obtain your value with fc=sqrt(f1*f2)=708.82Hz
You can verify in your simulation, look the -3db cutoff frequency of your HP output is at 2243Hz. You now can simulate your BP output to find the -3db cutoff frequency at 224Hz.
yes, but you are dissecting the topology wrongly in this case. you cannot ignore the feedback, which will essentially provide 12db/octave cutoff due to the couple of integrators, present. no need to look at slopes in this case, since the Q is low enough to look like filters from lower order...
Quote:
Sorry it's wrong, it's only true if C17=C16 (f1=f2) this is not the case here. In fact why the designer choice two different frequencies if he want only one cutoff frequency at 709Hz. There is a infinity solution to have sqrt(f1*f2)=709 why not f1=50Hz and f2=10054Hz. Probably because you don't obtain the same filter !!!
nobody states that the two capacitors (C17=C16) have to be equal for the state variable filter to work. not necessarily!
also please, note how all equations involve C1 and C2 instead of a single C value.
C1=C2 is a special case, which we should ignore here, since we don't have that in the circuit.
Quote:
I run a simulation of my digital filter and look the phase shift caused by the HP output is in 180deg.
<img>
In red you can look the simulation of the summator output with no boost, in green with bass boost and black with High frequency boost.
<img>
Look that the junction of the bass boost and the high boost is at 709Hz !!!
Because of the scale it's not easy to read, but you can look the same "dip" in the HP boost simulation and the same phase shift (at 180deg for low frequencies).
ok, this is the strange part which you provide...
in the DSP version, you are clearly using leaky integrators to form a band splitter (even the author of the 3-band-splitter(joiner) Mich/LOSER can confirm that). so let me get this straight - you are stating that your HP output has a 180 deg. phase shift?
example from your version is:
HP_output = (input - leaky_integrator_output)
not sure what software you are using, but these are the outputs i get using the "VST plugin analyzer" by Christian Budde (that _a lot_ of people are using as well). basically it loads the JS-VST with your FX version and plots what it does:
i've normalized the output, so that there aren't band boosts by default. (3db etc..)
phase of the HP output (sp4):
looks like 90 deg. to me...
phase of the band sum:
Quote:
Because all resistors is a 21.5kOhms it's not so hard.
Q = ((R+R25)/(3*R))*sqrt(R23*C17/(R27*C16)) with R=21.5k
with R25=R
Q = (2/3)*sqrt(f2/f1) = 0.21068
i've said its complex indeed, with the formula in front of my eyes. but please note, that i didn't even have to calculate it to get a good estimate of ~0.23 for Q. (i.e. not using the formula at all).
then again, where do you use the Q calculation in your DSP plugin, with first order filters, if the original filter has it ?
Quote:
You thought that my filter does not work because I only use a first order, you have forgotten the "state space theory" which allows the representation of any physical linear system only with a first order integrator and feedback. http://en.wikipedia.org/wiki/State_space_%28controls%29
Otherwise I think your plug is a good job and I do not claim that mine is better, only that my approach is different but not necessarily false.
your version makes sense as well, but i think you are approximating quite a lot...
state space is clear on my part, and yes you can do whatever you want with first order filters but not in this case, based on the cicruit.
also, a "dip" will never be present from summing leaky integrators with the input, since such will have only one pole.
i can bring this discussion into KVR and Music-DSP, for some other opinions on the subject, if you still think your DSP solution is correct. i personally wouldn't care much, who is right and who's wrong...but for some educational accuracy i guess?
in the your DSP version, your are clearly using leaky integrators to form a band splitter (even the author of the 3-band-splitter(joiner) Mich/LOSER can confirm that). so let me get this straight - your are stating that your HP output has a 180 deg. phase shift?
Yes. It's a leaky integrator ... or for the more technical folks: it's the digital equivilant to an analog RC-filter.
The phase response for which is (lowpass): http://upload.wikimedia.org/wikipedi...m_RC-Glied.svg
__________________
Quote:
Originally Posted by vBulletin Message
Sorry pipelineaudio is a moderator/admin and you are not allowed to ignore him or her.
It's a typical bi-quad band-pass resonant filter with a free running oscillations frequency f = 1/(2*pi*sqrt(L*C)) (Not to be confused with a cutoff frequency) and a Q factor Q = w*L/R
The block diagram representation of the state space equations is :
The bloc diagram representation of our L-R-C circuit is then :
We have two first order integrator and a summation to feedback.
If we want make a digital model of this circuit, we must find an digital equivalent of integrator. For this we can use the "Euler" method and the Z transform.
With the "Euler" method a digital equivalent of differential operation is :
Te is the sample time : Te = 1 / (sample rate)
Now we can use this equivalent to solve our differential equation :
We can deduce the recurrent equation of our differential equation :
q(n) = Te*i(n) + q(n-1)
We can easily deduce the second integrator :
i(n) = Te*di(n) + i(n-1)
It's easy now to program this L-R-C circuit with the scientific calculation software "Scilab" :
With Scilab we can generate the impulse response of the filter and calculate the FFT to have a Bode diagram. The complete Scilab code can be downloaded here :
http://forum.cockos.com/attachment.php?attachmentid=13464&stc=1&d=13231624 53
The Bode diagram of the tree output of this filter is :
The Resistor potential Vr is in Black and it's a Pass-band filter
The Capacitor potential Vc is in Red and it's a Low-Pass filter
The Inductor potential Vl is in Green and it's a High-pass filter
We checked the validity of our model and we can now use it in a JS plug-in.
Now let's see if we can generalize our filter, return to our bloc diagram :
With our digital transformation the bloc diagram is :
The q(z) feedback coefficients 1/(LC) can be decomposed by (1/sqrt(LC))*(1/sqrt(LC))
One of two (1/sqrt(LC)) can be move before the first integrator and and the other before the second integrator. For not change the i(z) feedback we multiply its coefficient (R/L) by sqrt(LC). The bloc diagram become :
We know that in a resonant L-R-C filter, the pulsation Wc = 1/sqrt(L*C) and the Q factor Q = w*L/R, also the bloc diagram become :
It is now easy to write a JS plug-in to test our filter :
You can test this plug and listen the resonance effect impossible to obtain with a first order filter.
Conclusion:
We prove that with the theory of the state space that it was possible to build a high order filter only with a sum of first order "leaky" integrator.
Programming this filter can be more simple than the classic Laplace transform especially for filters with a multiple input and output and because the number of coefficients does not explode with the order of filter.
But why do it simple if you can do it complicated.
To understand the state variables filters I suggest to study a L-R-C circuit
i hope this is not aimed at me specifically...
[part1]
you propose a series (not the more widely used parallel) LRC resonator circuit, show the difference equation and find the state-space representation from the vector-matrix. then plot the freq. response and phase, based on a fixed natural frequency and Q.
obviously any band pass filter is of second order, minimum.
[part2]
you present a general state space block diagram (or "flow graph").
you draw the LRC flow graph, apply z-transform, solve the recurrence relation.
so far so good...
[part3]
you plot the flow graph of the digital filter and then you simplify the coefficients based on the already known angular frequency and Q factor.
i really don't understand why didn't you even begin with this approach if you are so knowledgeable, but i'm sure you can now clearly see that all the JS code that you posted before this was for another, completely different filter network and therefore wrong as a model. also i'm pretty sure you've missed the part where i've mentioned i understand state space (for my own good).
----
now lets begin with the problems of your DSP filter in comparison to my biquad realization. i do agree however that there is a big trade-off as my version is much more expensive for the cpu, and yes its unstable for higher orders:
1) the phase is still wrong. you are missing the part where "some" of the outputs have inverted phase. this is essential for the summed output phase to work, based on the modeled circuit.
2) you filter is _extremely_ unstable for higher frequencies (above 7k) even for lower Q. Q itself is frequency dependent unlike the KHN state variable filter we are modeling.
3) there is a frequency warping problem near niqust and the filter has to be oversampled at least 4 times (in my opinion), so that the problem is reduced.
so i'm starting to question if the filter is going to be faster than the biquad method.
4) your choice of the calculation for the coefficient couple Wc*Te is not ideal.
but, really...since we are only interested in fixed parameters for our model, overall this is a correct way to do it.
infact, here is how you could do it (or modify it):
Code:
desc:state variable (bbe)
slider1:1<1,10>LG
slider2:1<1,10>HG
@slider
// params
Fs = srate;
Fc = 708;
Q = 0.21;
// this is a preferable f coefficient calculation. an alternative to your Wc*Te
f = 2*sin($pi*Fc/Fs);
// q is the same obviously
q = 1/Q;
// pots
lgain = slider1;
hgain = slider2;
@sample
in = spl0 = spl1;
// recurrence relation
lp = lp + f*bp;
hp = in - lp - bp*q;
bp = f*hp + bp;
// notice the phase of the BP here.
// also we compensate for 'q' so that the BP output is normalized
// and therefore a flat freq. response
spl0 = spl1 = lp*lgain + hp*hgain - bp*q;
// result:
// apart from the gain levels (HG, LG),
// the frequency response, phase response and group delay
// are very similar to the desired model
i don't have much more free time for such discussions to be honest, but i really think you should change the version you posted in the first post...it is just wrong...you cannot grab other people's code, calculate a couple of target frequencies and tap your name and a model of some hardware unit on top of the code.
reapercurious, look at your post counter in previous post! 8-() (trying to be just a little more mathematical)
I`m watching the Battle of Plug-In Titans, holding my breath and waiting for the Happy Ending wich will be true and correct JS Implementation of BBE Sonic Maximizer, or, maybe, another great plugin from these Monsters of Mind!
Please continue, domino49 and liteon! Your conversation is truly fascinating!
i suppose that whoever has the last word wins these sorts of discussions. what was wrong with the bbe sonic maximizer? what was the argument about by the way? I couldn't find the conflict.
Location: decepticon mothership in a hidden place inside a mountain
Posts: 3,754
This maximizer solved an issue i had in a mix to make a beat more boomy but still "clean" and unobstruive. It worked like a chamr !
THanks again, it is a clever tool
Location: decepticon mothership in a hidden place inside a mountain
Posts: 3,754
Hello
For anyone interested, there is a VST version of the Sonic Enhancer, using the code provided for the JS, and a GUI draft i had made. It was compiled by Elements Plugins (with the authorization of the authors).
On my computer, I have to create copies of this plugin and rename each one different, then change the fx name in reaper for each to reflect that, otherwise the standard "more than one plugin instance open causes crash" happens.
Anyhow, thank the gods and heavens for this plug.
Last edited by reapercurious; 02-05-2013 at 07:04 PM.
-feb 05. 2013:
fixed spikes when second instance loaded on the same track;
fixed incorrect control voltage for high band; now better compares with the originaj JS.
Location: decepticon mothership in a hidden place inside a mountain
Posts: 3,754
Quote:
Originally Posted by olilarkin
sinkmusic - would you like me to build a mac version of the exciter plugin?
Hello, Oli
Yes, of course : i don't have a Mac, but i think many people would happy to use it.
But, to make things clear : i haven't made much myself : all the coding is made by skilled reaperites (as it was initially a JS plugin), i just made the simple red GUI (posted a while ago as a sketch on Reaper forum), and another reaperite (Bodan) compiled it as a VST.
All Kudos belong to the devs
I tried the JS version on page 1 with the "Peek detector".
I was pleasantly surprised at what it does, seeing as how I also have the hardware version. We used to use it on a small PA in clubs. Quick easy adjustment of highs and lows.
So, today I tried the Red MaxSonic one and for my money, I believe that JS version sounds better. It has a little more "sparkle".
I think the crossover points are different or something. Anybody else seeing this?
I don't know if it made any difference, but I had to change this line in the JS file:
R=21.5e3; which caused a compile error to this:
Linear Mode
