On Tue, Mar 19, 2013 at 1:02 PM, Fons Adriaensen f...@linuxaudio.orgwrote:
The code below will do the trick
Brilliant, thanks for sharing. Will be implementing learning from this
later, appreciated!
-Harry
___
Linux-audio-dev mailing list
[Fons Adriaensen]
On Tue, Mar 19, 2013 at 04:26:21AM +0100, Tim Goetze wrote:
A 2nd-order IIR filter is often called a biquad; at musicdsp, look
for that instead.
Not really. A biquad is one way to implement a 2nd order IIR, and
in many cases related to audio DSP, not really the best way.
On Tue, Mar 19, 2013 at 03:02:19PM +0100, Tim Goetze wrote:
for (i = 0; i nframes; i++)
{
g1 += w * (gt - g1 - a * g2);
g2 += w * (b * g1 - g2);
out [i] = g2 * in [i];
}
Surely you realise this version executes exactly as many additions and
multiplications per sample
[Fons Adriaensen]
On Tue, Mar 19, 2013 at 03:02:19PM +0100, Tim Goetze wrote:
Surely you realise this version executes exactly as many additions and
multiplications per sample as a biquad?
Yes. In this case it's possible to remove one multiplication:
a = 0.07f;
b = 1 + a;
// ...
gm = b * gt;
On Tue, Mar 19, 2013 at 04:46:10PM +0100, Tim Goetze wrote:
However, I still take issue with the rather exaggerated claim that
using a biquad to smoothen gain changes would be giant overkill. It
may be slightly less efficient than your now optimised version, but
certainly not enough to
Spring is nigh.
Qtractor 0.5.8 (india romeo) is out, singing a serenade...
Nothing but the change-log (see below:))
Enjoy lots of fun.
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
[Fons Adriaensen]
Exactly the same with the form I proposed, w, a, b need to be computed
just once, not for every gain change. In fact only w depends on the
sample rate, a and b are fixed constants.
Ah yes, sorry, I see that now.
If that extra operation comes around to bite hard enough, I'll
Hi all,
Hopefully this will be useful to others. I just wrote a short note
describing my experiences when moving from a SysV init script based
OpenMixer[*] system to one that uses systemd. In short, yes, it is
possible, no, it was not easy (mostly because of my own ignorance of
systemd, of
On Tue, Mar 19, 2013 at 08:15:41PM +0100, Tim Goetze wrote:
[Fons Adriaensen]
Exactly the same with the form I proposed, w, a, b need to be computed
just once, not for every gain change. In fact only w depends on the
sample rate, a and b are fixed constants.
Ah yes, sorry, I see that now.
On Tue, Mar 19, 2013 at 2:15 PM, Tim Goetze t...@quitte.de wrote:
[Fons Adriaensen]
Exactly the same with the form I proposed, w, a, b need to be computed
just once, not for every gain change. In fact only w depends on the
sample rate, a and b are fixed constants.
Ah yes, sorry, I see that
On Tue, Mar 19, 2013 at 05:26:27PM -0500, Charles Z Henry wrote:
You guys are splitting hairs... kind of misses the forest for the trees.
Here's my nit to pick: two identical 1st-order lowpass filters in series
are only equivalent to a 2nd-order lowpass filter when the quality factor
is 0.5.
On Tue, Mar 19, 2013 at 5:57 PM, Fons Adriaensen f...@linuxaudio.orgwrote:
On Tue, Mar 19, 2013 at 05:26:27PM -0500, Charles Z Henry wrote:
You guys are splitting hairs... kind of misses the forest for the trees.
Here's my nit to pick: two identical 1st-order lowpass filters in series
are
On Tue, Mar 19, 2013 at 06:12:21PM -0500, Charles Z Henry wrote:
If it was always a fixed time over which you need to fade in, I think you
could find a good analytical function to use, or make a table that always
has a predictable effect.
Raised cosine is a good solution, but you don't need
13 matches
Mail list logo
