>Judging by this C++ library,
>
>https://github.com/vinniefalco/DSPFilters
>
>it shouldn't depend on the filters themselves, whether they can be made
>sweepable or even have "smooth parameter changes".
>
>So I guess there's some general technique?
>Judging by this C++ library,
>
>https://github.com/vinniefalco/DSPFilters
>
>it shouldn't depend on the filters themselves, whether they can be >made
>sweepable or even have "smooth parameter changes".
>
>So I guess there's some general technique?
Haven't you look the source code?
---------------------------------------
Posted through http://www.DSPRelated.com
Reply by Matti Viljamaa●July 15, 20162016-07-15
On Friday, July 15, 2016 at 11:01:13 AM UTC+3, Tauno Voipio wrote:
> On 15.7.16 10:45, Matti Viljamaa wrote:
> > Judging by this C++ library,
> >
> > https://github.com/vinniefalco/DSPFilters
> >
> > it shouldn't depend on the filters themselves, whether they can be made sweepable or even have "smooth parameter changes".
> >
> > So I guess there's some general technique?
>
>
> The library does IIR filters, which are DSP implementations of classical
> continuous-time analog filters. It seems that the
> library uses the analog filter design equations and transforms
> them to the sampled-data domain using the bilinear transform.
>
But how does it achieve sweepable filters? Or smooth parameter changes?
Reply by Tauno Voipio●July 15, 20162016-07-15
On 15.7.16 10:45, Matti Viljamaa wrote:
> Judging by this C++ library,
>
> https://github.com/vinniefalco/DSPFilters
>
> it shouldn't depend on the filters themselves, whether they can be made sweepable or even have "smooth parameter changes".
>
> So I guess there's some general technique?
The library does IIR filters, which are DSP implementations of classical
continuous-time analog filters. It seems that the
library uses the analog filter design equations and transforms
them to the sampled-data domain using the bilinear transform.
This is fine as long as you keep far enough away from the Nyquist frequency.
Please note that the filters are not just for arbitrary passband or
stopband, but only the classical lowpass, highpass, bandpass and bandstop.
For the classical filter design methods, get a filter design textbook.
--
-TV
Reply by Matti Viljamaa●July 15, 20162016-07-15
Judging by this C++ library,
https://github.com/vinniefalco/DSPFilters
it shouldn't depend on the filters themselves, whether they can be made sweepable or even have "smooth parameter changes".
So I guess there's some general technique?
Reply by Wolfgang Sörgel●July 14, 20162016-07-14
On 06/24/2016 02:44 PM, Matti Viljamaa wrote:
> How are filters that have their cutoff and e.g. Q variable (such as in a typical parametric equalizer) done?
One possible solution is to use filter structures where coefficients are
more directly related to the desired filter characteristics to be
adapted than simple biquads / direct structures. E.g. lattice structures
/ wave digital filters, ie. filters based on all-pass structures. This
can lead to filters where e.g. cutoff-frequency of a lowpass-highpass
pair nearly linerly depends on some coefficients in a certain frequency
range and your "filter design" comes down to a simple interpolation.
> Does this mean that the filter coefficients are recalculated (i.e. the filter is redesigned) every time the parameters are changed?
>
> What kind of other design considerations are involved (such as computational efficiency)? What about "smooth parameter changes", is it interpolation (and how is this adapted to recalculating the filter coefficients?)?
>
Reply by bitrex●July 4, 20162016-07-04
On 06/29/2016 06:33 AM, Matti Viljamaa wrote:
> On Tuesday, June 28, 2016 at 11:46:59 PM UTC+3, herrman...@gmail.com wrote:
>> On Monday, June 27, 2016 at 9:13:48 PM UTC-7, robert bristow-johnson wrote:
>>> if you have infinite computational power, you can slew the user
>>> parameter each and every sample and recalculate all of the coefficients
>>> each sample.
>>
>> Having not actually tried it, if you have a ROM look-up table with filters of
>> various center frequencies and Qs, does that help?
>>
>> Changing the center frequency is like changing the sampling rate.
>>
>> With the size of ROMs today, you could put a really large table of
>> precomputed coefficients in, and just look one up when needed.
>>
>> Maybe 1024 center frequencies, equally distributed in log frequency
>> space, and 1024 Qs. Choose the closest one.
>
> Does this kind of "quantization" of the frequencies lead to the stepping being heard when the parameters are changed? I.e. that the auditory response sounds "stepped"? Or is there a way, e.g. dense enough table, so that the response still sounds smooth?
>
I believe the way it's done in some commercial implementations is to
reduce zipper noise, the filter coefficients are recomputed when the
control "voltages" are being swept at low speed, and it switches over to
linear interpolation between stored coefficients at high rates, where
any artifacts due to the coefficients not being specifically computed
for that center frequency will hopefully be masked by the sweep.
Reply by robert bristow-johnson●July 4, 20162016-07-04
On Sunday, July 3, 2016 at 3:24:56 AM UTC-4, jtp_1960 wrote:
> >Software. And well, we can take RBJ's filters as an example.
> >
> >Since the cookbook gives parameters for Q, gain and cutoff, then
> >how are these actually varied in a real-time implementation? Does
> >one construct a table of the values and vary between them?
>
there might be a lotta dimensions to the table. doing more than 2-dimensional table lookup (and maybe interpolation) is a real pain in the ass and not particularly computationally cheap.
> None of my real-time (GEQ/PEQ) implementations uses lookup tables but
> calculates new filter coefficients in real-time for the filter which
> parameter was changed. This is smooth operation even when you make fast
> changes for parameters. (I'm talking 'bout 2nd order system but in my
> implementations there's also file writing and graphics plot done right
> after coefficient calculation).
>
> I've seen lookup table based fixed Q/bw graphical EQ implementations (cf's
> and Q/bw are constant, only gain changes) but, AFAIK, parametric EQ would
> be much more complicated to implement through lookup tables because of all
> parameters are changeable.
maybe if the numerator coefficients were done arithmetically with the boost/cut gain, the denominator coefficients can be done with a two-dimensional table lookup. one dimension might be the base 2 log of of the resonant frequency and the other dimension would be either log of Q or BW in octaves.
but it's not hard to just crunch out the numbers. this does not have to be done for each and every sample unless you want **really** good (i.e. smooth) modulation performance. you might be able to recalculate coefficients periodically (every 8 or 16 or 32 samples) and then, on a sample-by-sample basis, slew the coefficients from their previous value to the new values as computed from the user parameters (Q and w0).
but it depends on how wildly you might be expecting to modulate the parameters. you might not even want to use the Direct Form 1 for it. you can still use Cookbook formulae for the coefficients in the biquad transfer function and then map those to coefficients in the Lattice Form. check out http://web.eecs.utk.edu/~roberts/ECE506/PresentationSlides/LatticeLadder.pdf you will find out that one of the Lattice coefficients, k1, fully defines the resonant frequency, w0. you can really crank on that k1 coefficient and maybe not get a filter that blows up on you.
r b-j
Reply by Bob Masta●July 3, 20162016-07-03
On Sat, 2 Jul 2016 08:05:15 -0700 (PDT), Matti Viljamaa
<viljamaadsp@gmail.com> wrote:
>On Saturday, July 2, 2016 at 5:37:06 PM UTC+3, jtp_1960 wrote:
>> >I want to understand general ways of transforming filters that are
>> >specified "statically" (i.e. that the coefficients are supposed to stay
>> static)
>> >into dynamically variable filters. Many filter books seem to describe
>> filters
>> >mainly only statically as if they would be "designed and then left so",
>> >eventhough most digital audio applications call for parameters that the
>> user
>> >can vary in real-time.
>>
>> Maybe some example case could help here?
>> ---------------------------------------
>> Posted through http://www.DSPRelated.com
>
>I believe you can pick any filter design and it doesn't specify how to make a "variable" version of it. Rather, it only gives the equations for designing a static filter or static filters.
>
>So the question then is, how to make it variable like in a typical, practical parametric equalizer.
Certainly with analog filters the "variable" conversion is
straightforward: The standard approach to analog filter
design is to break it into 2-pole stages (plus a single-pole
stage if the total is odd). Pick a topology where the
frequency of each 2-pole stage is controlled by a pair of
matched resistors (usually different for each stage) and
replace (conceptually) with a ganged potentiometer.
In reality you'd use OTAs... cumbersome, but fairly standard
in analog synths.
A nifty method I first saw mentioned by Don Lancaster in the
"CMOS Cookbook" is to use real Rs but put a CMOS analog
switch in series with each. (Make sure the switch "on"
resistance is small compared to the tuning resistance.)
Then apply high-frequency PWM to all the switches, well
above the audio range. The effective resistance is
increased as the duty cycle decreases, and all the stages
track together, even though they have different tuning Rs.
This works great, but is practically limited to a 10:1 range
or so, in my experience.
Best regards,
Bob Masta
DAQARTA v9.20
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, Pitch Track, Pitch-to-MIDI
FREE 8-channel Signal Generator, DaqMusiq generator
Science with your sound card!
Reply by jtp_1960●July 3, 20162016-07-03
>Software. And well, we can take RBJ's filters as an example.
>
>Since the cookbook gives parameters for Q, gain and cutoff, then >how are
these actually varied in a real-time implementation? Does >one construct a
table of the values and vary between them?
None of my real-time (GEQ/PEQ) implementations uses lookup tables but
calculates new filter coefficients in real-time for the filter which
parameter was changed. This is smooth operation even when you make fast
changes for parameters. (I'm talking 'bout 2nd order system but in my
implementations there's also file writing and graphics plot done right
after coefficient calculation).
I've seen lookup table based fixed Q/bw graphical EQ implementations (cf's
and Q/bw are constant, only gain changes) but, AFAIK, parametric EQ would
be much more complicated to implement through lookup tables because of all
parameters are changeable.
---------------------------------------
Posted through http://www.DSPRelated.com