Tril

I'm thinking of making a plugin that creates data and stores it in GPRs. It would be some kind of adaptive FIR filter.

The first time I run it, it would find the coefficients it needs by itself. I would like the plugin to save the coefficients to a file so that everytime I reboot the computer, I don't need to find the coefficients again. It would also enable me to switch between different setups.

Plugins only store user controls in preset so I can't use a preset to store the values of the registers.

I was thinking of adding a save and a load buttons and an auto-load to my plugin(plugin coded in C++). I don't have any knowlodge on what can be used for that. I suppose functions and classes that do that already exist and can be easily downloaded and implemented.

Could someone direct me to where (websites, etc.) I could search for such things or give me good advices. Thank you in advance.

Tril

Max M.

Make a C++ based plug-in. Make number of its "parameters" >= number of gprs you need to store.

>Plugins only store user controls in preset

They store "parameters" - not "user controls"

small hint:

Tril

Thank you. I'll look into this.

What does ndx stand for? I suppose they are not three random letters.

Are you talking about this :
#define DEMO_PARAMS_COUNT 4 // number of user-visible parameters

Until now, I've always seen get_dsp_register used in this way.
"gainCLIP" is the register name from the da file. I suppose it's associated with the register address on the sound card.
&clip is the address of a C++ variable.

I don't understand this. Sorry. Can you give some explanations on what this does. I think ndx contains a number that is an ID but I don't know how it changes. You seem to be using ID numbers for the registers to store in memory. I don't quite yet understand how kxparam_t usage works.

Do you use something like that to assign ID to registers with numbers instead of VOL1_P, VOL2_P?



I think I'm beginning to understand.

Russ

#define just gives a meaningful name to a constant, so you can just remember the name instead of the value, etc (and it you ever need to change the value, you can do it in one place, instead of having to do it everywhere it is used in your code).

If you look at a .cpp version of a .da (da_myplugin.cpp) file you will see stuff like:
So, instead of having to remember 0x8002, etc for the above 3 gpr's, you can use a #define statement to assigns a meaningful name (to use in your C++ code, i.e. get_param, etc).
i.e.
#define COEF1 [color=Red]0x8002[/color]
#define COEF2 [color=Red]0x8003[/color]
#define VOLCTRL [color=Red]0x8004[/color]

#define MYPLUGIN_PARAMS_COUNT 3
This basically defines the size of the array used to store your parameters.
[color=Red] ndx[/color] (used in get_param, etc) is the i[color=Red]nd[/color]e[color=Red]x[/color] into that array. get_param, steps through that array retrieving each element of the array (i.e. in get_all_params) one at a time. So you could either use, switch-case statements to check which parameter it is looking for (based on the value of ndx) and create a case for each gpr (i.e. using get_dsp_register(COEF1, &value)), or you can create one statement that works for all your gpr's, as in the example by Max M:
get_dsp_register(_id_of_the_first_state_gpr + ndx, value)
i.e.
get_dsp_register(COEF1 + ndx, &value)
COEF1 is the ID of the first gpr we are interested in, so COEF1 + ndx (0) = COEF1, so when ndx is 0, it gets the value for COEF1, then when ndx is 1, COEF1 + 1 = COEF2 (0x8002 + 1 = 0x8003), so when ndx = 1, it retrieves the value for COEF2, etc. You would just need to make sure that the gpr's you are interested in, are sequential in your .da file (and thus in the .cpp version of your .da (your da_myplugin.cpp file) file).

<edit>

