kSettings usage?

Russ

Can someone confirm the usage of kSettings in the 3537 and 3538c SDK's?

I currently have 3538i installed and thus cannot test it without reinstalling the previous versions.

The only info I have regarding the registry key usage with kSettings is from an old post from Eugene (from kX 3535).

I would like to confirm that the above info is still accurate (particularly the " kSettings cfg(get_plugin()->ikx->get_device_name());" part) for the 3537 and 3538c SDK's, and also would like to know where is the best place to load and save the settings (strings) in 3537 and 3538c.

Thanks,
-Russ

Russ

Another thing I want to know is how it works with the previous kX versions.

i.e.
The previous kX version's do not have the save settings/load settings functions. This means that I have to save/load them myself in other kX functions (BTW: That is what I meant by, "where is the best place to save/load the settings"). I think this also means that if I unload the plugin, and reload it, and if I get the same pgm_id that I had previously, then it is going to load the strings when that was not was intended. Is this true?

Russ

Hmm, I just noticed that there is a iKXPluginManager::save_plugin_settings and a iKXPluginManager::load_plugin_settings function in the 3537 and 3538c SDK's. I will see if these are the same functions that are used by the plugin in 3538i.

Russ

Well, I tried using the same code that I used for 3538i to save the strings in the 3537/3538c versions and they compiled without errors. Now I will have to wait and see if they will work the same way as it does with 3538i (if those functions will be called upon loading/saving settings, etc).

Russ

OK, that did not seem to work, so I am still looking for the info I asked about.

Eugene Gavrilov

pre-3538x (as far as I remember) driver releases did not allow per-plugin settings to be saved / restored automatically without some hacks (say, adding custom event handlers -- event(IKX_LOAD / IKX_UNLOAD) etc...)


3538i:
there are two new 'virtual' functions added to iKXPlugin class (NOTE: NOT iKXPluginManager!), save_plugin_settings / restore_plugin_settings (read comments found in kxplugin.h)

// save/restore plugin settings
// note: all 'params' are already saved/restored
// use these functions for storing/restoring 'specific' parameters only, such as
// string values etc.
// save is called -after- and load is called -before- set/get_param(...)

note that you can still use events (IKX_SAVE_SETTINGS)

the order of calls is the following:
first, you get a notification IKX_SAVE_SETTINGS -- you can do whatever you like here
then, kx manager saves guid, name, window position etc.
(as well as microcode status)
kx manager obtains the number of parameters (get_param_count())
then for each param_t get_param() is executed and saved
then kx manager saves plugin connections
then it calls iKXPlugin::save_plugin_settings

you will need to obtain correct key, sprintf(section,"pgm_%d",pgm_id); to save / restore settings properly

note that since event is sent -before- get_param_count(), plugins with variable parameters should initialize correctly at that time

you can save/restore any data, not only numbers (review info.cpp for details)

for pre-3538i releases:
1. remove your custom save/load_plug_settings functions from your iKXPlugin-based class
2. add event handlers
(note: events IKX_SAVE_SETTINGS / RESTORE_SETTINGS are not sent to the plugin in pre-3538i releases! you will need to handle other events, such as LOAD/UNLOAD)

make sure you always compile with the correct SDK, since otherwise, even if compiled correctly, your plugin might not work!
---
concerning 'previous' settings
whenever new plugin is uploaded, it's 'set_defaults' function is called
after that, as a rule, the plugin will receive 'save_settings' event -before- any 'load_settings' event, thus, it is up to the plugin to override any existing settings

generic rule is to save/restore -all- the possible plugin parameters on each save/restore call

E.

Russ

Thanks for the info Eugene. I was aware of the new stuff in 3538i, I just wasn't sure about the previous versions. So, for pre-3538i versions, it is probabably best to only save settings (other than presets) that you want always applied, because there is no way to differentiate between loading and loading from a saved config.

Russ

A small issue regarding saving per-instance settings using kSettings. I noticed that the registry values that are created are never deleted. If a number of plugins start saving settings this way, then we could end up with a bunch of unneeded junk left over in the registry. As it stands now, we cannot delete these values ourselves when they are no longer needed, because there is no way for us to know whether the plugin is being unloaded do to the user unloading it (by choosing unload, or from loading a different config, in which case the registry values are no longer needed), or whether it is being unloaded due to kX mixer shutting down (in which case the settings should remain, so that they can be used when kX mixer is restarted), etc. I think it would be good if there were flags (or some other method) that we could check during IKX_UNLOAD, to determine why the plugin is being unloaded so we may do any necessary cleanup.

Alternatively (and maybe better), if kX did it automatically, then it would not be an issue. Aside from the settings that we are saving ourselves, the settings that kX saves automatically, also seem to remain in the registry when they are no longer needed. The alternative option would be for the per instance settings (the pgm# keys in the regsitry), to be completely cleared whenever a plugin is unloaded (due to any plugin unloading process other than kX Mixer shutting down). This would clean out the left over per-instance settings (connection info, etc), and would eliminate the need for plugin programmers to delete thier saved settings if they are doing it on a per instance basis (as kX would do it automatically).