Re: Bug in Delay plug-in

| From Richard Ash <richardaudacityteam.org> 
| Sat, 19 Jan 2008 14:38:21 +0000
| Subject: [Audacity-devel] Bug in Delay plug-in
|  > On Sat, 2008-01-19 at 08:39 +0000, Gale Andrews
wrote:
> > I tend to agree it's a bit odd to normalise a
delay. I did try simply excising
> > the extraction and normalising functions but it
did not seem to work,
> > nor (for some reason) did reducing the maximum
number of samples it
> > checks to a very small number, so stopping it
working that way for any 
> > sensible length of audio. But I don't think
turning off normalization
> > will help. It looks to me as if with the same
default parameters as the
> > old delay (6 dB, 0.5 seconds, five echoes), the
current one produces 
> > vastly more clipping. Even setting decay to -20 dB
does not help.
> I wouldn't expect it to. In order to be able to apply a
delay effect to
> a signal without causing clipping you need to make the
_input_ quieter
> to make some headroom. If I try to apply echoes to
tones generated at
> 0.8 amplitude (only -1.9dB FS), then I do get clipping
quickly. Move
> down to -10dB FS input, and I can more or less do what
I like without
> problems. The less decay, and the more echoes, you use,
the more
> headroom you need to provide at the input.
> 
> This is with a simple hack that just doesn't normalise
the output, as
> attached (I haven't deleted anything, but have
commented out the old
> versions for the moment). To my mind this is a lot more
useful as a
> stock delay effect (rather than an exotic special
effect). I haven't
> tried the bouncing ball modes because I don't normally
use them.

Thanks, I can see now my mistake was removing a couple of
entire lines 
where normalise was embedded in another function, instead of
just 
removing the normalise function from that line. It also
seems that 
normalisation to that original level (0.95) was actually
causing much 
of the clipping, because much of it goes away if you just
stop the 
normalisation happening as you have done (does that make
sense?)

With "regular" mode, your version only gives
slight clipping on the
maximised pop track I was using as a "typical"
track (the worst case
where people don't deamplify first). "Bouncing
ball" gives quite a bit
more, but far less than before. My hack normalising to 0.8
doesn't 
seem to give any clipping even on a track that you don't
bother to
deamplify, but this might well cause problems on longer
tracks with
slower machines. Let's go with your way, and spell out to
them in 
the plug-in that they will normally expect to get some
clipping if they
don't reduce the amplitude of the track. I've done that,
removed the 
redundant normalisation code entirely, and added what we've
done 
to the plug-in history (attached).        

> >  I don't have the knowledge (without a lot of
reading up
> > or asking around) to fix the very latest version
of pluck, but I can fix
> > it by going back to an earlier version and then
forwards from there, so
> > that it looks/behaves like the current one but
normalizes to some chosen
> > value in the code. However it seems that you need
to set the amplitude
> > to 0.5 to ensure "show clipping" does
not pick up the first samples as
> > clipped. I also noticed the "abrupt"
control actually makes the "gradual"
> > pluck and vice versa, so I can fix that anyway. 
> 
> This is a pain, because the actual pluck operator is
built in to
> nyquist, so we have relatively little control over it
(I don't have the
> nyquist language reference in front of me). We might be
best off with
> just a fixed attenuation applied to the pluck output to
ensure it is not
> clipped (at the moment there is some quite obvious
multi-sample clipping
> going on).

OK if you want me to do anything e.g. produce the hack to
0.5 that I'd
figured out, let me know. 


Gale 

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity
-devel

On Sat, 2008-01-19 at 20:18 +0000, Gale Andrews wrote:
> Thanks, I can see now my mistake was removing a couple
of entire lines 
> where normalise was embedded in another function,
instead of just 
> removing the normalise function from that line. It also
seems that 
> normalisation to that original level (0.95) was
actually causing much 
> of the clipping, because much of it goes away if you
just stop the 
> normalisation happening as you have done (does that
make sense?)
> 
> With "regular" mode, your version only gives
slight clipping on the
> maximised pop track I was using as a
"typical" track (the worst case
> where people don't deamplify first). "Bouncing
ball" gives quite a bit
> more, but far less than before. My hack normalising to
0.8 doesn't 
> seem to give any clipping even on a track that you
don't bother to
> deamplify, but this might well cause problems on longer
tracks with
> slower machines. Let's go with your way, and spell out
to them in 
> the plug-in that they will normally expect to get some
clipping if they
> don't reduce the amplitude of the track. I've done
that, removed the 
> redundant normalisation code entirely, and added what
we've done 
> to the plug-in history (attached).        
Committed.

> OK if you want me to do anything e.g. produce the hack
to 0.5 that I'd
> figured out, let me know. 
Yes please - I'm not really sure where to go with this one
otherwise.

Richard


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity
-devel