Addtional info:
See set_all_params for an example of how that value changes (get_all_params code would be similair, or you could add your own function to retrieve individual values (pass in the index of the value that you want) or a subset of all the values, etc.

C++ array indices start at 0, so looking at the above code, you can see that it uses a loop to call set_param, once for each parameter (passing 0 the first time) up to MYPLUGIN_PARAMS_COUNT - 1 (while i < MYPLUGIN_PARAMS_COUNT), thus changing the value for ndx each time set_param is called.

Hope this helps...
Russ

Tril

Thank you Russ and Max M. Good explanation. It will help.

I think I understand now. You put the GPRs (or other info) values in the array using value with an index by calling get_param or get_all_params. When you save a preset, what is in that array gets saved.

I usually find it harder to understand code written by others than code written by myself (especially if they are better programmers than me ).

Russ

I think you've got it, you just made a small typo, "using get_param or get_all_params" should be "using set_param or set_all_params".

static int default_params[MYPLUGIN_PARAMS_COUNT] = {0, 10, 8, 4}; // 4 params
The above statement creates the default settings array and puts the initial values into it.

i.e.
default_params[0] = 0;
default_params[1] = 10;
default_params[2] = 8;
default_params[3] = 4;

The set_defaults function then places the above default values into the _params[MYPLUGIN_PARAMS_COUNT] array (using set_all_params).

The set_param/set_all_params functions modify those array elements at runtime.
i.e.
set_param(1, value);
Would change the value of _params[1]

You would use get_param or get_all_params to retrieve these values (i.e. to save them as a preset).

Russ

BTW: You situation is slighty more complicated because you are not actually adding the coefficient values to the array, you are just retrieving the values from microcode when get_param is called. Normally the parameters represent values that change when a control is adjusted (or a timer fires, etc), and thus get added to the array using set_param, etc, in the part of the code that handles your controls. As your values are coefficients that adjust themselves, they will not automatically be added to the array (i.e. you have no event to signal the code to add those values to the array), so you have to modify the get_param code to account for these parameters (using get_dsp_register instead of the code from the demo, so that instead of returning the value from the array, it just returns the value of the register itself). I am not sure if the save_preset function uses get_all_params to retrieve the values (in which case it should work and your values will be saved), or if it just uses the _param array in its current state to save the presets (in which case your values will not get saved because the values where never actaully stored in the array).

Tril

Thank you for explaining the set and get. It was not a typo. I was thinking the opposite of what it is. It's about point of view.

You get the values from a register and you set them to the param array.

I've searched through the files of the SDK and the only place save_preset is mentionned is in kxplugin.h. Why? Is it used in the driver in a file not available in the SDK that calls get_param?

You are a good teacher, Russ. Every time you post something about programming for the kX plugins, I learn something I did not know.

Russ

Set param sets the values (sets dsp registers and sets the values in the array), under normal circumstances. Get param normally only returns the value from the array. Neither one actually gets the values from the registers under normal circumstances (as usually this is unnecessary).

I just took another look at the save_preset function and realized that it is not a virtual function, so it is not going to work the way I was thinking (sorry for the confusion I only took a quick look at it previously). It can be used to save a preset, but it is not a function you can use to modify the save_preset behavior unfortunatley. I will take a look and see if I can find another way of accomplishing what I was thinking.

Russ

First I would check and see if get_all_params is used when you save a preset (see if your values are all saved), to determine if you need to do anything special to save those values.

If the values are not saved, one possibility is to use on_command to catch the click of the preset button and save your values then.
It is not the best way, but it should work.

i.e.
add the following to the Plugin GUI definition in myplugin.h
and then add its implementation in myplugin.cpp:
That should add your values to the _params array whenever the preset button is clicked if necessary (when you are going to save a preset, but also when you choose a preset, etc).

Maybe one of the other guys knows a better method to do what you want.

Tril

Arggh. I lost a post. I clicked on backspace outside of the window and it rewinded to the last page.

I did some tests with debug and DebugView.

When clicking on a preset, set_all_params gets called first, then get_param gets called multiples times.

When saving a preset, only get_params gets called (multiples times).

So, If I put the code to get the registers and save them in params array in the function set_all_params, the values of the registers will only be saved when changing profile. They won't be saved when saving a profile.

Russ, I may need to use you function to catch clicks and use it to call set_all_params the correct way.

How do I call it correctly?

Russ

When you save a preset it appears that get_all_params is used to retrieve the parameters before saving them. That is a good thing as it should make it easier. You should be able to just add the parameters just like you would with any other parameter, and should only need to modify the get_param code as previously suggested (i.e. you probably do not have to worry about adding it to the _params array when saving it, only when applying a preset).

Tril

Again, I was slightly confused. Thank you for clearing that up. That's true, if get_param gets called before saving and I modify get_param as Max suggested, I don't need to store the GRPs values in tha param array.

I'll only need to add code to get_param to enable saving of my registers.

I'll need to add code to set_all_params to enable saving of my registers before the presets switch.

I think that's all I need to do.

Russ

Some of the confusion comes from only being able to see the SDK headers (that are not fully documented), and thus having to figure out for yourself, what is done inside some of the functions. Normally you set your registers from the C++ code, so you have all the values on hand, and thus storing them in an array just keeps track of the current values for you, but it probably is not even needed at all. You could probably just track the values using your own methods and modify the code accordingly. Again, not knowing if the array is used somewhere in the hidden code (or if it was just used in the demo as an example of one way to do it) just confuses the issue, and sometimes the only way to find these things out is by trial and error.