Russ

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

System Specs

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

Russ

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

That's a bug I guess...

__________________
Miss you, Steve...

Russ

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

Russ

@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

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

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

Russ

@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

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

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

Lex Nahumury

ok. got me worried there for a moment lol

Russ

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

-Russ

Maddogg6

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

Russ

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.