Re: [LAD] New stuff: zita-dpl
On 12/05/2011 12:22 AM, Fons Adriaensen wrote:
Hello all,
First release of zita-dpl1. Look-ahead digital peak limiter.
1-16 channels (highest one determines gain reduction).
More athttp://kokkinizita.linuxaudio.org/linuxaudio.
excellent, thanks!
builds and runs fine, will probably be using it for real before the end
of the week. can i suggest two small extensions?
* it would be great to have the input gain displayed numerically in the
display as well - i need to document my sessions so that i can always
revisit them in case the client requests changes. now i could just make
a screenshot (as i do for zita-rev1, which works because small
deviations in setup don't have dramatic effects), but for limiting, i
need absolute precision and 100% reproducible settings. trivial patch is
attached.
* i'm assuming you are looking at the maximum level of all channels, and
then apply the same amount of gain reduction to each of them. certainly
the way to go in speaker-based mixes. but as i already mentioned over
that coffee at ICSA, do you think it could be useful to add an ambisonic
mode which would apply the gain reduction only to the component that's
actually over? my hope is that the result is more subtle, because only
the source sharpness would change slightly, and with b-format, there is
no danger of irritating jumps of the source...
best,
jörn
diff -urN zita-dpl1-0.0.1/source/mainwin.cc zita-dpl1-0.0.1-new//source/mainwin.cc
--- zita-dpl1-0.0.1/source/mainwin.cc 2011-12-04 22:18:55.0 +0100
+++ zita-dpl1-0.0.1-new//source/mainwin.cc 2011-12-05 12:12:28.135265876 +0100
@@ -62,6 +62,7 @@
_dispmap = XCreatePixmap (dpy (), _dispwin-win (), 315, 72, disp ()-depth ());
_dispgct = XCreateGC (dpy (), _dispmap, 0, NULL);
init_disp ();
+print_param (R_INPGAIN);
print_param (R_THRESHD);
print_param (R_RELTIME);
_dispwin-x_map ();
@@ -227,14 +228,20 @@
switch (k)
{
+case R_INPGAIN:
+y = 0;
+v = _inpgain-value ();
+sprintf(s, %2.1lf dB, v);
+C = XftColors [C_INPGAIN];
+break;
case R_THRESHD:
- y = 5;
+ y = 18;
v = _threshd-value ();
sprintf (s, %5.1lf dB, v);
C = XftColors [C_THRESHD];
break;
case R_RELTIME:
- y = 25;
+ y = 36;
v = _reltime-value ();
if (v = 0.30f) sprintf (s, %4.2lf s, v);
else if (v = 0.03f) sprintf (s, %3.0lf ms, 1e3f * v);
diff -urN zita-dpl1-0.0.1/source/styles.cc zita-dpl1-0.0.1-new//source/styles.cc
--- zita-dpl1-0.0.1/source/styles.cc 2011-12-04 22:29:36.0 +0100
+++ zita-dpl1-0.0.1-new//source/styles.cc 2011-12-05 12:16:31.955871428 +0100
@@ -42,6 +42,7 @@
XftColors [C_DISP_BG] = disp-alloc_xftcolor (0.1f, 0.1f, 0.1f, 1.0f);
XftColors [C_TEXT_BG] = disp-alloc_xftcolor (0.9f, 0.9f, 0.9f, 1.0f);
XftColors [C_TEXT_FG] = disp-alloc_xftcolor (0.0f, 0.0f, 0.0f, 1.0f);
+XftColors [C_INPGAIN] = disp-alloc_xftcolor (0.9f, 0.9f, 0.2f, 1.0f);
XftColors [C_THRESHD] = disp-alloc_xftcolor (1.0f, 0.2f, 0.2f, 1.0f);
XftColors [C_RELTIME] = disp-alloc_xftcolor (0.6f, 0.6f, 1.0f, 1.0f);
diff -urN zita-dpl1-0.0.1/source/styles.h zita-dpl1-0.0.1-new//source/styles.h
--- zita-dpl1-0.0.1/source/styles.h 2011-12-04 22:32:35.0 +0100
+++ zita-dpl1-0.0.1-new//source/styles.h 2011-12-05 12:11:12.092205429 +0100
@@ -30,7 +30,7 @@
{
C_MAIN_BG, C_MAIN_FG, C_DISP_BG,
C_TEXT_BG, C_TEXT_FG,
-C_THRESHD, C_RELTIME,
+C_INPGAIN, C_THRESHD, C_RELTIME,
NXFTCOLORS
};
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] New stuff: zita-dpl
On Mon, Dec 05, 2011 at 12:20:24PM +0100, Jörn Nettingsmeier wrote: * it would be great to have the input gain displayed numerically in the display as well - i need to document my sessions so that i can always revisit them in case the client requests changes. now i could just make a screenshot (as i do for zita-rev1, which works because small deviations in setup don't have dramatic effects), but for limiting, i need absolute precision and 100% reproducible settings. trivial patch is attached. Applied, thanks. * i'm assuming you are looking at the maximum level of all channels, and then apply the same amount of gain reduction to each of them. Yes. certainly the way to go in speaker-based mixes. but as i already mentioned over that coffee at ICSA, do you think it could be useful to add an ambisonic mode which would apply the gain reduction only to the component that's actually over? my hope is that the result is more subtle, because only the source sharpness would change slightly, and with b-format, there is no danger of irritating jumps of the source... Actually that is not true - sources would move. Imagine a simple WXY system. You have a source at 45 degrees and one at 90. The one at 90 (say some percussion) makes Y go into limiting. This means the one at 45 will move forward. So any gain change would have to affect equally at least all components of the same degree. And even that can only be done for a short time, as modifying the gain of one degree makes a complete mess of the decoding - rE will drop sharply and rV can take on any value, even go 'negative'. After at most a few tens of milliseconds the other components would have to follow. So that would require separating transient gain changes from longer ones. This would be possible in e.g. a compressor, but for a peak limiter (which has to ensure that no samples are over 0dB whatever happens, and operates in feed-forward mode) it can become quite difficult. I tried something similar: to make transient gain changes affect only the mid and high frequency part of the signal, but I had to abandon that idea (at least for now) - it really gets very hairy. Assuming it could be done, the limiter would have to know which channels belong to the same degree. No problem if you only have complete sets, but I want to support horizontal only and mixed order sets as well. The plugin system in AmbMixer can handle this. Others could mayby do it with a few more extensions, but those would always imply explicit AMB support by the host. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] New stuff: zita-dpl
On 12/05/2011 02:50 PM, Fons Adriaensen wrote: On Mon, Dec 05, 2011 at 12:20:24PM +0100, Jörn Nettingsmeier wrote: * i'm assuming you are looking at the maximum level of all channels, and then apply the same amount of gain reduction to each of them. Yes. certainly the way to go in speaker-based mixes. but as i already mentioned over that coffee at ICSA, do you think it could be useful to add an ambisonic mode which would apply the gain reduction only to the component that's actually over? my hope is that the result is more subtle, because only the source sharpness would change slightly, and with b-format, there is no danger of irritating jumps of the source... Actually that is not true - sources would move. Imagine a simple WXY system. You have a source at 45 degrees and one at 90. The one at 90 (say some percussion) makes Y go into limiting. This means the one at 45 will move forward. right, now i see the problem.. So any gain change would have to affect equally at least all components of the same degree. And even that can only be done for a short time, as modifying the gain of one degree makes a complete mess of the decoding - rE will drop sharply and rV can take on any value, even go 'negative'. After at most a few tens of milliseconds the other components would have to follow. So that would require separating transient gain changes from longer ones. This would be possible in e.g. a compressor, but for a peak limiter (which has to ensure that no samples are over 0dB whatever happens, and operates in feed-forward mode) it can become quite difficult. I tried something similar: to make transient gain changes affect only the mid and high frequency part of the signal, but I had to abandon that idea (at least for now) - it really gets very hairy. Assuming it could be done, the limiter would have to know which channels belong to the same degree. No problem if you only have complete sets, but I want to support horizontal only and mixed order sets as well. The plugin system in AmbMixer can handle this. Others could mayby do it with a few more extensions, but those would always imply explicit AMB support by the host. thanks for elaborating. i agree, it's too hairy to be worth it, and i dislike tools that try to be too clever - even if it could be done, i'm sure it will confuse some users in corner cases, and the final stage of a production is not a good place for interesting surprises... best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
