Re: [LMMS-devel] Request: peak controller decay

[Paul G. <dr...@gm...>]

Well, the clicks are probably from two different causes:

1) no decay on the Peak Controller.  Very large changes in the audio
signal will cause the peak controller to adjust by a large amount too.
 If you want the Peak Controller to be less rapid, then a decay
feature will help smooth the curve and make it more 'spongy'

2) However... even in this case, there is still the problem that
Controller changes are only considered once per-period.  Assume your
buffer-size is set to 256 samples (frames, whatever).  In this case,
there the controllers change once every 256 samples.  This is a
restriction in LADSPA, LV2, and many other plug-in technologies.

There are a few workarounds.  The host (LMMS) can run the plugins for
1-sample buffers. This is EXTREMELY slow, especially with how LMMS
distributes work (it expects the DSP code to take a while).  This is
only practical when rendering to a file.

Another workaround is to have controllers use a buffer of values for
the rendering period instead of a single value.  Some LADSPA plugins
do this I believe for inputs such as pitch-bend.  However, many
plugins must recalculate coefficients etc for these changes which
results in a slow-down again.  Also, this requires the plugin author
to decide which control ports (pitch-bend, volume, cutoff freq, etc)
get this treatment.

Finally, the most common approach (that I have seen) is for the plugin
to handle the problem.  In this case, peak-controller is behaving
fine.  Instead, it is the job of the connected plugin to interpolate
the values of their inputs if not doing so would result in artifacts.
For example, it will ramp from last_value to current_value over the
current rendering period.  Also, the plugin can decide to not
interpolate the value of an input that would cause performance issues.
 This is a nice approach I think.  It also circumvents the
"recalculate coefficients problem" to a degree because the plugin may
be able to optimize for a linear interpolation much better than 256
explicit values.

In conclusion, a decay feature would be nice and achieve certain
effects.  But, it will probably not fix the "zipper effect" you are
hearing.  This is probably more a problem with the attached effect or
instrument.

What are you controlling with the peak controller by the way?

Paul

2011/1/12 Tobiasz Karoń <un...@gm...>:
> Hi!
>
> I'am not sure if this list is the right place to place requests (if there is
> a better one, please gimme a link), anyay:
> Peak controller needs decay!
> The decay knob is already there and what is says from ~5 releases (that I
> remember) of LMMS is : "not implemented yet!"
> This is a very important feature as it gives us the possibility to use
> side-chain compression, but without decay it's very limited and produces a
> lot of bad clicks.
> Check out the project file I gave here for an example.
> Drums making bass dodge generate a lot of clicks.
>
> Is there any information about how does the peak controller work and how to
> implement the decay feature in it? I'd try to do it myself.
> Please help!
> --
> Tobiasz unfa Karoń
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
> !N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
> b+>+++ DI>+ D+ G e h-->- !r y--()
> ------END GEEK CODE BLOCK------
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> LMMS-devel mailing list
> LMM...@li...
> https://lists.sourceforge.net/lists/listinfo/lmms-devel
>
>