Steve Harris wrote:
>On Fri, Nov 01, 2002 at 01:11:44AM +0100, Tim Goetze wrote:
>>
>> i'll try to work out some tables after checking for fundamental
>> dependency. what kind of windowing would you recommend?
>
>Blackman-Harris has the best sidelobe rejection, which is probably what we
just to make sure we're talking about the same thing:
double blackman (int i)
{
return 0.42
- 0.5 * cos (2 * (double) i * M_PI / WINDOW)
+ 0.08 * cos (4 * (double) i * M_PI / WINDOW);
}
is what you mean, right?
>care about here. An important thing is to catch all the components of the
>harmonic, as some will slip into neighboring bins, I'm wondering if that
>isn't one of the causes of the aparent amplitude variation of the
>harmonics.
just did the same plot with applying the above window before the FT;
it does not look fundamentally different. plot is at
http://quitte.de/spectral-evolution-windowed.gif
>Me too. I'm beginig to suspect that commercial amp models aren't really
>modelling the behaviour though.
"aren't really modelling the amp", i understand.
seeing that the proposed chebyshev emulation lends itself much
better for a series of amp models than a 'physical' model makes
me think the same.
>Its not too bad. I hacked up a quick cheby that jumps between 4 harmonic
>sets last night, recalcuating the cheby every sample. It didn't seem
>that slow.
it's probably depending on the size of the I-cache. i guess the
P-III one is bigger than the k6's, in which case loop unrolling is
more of a benefit in chebpc().
>> yep, best not to go there. however i fear the switched chebyshev
>> output can produce nasty discontinuities. we'll find out.
>
>It does. Well in my randomly picked test set it did, when the harmonic
>amplitudes are real it may be smoother. I'l clean up the code later, make
>it LERP between harmonic sets and send it to you, but I have sleave for
>work now.
could be we can get away with something like a simple four-sample
xfade, though that could introduce unrelated harmonics. better
than an unmasked discontinuity still. hmmm.
>Interesting. It takes 1/2 as much as a single (optimised) valve here.
did some tests with valve and harmonic_gen at different frames/cycle,
the results seem to support my above cache theory; the chebyshev
is costing a lot less at larger block sizes than the valve. you run
them at 128/44.1 i understand?
>> could this be to do with the 'magnitude normalization' it does?
>
>It could be, I've zapped the normalisation in the ampy one, its also
>possible that its buggy. The cheby maths came from num. rec. which
>is famously full of errors.
good god. know an alternative source for calculating the
coefficients? Bill?
tim
