.kxl plugin and default settings...

Russ · Feb 19, 2007, 07:14 PM

Can anyone think of a reason why a .kxl plugin would not work until the reset button is clicked?

The reason I ask is because I have run into a situation where for some unknown reason this is happening with a plugin.

Why would clicking reset do anything different than what occurs when the plugin is loaded?

Additionally, the default values are hard coded into the DSP code.

If I look at the code dump before and after the reset button is clicked (default values, etc), it is identical. However, when examining the registers (current value -vs- previous value -vs- default value ) one of the gprs shows a value of 0 (as the current value, with the previous value being the default value) before reset is clicked. It seems as though something is happening in the code that is causing that value to reach 0, before it is fully initialized, and it remains 0, because it is used as a multiplicand (and of course, anything multiplied by 0 is 0), and thus the plugin does not work. However, when clicking reset, it works as it should.

Modifying the value in question (using a slider, etc), also makes the plugin work, but again, I cannot explain why the default values at load time do not work, but the same default values do work when reset is clicked (or when adjusting the sliders to the same default values, etc).

Anyone have any thoughts about this?

Tril · Feb 19, 2007, 11:42 PM

I don't have any idea. Which plugin is that?

Russ · Feb 20, 2007, 12:00 AM

I was making some changes/updating my phaser plugin, and it started doing that.

In any case, it is easy enough to work around, and one of the changes I am making to it, will prevent it from happening anyway. I am just curious as to what could cause it to act that way, considering it should be using the same code when loading, and when setting defaults.

Tiger M · Feb 20, 2007, 03:11 PM

That's a bug I guess...

Russ · Feb 20, 2007, 04:01 PM

Yeah, it is strange, but considering I have never seen that heppen before... I am not sure what to think about it.

Russ · Feb 20, 2007, 07:32 PM

@Tril,
Here is something interesting...
I was looking at your TimeBalance plugin, to see if I could see anything that might be giving frost_dk problems, and I noticed that the load-time values for the iTram addresses are not valid (outside the iTram address range).

i.e. (here is a partial dump after loading the plugin)

idelay write dwFL at 0x0;
idelay read drFL at 0x241c127;
idelay write dwFR at 0x241c128;
idelay read drFR at 0x483824d;
idelay write dwRL at 0x483824e;
idelay read drRL at 0x4838250;
idelay write dwRR at 0x4838251;
idelay read drRR at 0x6c449a4;
idelay write dwC at 0x6c449a5;
idelay read drC at 0x6c500a4;

Note that your iTram size is 4190, so none of the above addresses should be above 0x105e (they are way out of range).

However, after clicking reset (or adjusting a slider):

idelay write dwFL at 0x0;
idelay read drFL at 0x2;
idelay write dwFR at 0x3;
idelay read drFR at 0x5;
idelay write dwRL at 0x6;
idelay read drRL at 0x8;
idelay write dwRR at 0x9;
idelay read drRR at 0xb;
idelay write dwC at 0xc;
idelay read drC at 0xe;

This is making me wonder if maybe there is something wrong with the plugin loading code in 3538m.

BTW: Although the addresses seem off when loading the plugin, it does not mute my sound when connected (as with frost_dk), but maybe this is a contributing factor to the problem that frost_dk is having.

Russ · Feb 22, 2007, 07:40 PM

Update: The problem with the TimeBalanceV2 plugin turned out to be something else, and considering I have not had this problem (thus far) with any other plugins (and I allready changed my phaser code such that it does not happen anymore (i.e. I can no longer test it)), I am not willing to say (with certainty) that it is a bug. So I guess we should just forget about it for now...

**Eugene Gavrilov** · Feb 24, 2007, 03:21 PM

without the source I won't be able to help
I guess something went wrong with C++ stuff (inheritance or class instantiation)
E.

Russ · Feb 25, 2007, 11:00 AM

@Eugene,

Thanks for responding

There was a bug in my code similar to the issue Tril was having with his TimeBalanceV2 plugin, and although, I think it should not have caused this (with my plugin), it is a bug none-the-less, and was likely a contributing factor. In any case, as I said previously I have allready modifed the code (with changes I was planning to do anyway, as well as fixing that bug), and it is no longer a problem.

Lex Nahumury · Feb 25, 2007, 11:25 AM

Quote:

