How to add params conveniently

Download param.as and use it like that:

Short explanation

Using params library we can add params inside initialize function in a very compact and easy to read and maintain manner. 

The format for adding params is:

We can also use shortcuts IP, OP, IPS, OPS instead of long names inputParameters, outputParameters, inputStrings, outputStrings to make our code more compact.

Long explanation

The default way of adding input and output parameters in Plug'n Script is using arrays:

To access these parameters later we can write 

It would be easier to read and write code if we write names instead of indexes (0,1,2...). We can assign them to constants like this:

Or better use Enums, which will do the same, but are easier to setup and maintain (especially when you want to add, re-order or remove values).

Now we can access inputParameters like this:

Cool! If we have a simple script with a few params, we can use it like that.

Disadvantages of default method

However, using this array-based way of adding params has some disadvantages.

For example, this is a beginning of one of my first projects (tone-generator script) using less than 30 input params. The section of adding params takes >130 lines of code and is very hard to read and manage.

If there's a mistake somewhere (say, a missed comma), the script may even continue to work, but array values will be shifted, which is sometimes hard to notice.

So, wouldn't it be nice to make things clean and simple?

Let's use initialize

Inside initialize we can still add and update parameters. So let's write a function that will get a bunch of param attributes and put it into arrays, something like that:

We can also add another function with the same name but other parameters to add "enumerated" parameters.

Before using inputParameters arrays we have to create them globally. And there will be more functions to add output params and strings, so let's save it all into "params.as" file and include it on top of our script.

This is already very cool — light and easy to write and read.

Though using constants for index names might be slightly inconvenient, because:

1. Order of function calls in initialize may not match the order of params, which is visually not clear.
2. If you want to disable or remove params you have to update them both in enums list and in initialize, which is twice as much work.

So, let's improve it further: index of added param can be generated and returned from function, like this:

Now it's easy to re-order, remove or temporarily disable params. All param info is kept in a single line. Beautiful!

Here are examples on how to add output params, input and output strings. Also if you like to make things shorter, with this library included you can use aliases, like IP[GAIN] instead of inputParameters[GAIN].

What about the GUI?

We can make our life easier in the KUIML as well.

By default, when we add params in the Plug'n Script DSP they are exposed to the GUI with generic names like dsp.input8 (for exported plugin they start from dsp.input1), dsp.output0, etc. Generic params have generic ranges from 0 to 1. And inside skin they are mapped into custom_param0, custom_out_param0 with proper param names and ranges.

So when writing kuiml file for our script we usually use these aliased params, like this:

It would also be nice to use names instead of these numbered params.

We can do it so by keeping param names in KUIML VARIABLEs.

and later use it like that:

So, it's much more readable already!

Info: If you're wondering, what knobs are available in the skin, see this article.

But what if we reorder params in DSP? Do we have to rewrite every VARIABLE in KUIML?

We can get away from it by using the incremented variable index, like this:

Good, but let's make things more visually appealing. If you're not using Letimix Skin yet, first add this to your kuiml (in Letimix skin these elements are added already):

Now we can write it shorter:

Now if we re-order params in DSP we just move the line of code in KUIML and that's it! Beautiful!

For output params we can use the same principle, just use custom_out_param$N$ instead.

Input and output strings

Custom input strings are exposed as dsp.input_string1, dsp_input_string2, etc. (String number 0 is holding the path to current script). In the skin these string names are kept in VARIABLEs named script_input_string0, script_input_string1, etc.

Custom output strings are exposed as dsp.output_string360 and further, but when exported this name would change to something like dsp.output_stringX. Where X is 8 + ($PLUGIN_INPUT_PARAMS_COUNT$-1)*4 + $PLUGIN_OUTPUT_PARAMS_COUNT$*4 + 16 + 16 (if you wonder what it all means: the number of params  + 16 input string names, 16 output string names, then goes output string data that we need).

It makes using dsp.output_stringX more complicated. However, proper output string names are also kept in VARIABLEs like script_output_string0, script_output_string1, that we can safely use.

It's probably easier to keep things like that, however, if you really want to give your input and output string names, you can try the similar approach.

That's all for now. You can write your ideas on adding params in PnS in the comment below.