Maddogg6

Ok - I was screwing around... and upon loading this plugin - kX Mixer crashed...
And would crash when I try restarting kX Mixer... so, to avoid re-installing everything kX... I tracked down the kxfxloudness.kxl file in windows system32... and renamed the plugin to get kX mixer to stop crashing - and it worked.

So, to retest this, I renamed he kxl file back (all I really did was add '.old' to the file name - so I would avoid making a mistake in renamimg it...

Restart kX Mixer - and it says - 'error - would you like to un-register this plugin' or to that affect... anyways... now I wonder if I hosed my kX installation.

Bottom line is I was hoping someone with 3545a could test that out for me and report back. I would just like to hear comfirmation that I hosed up my install be for I un-install / re-install everything (all them da plugins Ive collected)

Thanks in advance.

Russ

I doubt that you hosed anything...

There seems to be a problem with that plugin in 3545b too ((crashes if you try to restart kxmixer with it loaded)).

Double check the file name: kxfxloudness.kxl, or just unregister it (IIRC, even though kX asks if you want to unregister a plugin, it does not do so).

.reg file to unregister that plugin:

Maddogg6

thanks Russ... yeah I meant 3545b...

*be gone cursed plugin *

Russ

Hehe

You should probably let Eugene know (or maybe townkat) so that it can be fixed (or whatever).

Max M.

I've taken a look in its sources - it seems to crash with division by zero -
most likely when set_all_params(default_params) is called
(params[SETVOL_ID] is the one being ZERO (when it should not) and it is the last parameter being set to actual default value)

__________________

Russ

[COLOR=Gray](Out of curiosity)[/COLOR] Any idea why that would only happen when restarting kxmixer (i.e. it does not crash on me when loading the plugin or clicking the reset button)?

Max M.

I think it happens just randomly - when plugin is loaded the memory of the "params" array is not initialized - so params[SETVOL_ID] can or cannot be 0 by occasion.

__________________

Russ

Thanks for the explanation, I think I know what you mean. I did not see the sources anywhere, so I have not looked at them, but I have seen where this type of thing might occur in other plugins (when one parameter uses another parameter as part of it's calculations, before the other parameter has been initialized (maybe not same thing here, but same idea)).

Max M.

sources: KX Plugins

>when one parameter uses another parameter as part of it's calculations, before the other parameter has been initialized

In general - it's OK - (in context of "lazy" set_all_params() implemented like there) - as in the last iteration we get all the parameters initialized. But of course only if invalid parameter values (in earlier iterations) do not cause crash (like that div-by-zero)

__________________

Russ

Thanks for the link. Yup I see it... So the fix would be to memcpy the default_params into the _params array before set_all_params is callled within set_defaults (or probably better to copy the values in set_all_params)

Max M.

Yeah, i thought exactly of the same fix. Also after all - i would just put right at the beggining of the set_param() - to be sure that it never ever ever can be zero

edit: oops...

__________________

Russ

Yeah, that is a good idea...

Russ

I am not sure if townkat still comes around here, so I added the suggested code changes (set_all_params).
Here is the modified source (includes .kxl compiled for 3545b).

Maddogg6

awesome Russ... thank you...

Russ

<edit>
Nevermind, I decided to leave it with just the memcpy in set_all_params.

Max M.

[color=gray]mm, doesn't it have sync(ndx) after each set_param already?
(e.g. it is already synched after set_all_params w/o additional calls)[/color]

__________________

Lex Nahumury

I would simply use init() or even request_microcode()
for the _params array initialization?
Those are only called once and prior to all the set_param stuff.

Max M.

[color=gray]Well, if we are about "perfectization" i would rewrote the whole set_param there at all (first of all, i'd get off of copy-pastes and secondly removed division - to fix the problem itself and not fixing the symptoms )
And finally i'd renamed it from the "Timbre"! But who cares - whatever fix does the trick - who cares of how exactly. (IMHO) Too much attention to this one little plugin. [/color]

__________________

Lex Nahumury

True, but what else is there to talk about?

Max M.

catcha!

__________________

Russ

The problem was that parameters where being used before there values where valid (the divide by zero error was just a consequence of this). Initializing the whole array in set_all_params (for defaults and presets, etc) ensures that all the values are valid before they are used.

Well, if townkat does pop his head in here, I would like him to know the reason for the changes, etc.

BTW: I did rename most of the files, etc, as if Eugene ends up using this code, I didn't think leaving it called timbre would be good (but other than that, I did try to leave most of the code intact).

Lex Nahumury

LOL. Yes I understood that the first time.
Yes and I added that I would initialize that array in init() and *not* in set_all_params().

Russ

Sorry, you are not understanding what I mean.

When you set defaults or load a preset, you get a whole new set of values. set_all_params() calls set_param() for each parameter one at a time (as you know). The problem is that each parameter uses other parameters before their values would have been updated, thus they are using old (thus invalid) values (or in the case of the divide by zero error, uninitialized data) for their calculations, resulting in the calculations being invalid.

Lex Nahumury

Ah yes, I see now. (weird coding)
Sorry, I stand correct!

edit:
And thus Max was right afterall; best to re-write the content of set_param().