Originally Posted by Russ

There was a bug in the code similar to the issue Tril was having with his TimeBalanceV2 plugin, and although, I think it should not have caused this (with my plugin), it is a bug none-the-less, and was likely a contributing factor. In any case, as I said previously I have allready modifed the code (with changes I was planning to do anyway, as well as fixing that bug), and it is no longer a problem.

Sorry, perhaps I missed something, but what is all this vague talk about 'bug'???
I presume you mean a bug in your plugin code. Not in kx api right?

Russ · Feb 25, 2007, 11:36 AM

Yes, I mean a bug in my plugins C++ code.

Lex Nahumury · Feb 25, 2007, 12:00 PM

ok. got me worried there for a moment lol

Russ · Mar 3, 2007, 06:20 PM

<edit>
I removed the C++ source code since the problem happens with Dane only plugins.
</edit>

-Russ

Maddogg6 · Mar 3, 2007, 08:36 PM

Well - I can only confirm this behavior on my card as well..

Russ · Mar 3, 2007, 09:55 PM

BTW: (I allready mentioned this before, but) I do realize that with the way the code uses these registers, it is not good to use it only in multiplication operations (because if it does go to zero (for whatever reason), it will stay there), and the other version does not do this. The main thing I wonder about, is why it goes to zero instantly after loading, but not when setting defaults.

BTW: It does the same thing if you copy and paste the code into a new (Dane only) plugin, so that would seem to indicate that the plugin's C++ code is not the problem.

Max M. · Mar 4, 2007, 03:39 AM

> It does the same thing if you copy and paste the code into a new (Dane only) plugin

is there any pure dane code for this i can look in?

Russ · Mar 4, 2007, 08:34 AM

Quote:

Originally Posted by Max M.

> It does the same thing if you copy and paste the code into a new (Dane only) plugin

is there any pure dane code for this i can look in?

Actually, I think I am going to have to do some more testing with the Dane code, because if I make a plugin with only the code that effects those 2 registers (using the same default valules), the problem does not happen.

i.e.

Code:

    static sw_val1=0x94c92c0, sw_val2=0x4c899e8;
    static sw_up=0x10000c1d, sw_down=0xffff3e3, sw_min1=0x4a64960;
    static sw_max1=0x12992581, sw_min2=0x2644cf4, sw_max2=0x99133cf;
    static sw_fac1=0x10000c1d, sw_fac2=0x10000c1d;
    temp tmp1;

     
     macs      sw_val1,  0,  sw_val1,  0.125;
     
     macs      sw_val2,  0,  sw_val2,  0.125;
     
     macints      sw_val1,  0,  sw_val1,  8;
     macs      sw_val1,  0,  sw_val1,  sw_fac1;
     macints      sw_val1,  0,  sw_val1,  8;
     
     macints      sw_val2,  0,  sw_val2,  8;
     macs      sw_val2,  0,  sw_val2,  sw_fac2;
     macints      sw_val2,  0,  sw_val2,  8;
     
     macints      tmp1,  sw_val1,  sw_max1,  -1;
     skip      ccr,  ccr,  0x4,  2;
     macs      sw_fac1,  sw_down,  0,  0;
     macs      sw_fac2,  sw_down,  0,  0;  
     
     macints      tmp1,  sw_min1,  sw_val1,  -1;
     skip      ccr,  ccr,  0x4,  2;
     macs      sw_fac1,  sw_up,  0,  0;
     macs      sw_fac2,  sw_up,  0,  0;

Full code:

