JohnN

I suppose I missed that...

I've added automation to all control and tweaked the graphics.
Links as above.

Let me know if it works.

BR
JN

__________________
AMD 64 skt 939 4000+, 2G DDR, XFX6800GT, 80G + 200G, Audigy2 Value, IKEA room

Russ

Me too...

Something is off with the automation. I just did a quick automation test with aux8_1, aux8_2, and aux8_3, and it controlled aux8_8, aux8_9, and aux8_10.

-Russ

<edit>
More Info (kX Automation):

aux8_1 = aux8_8
aux8_2 = aux8_9
aux8_3 = aux8_10
aux8_4 = aux8_11
aux8_5 = aux8_12
aux8_6 = aux8_13
aux8_7 = aux8_14
aux8_8 = aux8_15
aux8_9 = aux8_16
aux8_10 = aux1_m
aux8_11 = aux2_m
aux8_12 = aux3_m
aux8_13 = aux4_m
aux8_14 = aux5_m
aux8_15 = aux6_m
aux8_16 = aux7_m
aux8_m = aux8_m
</edit>

<edit2>
I tested with aux1 as well, and they map correctly except for aux1_m which maps to aux2_1.
</edit2>

JGSF

I've had that same problem yesterday, in my case it was because of wrong
typedef enum _params_id{} definitions (junk left from previous tries).

Russ

Yes, it seems that maybe the _params_ID array and _param_descr array are using a different ordering (although that is just a guess).

Personally, since all of the parameters are of the same type, and thus are handled the same way, I would probably make the above arrays use the same ordering as the GPRs, and then just use one handler in set_param for all of them (instead of a bunch of different case statements, etc).

i.e. (psuedocode)
double x = ... (calculate value)
set_dsp_register(AUX1_1_P + ndx, x);

The GUI sync code could be handled in a similair way.

-Russ

JohnN

I'll have to check to which parameters these refer - with out them in front of me, I'm not sure.
I know that the "automation" array is differnt to the enumation ID list.

The automation has aux1_1 to aux1_16 + aux1_m. Repeat for aux2 to aux8.

The enum ID list though is AUX1_1_ID to AUX1_16_ID, AUX2_1_ID to AUX2_16_ID etc. The 8 MAIN controls, AUX1_M_ID to AUX8_M_ID were added afterwards and so are at the end of the list. That stacks-up with your tests which show all 8 aux mains to be consecutive AND at the end !

Didn't realise there was a correlation between position and the control.
The automation panel appears to list by name, hence my mistake.

I'll look tonight!

BR
JN

__________________
AMD 64 skt 939 4000+, 2G DDR, XFX6800GT, 80G + 200G, Audigy2 Value, IKEA room

Russ

It is the array indices (not the names) that are used to determine which parameter to set, so they need to be ordered such that set_param is called with the correct index.

The enum ID's just give you a friendly name to use in your code instead of having to use the array indices directly, and the names used in _param_descr are just the user friendly names that show up in kX Automation.

JGSF

I have another problem...
I was adding some vu meters to mine, but without using extra GPR's (I am using the dynamica plugin vu meter code).

The meter works and shows the correct position, *but* it has cyclic maximum peak spikes.

Any idea of what might be causing this?

Garbage stored in the GPR that it is reading the value from at some point?

(It is getting the readings directly from the inputs in my case, no aux GPR's)

JohnN

Automation fixed.... I hope !

http://homepage.ntlworld.com/john.ni...kX/kxpoint.zip


VU meters?
Hey, Johnny, are you a manager in the Real World; changing requirement specifications halfway through a project?
:-)
(/jk)

Sorry, don't know what could be causing your spikes.
I lifted my VU meters from one of the mixers; I think it may have been mx6.

BR
JN

__________________
AMD 64 skt 939 4000+, 2G DDR, XFX6800GT, 80G + 200G, Audigy2 Value, IKEA room

Russ

How can you use the Dynamics Processor code without the extra GPRs?

The standard peak code (DSP code), is to take the abs of the signal, and then compare that value with the current peak value, and save which ever value is greater. The Dynamcis Processor uses this same code, so I wonder how you can use its C++ code without the corresponding DSP code?

Russ

I tested automation with aux1, aux8, and main, and they seem to work correctly now.

JGSF

lol, nevermind that, it's just my experiments... Since I started messing around with it too... At least I'll learn something out of it...

Russ:

