Thank you.
peakmeters - yep, actually EQG10 had build-in peak-meter (in some alpha vers.) but i've decided to remove it.
The truth is that we've already run out of dsp resources (so that in next kx ver 30 -Timbre is used instead of EQ for SBLive models...)...
So actually i'm thinking about some "smarter" peakmeter architecture - like maybe peakmeter as separate "child" plugin which can be loaded/unloaded automatically when user enables/disables metering, but with view of it from same EQ window of course...
As for compressor, yep, i think, the good way will be to put peakmeter right into compressor code... actually, there's nothing difficult to do this... Also i'm not sure about 29, but for 28 and all of erlier versions it could be done without any special controls/functions of kx (see instructions below)...
>with less than 1% of resources more
yep, but see above, Live have no even 1% of resource this days (damn mixer

...
>And an automatic gain control to avoid clipping would be very apreciated too.
Presets for EQ are designed with "same volume subjective feel" in mind, so yep, clipping may of course occure for some material depending on its spectral content...
>And an automatic gain control to avoid clipping would be very apreciated too.
But not built into EQ itself. "Input Gain" is there exactly for such situation.
Separate "Limiter" or "AGC" plugins put before output stage of kx dsp would be another option (but not loaded by default).
>Another thing, will be this gui avaliable in the SDK?
Some day. It's actually hard a bit to publish something solid these days, since native kxgui and so uniform (kxgui independend but somewhat linked to ) are being constantly updated now... Also i'd prefer to concentrate on writing plugins themselves raither then on making SDK for them at the moment.
I'll publish some example sources for "uniform" soon maybe, although, i don't think they will be too usefull without any documentation.
---------
PeakMeter
---------
(i've posted this on some mailing list some days ago)
---------
Code:
name "peak meter";
created "07/23/2002";
input in
static peak
temp t
log t, in, 31i, 1i
limit peak, t, t, peak
end
just read the value of "peak" register on some timer (for example ~16 times per second) and write zero to it after reading...
#define UNITY_GAIN_COEFF 0x78000000L // this is for standard 0.25 level
#define MAGIC_NUMBER 0xaaaaaaaa
ValueToShow = (peak - UNITY_GAIN_COEFF) / MAGIC_NUMBER;
/* this for example gives you ValueToShow right in decibels... (of course you need more presice measurement so you need to decrease MAGIC_NUMBER or make ValueToShow to be float/double... - i use MAGIC_NUMBER = 0x111111 which gives me ValueToShow in centibels, Eugene uses some other "floating point" formula as i know etc... that depends on how you are going to show "peak" to user) */
/max
-----------
Well, as for visual implementation, so before kx29, one could use MFC's CProgressCtrl for example or something similiar... However, these days, maybe it's too late to use MFC with native kx plugin api (since kxapi/kxgui are being rewritten to be MFC free) and too early too use new kxgui for that (since it is not yet complete, E., fixme, is special control dedicated to peakmetering there?)...