Code:

    input in_left, in_right;
    output out_left, out_right;
    static dry=0.4, wet=0.6, feedback=0.6;
    static xfeed=0x0, xl1=0x0, xl2=0x0;
    static xl3=0x0, xl4=0x0, xl5=0x0;
    static xl6=0x0, xr1=0x0, xr2=0x0;
    static xr3=0x0, xr4=0x0, xr5=0x0;
    static xr6=0x0, yl1=0x0, yl2=0x0;
    static yl3=0x0, yl4=0x0, yl5=0x0;
    static yl6=0x0, yr1=0x0, yr2=0x0;
    static yr3=0x0, yr4=0x0, yr5=0x0;
    static yr6=0x0, sw_val1=0x94c92c0, sw_val2=0x4c899e8;
    static sw_up=0x10000c1d, sw_down=0xffff3e3, sw_min1=0x4a64960;
    static sw_max1=0x12992581, sw_min2=0x2644cf4, sw_max2=0x99133cf;
    static sw_fac1=0x10000c1d, sw_fac2=0x10000c1d;
    temp tmp1, tmp2;


     macs      out_left,  in_left,  0,  0;
     macs      out_right,  in_right,  0,  0;     
     
     macs      sw_val1,  0,  sw_val1,  0.125;
     
     macints      tmp1,  0.125,  sw_val1,  -1;
     macints      tmp2,  0.125,  sw_val1,  1;
     log      tmp1,  tmp1,  0x1f,  0x1;
     log      tmp2,  tmp2,  0x1f,  0x1;
     macints      tmp2,  tmp2,  0x80000000,  0x1;
     macints      tmp1,  tmp1,  tmp2,  -1;
     exp      tmp1,  tmp1,  0x1f,  0x1;    
     
     macs      tmp2,  out_left,  feedback,  yl6;
     
     macs      0,  0,  xl1,  -1;
     macmv      xl1,  tmp2,  yl1,  tmp1;
     macs      yl1,  accum,  tmp2,  tmp1;       
     macs      0,  0,  xl2,  -1;
     macmv      xl2,  yl1,  yl2,  tmp1;
     macs      yl2,  accum,  yl1,  tmp1;
     macs      0,  0,  xl3,  -1;
     macmv      xl3,  yl2,  yl3,  tmp1;
     macs      yl3,  accum,  yl2,  tmp1;
     macs      0,  0,  xl4,  -1;
     macmv      xl4,  yl3,  yl4,  tmp1;
     macs      yl4,  accum,  yl3,  tmp1;
     macs      0,  0,  xl5,  -1;
     macmv      xl5,  yl4,  yl5,  tmp1;
     macs      yl5,  accum,  yl4,  tmp1;
     macs      0,  0,  xl6,  -1;
     macmv      xl6,  yl5,  yl6,  tmp1;
     macs      yl6,  accum,  yl5,  tmp1;
     
     macs      sw_val2,  0,  sw_val2,  0.125;

     macints      tmp1,  0.125,  sw_val2,  -1;
     macints      tmp2,  0.125,  sw_val2,  1;
     log      tmp1,  tmp1,  0x1f,  0x1;
     log      tmp2,  tmp2,  0x1f,  0x1;
     macints      tmp2,  tmp2,  0x80000000,  0x1;
     macints      tmp1,  tmp1,  tmp2,  -1;
     exp      tmp1,  tmp1,  0x1f,  0x1;   
     
     macs      tmp2,  out_right,  feedback,  yr6;
     
     macs      0,  0,  xr1,  -1;
     macmv      xr1,  tmp2,  yr1,  tmp1;
     macs      yr1,  accum,  tmp2,  tmp1;
     macs      0,  0,  xr2,  -1;
     macmv      xr2,  yr1,  yr2,  tmp1;
     macs      yr2,  accum,  yr1,  tmp1;
     macs      0,  0,  xr3,  -1;
     macmv      xr3,  yr2,  yr3,  tmp1;
     macs      yr3,  accum,  yr2,  tmp1;
     macs      0,  0,  xr4,  -1;
     macmv      xr4,  yr3,  yr4,  tmp1;
     macs      yr4,  accum,  yr3,  tmp1;
     macs      0,  0,  xr5,  -1;
     macmv      xr5,  yr4,  yr5,  tmp1;
     macs      yr5,  accum,  yr4,  tmp1;
     macs      0,  0,  xr6,  -1;
     macmv      xr6,  yr5,  yr6,  tmp1;
     macs      yr6,  accum,  yr5,  tmp1;    
     
     macs      out_left,  0,  out_left,  dry;
     interp      tmp1,  yl6,  xfeed,  yr6;
     macs      out_left,  out_left,  tmp1,  wet;
     
     macs      out_right,  0,  out_right,  dry;
     interp      tmp1,  yr6,  xfeed,  yl6;
     macs      out_right,  out_right,  tmp1,  wet;
     
     macints      sw_val1,  0,  sw_val1,  8;
     macs      sw_val1,  0,  sw_val1,  sw_fac1;
     macints      sw_val1,  0,  sw_val1,  8;
     
     macints      sw_val2,  0,  sw_val2,  8;
     macs      sw_val2,  0,  sw_val2,  sw_fac2;
     macints      sw_val2,  0,  sw_val2,  8;
     
     macints      tmp1,  sw_val1,  sw_max1,  -1;
     skip      ccr,  ccr,  0x4,  2;
     macs      sw_fac1,  sw_down,  0,  0;
     macs      sw_fac2,  sw_down,  0,  0; 
     
     macints      tmp1,  sw_min1,  sw_val1,  -1;
     skip      ccr,  ccr,  0x4,  2;
     macs      sw_fac1,  sw_up,  0,  0;
     macs      sw_fac2,  sw_up,  0,  0;