/*== INPUT VU ================================================== ====*/
x1 = (float) (8.68588963800 * log((double) [COLOR=Red]reg_in_L[/COLOR] + 1) - 174.597397471);// in fractional format & log scale
pos1 = (int) (VU_px_0dB - x1 * VU_sca_pxdB);// VUmeter position
pos2 = pos1; //since it's mono
if (pos1 != pos_in_L) // if position change
{
m_in.set_value(pos1, pos2, 0, 0);
m_in.redraw();
pos_in_L = pos1;
pos_in_R = pos2;
}

Besides the other pieces of code I used, I replaced reg_in_L with an input register in my code (besides some values (and bitmaps) I had to re-scale to make the meter about 5 times smaller).

I confess I didn't even looked at the DSP code in the dynamica plugin, I assumed that the meter stuff was all made with C++ code... (and since the name was reg_in_L I thought "hey, this must be an input").

Russ

If you look at the part that actually reads the register, you will see that it reads the register and then sets it to zero (you would not want to do this to an input/output).

By reading the input directly you are just getting a semi-random value (i.e. one sample) of the signal's waveform at the time that the timer fires, when what you want is either the peak value up to that point, or some average of the values up to that point, etc.

JGSF

Is possible to do all that without the extra register? I managed to solve the spikes, but I still I have these problems:

- meters won't update on -inf
- meter reading is unstable

---------------------------------------------------

plugin->get_dsp_register(CH1,&x1_temp);

if(temp<abs(x1_temp)) //temp is declared in the iDemoPluginDLG class and init. with CH1 value

{
temp=abs(x1_temp);

x1= (float) (8.68588963800 * log((float) (abs(x1_temp)) + 1) - 174.597397471);
pos1 = (int) (VU_px_0dB - x1 * VU_sca_pxdB);// VUmeter position
if (pos1 != pos_in_ch1) // if position change
{
m_in.set_value(pos1, pos1, 0, 0);
m_in.redraw();
pos_in_ch1 = pos1;
}
}

plugin->get_dsp_register(CH1,&temp);

------------------------------------------------

Maybe I should look somewhere else in the dynamica code?

To see how the meters behave:

click

Russ

Again, without the registers, you are reading in semi-random data.

i.e.
You are reading one sample every time the timer fires (ignoring the rest of the samples). With a high (fixed) frequency periodic signal, it may give the impression that it is working, but try it with actual music...

Also, if you are going to monitor the input directly (as opposed to monitoring something internal to your plugin, that otherwise could not be accessed), then there is not much advantage in adding the peaks to your plugin, when the same thing can be done using external peak plugins (i.e. you could use ProFx:Peak8). With your plugin, you are not saving any GPRs by including the peaks within the plugin, so the only advantage I can see is that you would not need a second window open. When you included the Main volumes it was a little different, because the peaks could monitor the input as modified by those volumes, which could not be done for each channel externally, but monitoring the input can be done externally.

JGSF

The inputs were just for testing (as those were the first two in the code), it was intended to be used for each channel aux send and final mix, to make it easier to check if all was working... but ok, I'll leave it without meters (attempts), the important thing is that it works.

Russ

It is your plugin so do what you want of course... and playing around will not hurt anything... I am just not sure what the peaks would represent for the per channel aux settings.

i.e.
It sounds like you want:
PeakC1 = ch1_aux1_amount + ch1_aux2_amount + ch1_aux3_amount...
PeakC2 = ch2_aux1_amount + ch2_aux2_amount + ch2_aux3_amount...

The above would show the total for each channel, but I am not sure how that makes sense on a peak meter, as the output is sent to different sends (i.e. the total amount per-channel is not what is output). It will show that adjusting one of the levels affects the level on the meter, but the total value per-channel does not really mean anything to the total value per send.

Peaks on the final mix makes more sense, but again, you can get the same thing by connecting a ProFx:Peak4 to the output of the plugin (and you have the option to unload it when you do not need it), etc.

In any case, the dsp code is not hard.
i.e.
For the final mix peaks:

macs aux1, 0x0, aux1, aux1_out; final aux1 value
log tmp, aux1, 0x1, 0x1; tmp = abs(aux1)
limit PeakM1, tmp, tmp, PeakM1; if tmp >= PeakM1, PeakM1=tmp

(PeakM1 is a static GPR)
Do the same/similair for the other peaks.
In the C++ code, PeakM1 would be the register to read, and reset to zero (for aux1 final mix), etc.

If you look at the last 4 instructions of the Dynamics Processor, you will see that it does basically the same thing (except it uses tstneg to do the abs, and uses a couple of temp registers, instead of 1 temp).

JGSF

I'll keep trying... but not so often now, other hard work ahead to do...

Thanks for your valuable help, guys.