18 May
2010
18 May
'10
11:03 p.m.
On Tue, 18 May 2010 22:56:44 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Mon, May 17, 2010 at 02:29:01AM -0700, Ken Restivo
wrote:
This is rather disturbing. I had noticed that jamin was quite
processor heavy, but was unaware that this was unnecessary. Has this
been discussed with the devs? Mostly I like the way it sounds and works,
and the interface it presents (not that I have much to compare it
with). I would rather see it improved than dropped.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Well, Fons kind of sniffed at Jamin-- "you
are mastering through a vocoder"
Well, that is not really what I wrote:
Responding to:
> I was thinking about tearing into the code
for
> something like Jamin to look at what's done there. Maybe there are
> better examples for me to use though?
I wrote:
Jamin's FFT based filter is not really a
filter, it's a vocoder
being used as a filter and it has side effects.
Which is just true. It's also true that changing the window
function and increasing the FFT overlap has reduced the
artefacts to below -80..-90 dB w.r.t. the signal. But that's
not a solution but a cover-up, coming at the expense of a lot
of wasted CPU load - Jamin takes 35% on my 2GHz P4. For what
it is doing 5% would be reasonable. And it doesn't help to
bypass the EQ: it is *always* in circuit, even if the response
is forced to flat when you enable the 'bypass' checkbox. Nor
does it help to improve the atrocious type of responses that
the 'HD' filter will generate if you are just a bit unlucky.
Ciao,