BTW: The "writing to 0" issue does not seem to be the problem here (I tested with and without that).

<edit>
'sw_min2' and 'sw_max2' are not used in the above code (they are left over from the other version (I forgot to remove them), where they are used to reset the 'sw_val' registers at the top and bottom of the sweep (as well as for the 'sweep opposite directions' option)).
</edit>

Russ · Mar 4, 2007, 08:47 AM

Quote:

Originally Posted by Maddogg6

Well - I can only confirm this behavior on my card as well..

Thanks for testing

For clarification, was that with your A2 card?

Maddogg6 · Mar 4, 2007, 10:32 PM

Oh - sorry I missed this post..

I only tested with my A2 Card... figured if I got the same thing on a different card - its not card specific or your computer...so i didnt bother. And Ive replaced it with your new one - so...

BUT...- I did notice something - probably nothing.. but - its a difference.
In the EQ Bandpass I see this:

Quote:

int iEQ_BandpassPlugin::set_defaults()
{
set_all_params(EQ_Bandpass_default_params);
return 0;
}

But in your source you posted for Phaser V3 - I see this:

Quote:

int iPhaserPlugin::set_defaults()
{
memcpy(_params, &default_params, sizeof default_params);
set_all_params(default_params);
return 0;
}

1) Im curious why the memcpy is used
2) is that function causing a problem for you.. ??

But - knowing me - it prolly has nothing to do with anything... and for that I'll apologize in advance.

Russ · Mar 5, 2007, 07:53 AM

Quote:

Originally Posted by Maddogg6

1) Im curious why the memcpy is used

The unmodified set_defaults function sets the parameters one at a time to the default values. This is ok if none of the parameters use another parameter for it's calculation, but if they do, when the first (common) parameter is set, the second one (all of the rest) is uninitialized (the very first time set_defaults is called) or invalid. The memcpy is used to intialize the full _params array to the default values, before setting defaults.

BTW: I also modifed the set_all_params function for similair reasons, which probably makes the memcpy unnecessary, but it doesn't hurt to leave it in (although I probably will remove it at some point).

These modifications were not absolutely necessary with the phaser plugin, as the problem was self correcting, but the newer code is better (and more efficient).

In any case, since the problem happens with the Dane only code, it seems that the C++ code is not the cause (and from your testing with the A2, I know it is not some '10k1 only' issue).

Russ · Mar 5, 2007, 11:07 AM

Another couple of things to note about this issue:

Load the (Dane only version) plugin.
Use kX Console to read the current value of the 2 registers (note that they show a value of zero).
Try a "Reset Settings" for the plugin and re-check those registers (note that they still read zero).
Use kX Console (-sg command) to write the same default values to those registers, and then recheck their values (note that the code now works as expected).
Try a "Reset Settings" for the plugin and re-check the values of those registers (note that it still works as expected (i.e. they are not zero)).

From the above:
"Reset Settings" for a Dane only plugin, does not seem to reset the static GPR's to their default values (although I am not sure if it is supposed to).

More importantly, writing the same default values to those 2 registers using kX Console, results in the code working as it should (same as setting defaults with the .kxl version), while it does not work as it should, right after loading (or updating microcode). This would seem to indicate that the problem is somewhere in the loader (and as such, there is no way I would be able to determine the specific cause myself).

-Russ

<edit>
One more thing to note (from my previous testing (with the .kxl version)) is that whatever is causing this problem, is happening AFTER the plugin's initial set_defaults code is executed (as I did verify that set_defaults was called during the loading process, and that it was using the correct values), otherwise the .kxl version would not have this problem (the initial set_defaults would have corrected it).
</edit>