Stefan, what would ratio correspond to in the soft-knee case? The limit, i.e. in the 0.5 case mentioned above 1.0?

"... When the Compressor is set for Hard knee, the compression ratio applies only to signals above the threshold level. If the Compressor is set for Soft knee, the compression ratio gradually increases from 1:1 to the currently selected ratio over a range of approximately 5 dB, so that the transition from uncompressed to compressed is more gradual. The difference between Hard Knee and Soft Knee is more obvious at high compression ratios. Once the input signal crosses the Threshold, the unit will compress the signal at the full ratio level. ..."
-- http://alesis.com/support/notes/Signal_Processing/Compterm.html

Ok, roadmap for now is the following:
1) Implement an element with the following properties:
   - characteristics = {hardknee,softknee}
   - mode = {compressor,expander}
   - ratio = [0.0;G_MAXDOUBLE]
   - threshold = [0.0;1.0]

The soft-knee solution will most probably use a bezier curve in the beginning, which will have a slope of 1 at the $threshold and a slope of $ratio$ at the maximum (i.e. 0 for expander, 1 compressor).

2) Implement additional properties:
   - attack = [0.0;GST_SECOND]
   - release = [0.0;GST_SECOND]

Attack will look "in the future" and if something above $threshold is noticed $attack seconds in the future the ratio will be raised from 1 to $ratio over this time, having full compression at the point where the input is above $threshold.

If the input is below $threshold again the compression will be lowered from $ratio to 1 in the following $release seconds. If the input gets above $threshold again in $attack seconds while lowering the compression the effect of $attack and $release are mixed.


Any additional ideas on this?

Created attachment 84087 [details] [review]
audiodynamic.diff

Ok, here's a first version of state 1). Currently it works as compressor and expander in soft-knee and hard-knee mode without any problems. Unit tests and docs integration will follow after someone reviewed this.

The only thing I'm not yet completely sure about is that I look at each channel separately. Could this lead to problems, is it necessary to look at all channels at once and apply the same rate to them? How exactly should this work?

It might also make sense to use gdoubles instead of gfloat for some intermediate variables.

looks good. some nitpicks:

* Instead of (1 - filter->ratio) I would write (1.0 - filter->ratio) to show that it is a float operation.

* what is 'zero' ? maybe a comment in the algorithm.

But basicaly, it can go in. Thanks for the hard work on this.

Ok, thanks. I committed it with some small changes (+ docs integration and unit test):

* Use 1.0 and 0.0 instead of 1 and 0 in the float cases
* Use doubles as intermediate values to prevent rounding errors
* Check in the beginning of each processing function if we actually have to do something, this removes some FIXME because division by zero can't happen anymore. One is still present though...
* Improve comments


2007-03-08  Sebastian Dröge  <slomo@circular-chaos.org>

	reviewed by: Stefan Kost  <ensonic@users.sf.net>

	* gst/audiofx/Makefile.am:
	* gst/audiofx/audiodynamic.c:
	(gst_audio_dynamic_characteristics_get_type),
	(gst_audio_dynamic_mode_get_type),
	(gst_audio_dynamic_set_process_function),
	(gst_audio_dynamic_base_init), (gst_audio_dynamic_class_init),
	(gst_audio_dynamic_init), (gst_audio_dynamic_set_property),
	(gst_audio_dynamic_get_property), (gst_audio_dynamic_setup),
	(gst_audio_dynamic_transform_hard_knee_compressor_int),
	(gst_audio_dynamic_transform_hard_knee_compressor_float),
	(gst_audio_dynamic_transform_soft_knee_compressor_int),
	(gst_audio_dynamic_transform_soft_knee_compressor_float),
	(gst_audio_dynamic_transform_hard_knee_expander_int),
	(gst_audio_dynamic_transform_hard_knee_expander_float),
	(gst_audio_dynamic_transform_soft_knee_expander_int),
	(gst_audio_dynamic_transform_soft_knee_expander_float),
	(gst_audio_dynamic_transform_ip):
	* gst/audiofx/audiodynamic.h:
	* gst/audiofx/audiofx.c: (plugin_init):
	Add new audiodynamic element which can act as a compressor or
	expander. Supported are hard-knee and soft-knee operation modes with
	user-specified ratio and threshold.
	Attack and release parameters are not yet implemented but will follow.
	* docs/plugins/Makefile.am:
	* docs/plugins/gst-plugins-good-plugins-docs.sgml:
	* docs/plugins/gst-plugins-good-plugins-sections.txt:
	* docs/plugins/gst-plugins-good-plugins.args:
	* docs/plugins/inspect/plugin-audiofx.xml:
	Integrate audiodynamic into the docs.
	* tests/check/Makefile.am:
	* tests/check/elements/audiodynamic.c: (setup_dynamic),
	(cleanup_dynamic), (GST_START_TEST), (dynamic_suite), (main):
	Add unit test for audiodynamic.