Create VST, VST3 and Audio Units with Plug'n Script 3.1

[Blue Cat Audio]

I did some investigation to clear up how GUI <-> DSP communication works and wrote an article on that, hopefully someone fill find it useful. Would appreciate if you point out mistakes, if any!
https://docs.google.com/document/d/1iZ0 ... sp=sharing

Very nice! Will take some time to read it carefully later today!

[ilyaorlov]

What about adding a background color to the "WIDGET" generic widget? It would avoid the layer_stack which indeed gets a bit boring if it's only for rectangles!

I think the most intuitive (for users) would be adding background_color to CELLs, of course! But I understand now, that they are not visible, so logically WIDGET would be the right place!

[ilyaorlov]

Here's a debugging skin I'm working on. It can be used as a "helper" when writing KUIML for Plug-n-Script, you can easily see the params and actions and click-copy names.

Uploaded a first version here:
https://github.com/ilyaorlovru/plug-n-script_skins

Tested on Windows, PnS 3.1, works with exported plugins as well.

[ilyaorlov]

Decided to write my Plug-n-Script feature requests

DSP

1) A way to send more data to GUI (Output Strings, Binary/RAW, maybe a way to use private_output_params). (Very much awaited, would open a lot more possibilities for new scripts)

2) Maybe some encryption for exported scripts (not so important, but nice).

3) Get current track name in "transport" info (if possible)

4) (not very important) A way for plugins to interact with another (maybe send_messages or shared_memory between all instances).

5) (just maybe one day) Included in API simple FFT/iFFT, convolution functions.

KUIML

6) Write scripts inside <SCRIPT> without having to escape &quot; and &lt;
<SCRIPT requires="...">
void doSomething(){
string s="hello";
if (d < 230) {
...
}
}
</SCRIPT>

7) Way to use string comparison in formulas:
<IF condition="&quot;$_SYSTEM_TYPE_$&quot; = &quot;Mac&quot;">
</IF>

Way to check if VARIABLE is not defined.

9) Way to silently ignore INCLUDE if file not preset.

10) (Maybe) A way to know current dir when inside KUIML_WIDGET, like a special _KUIML_DIR_ variable, so we could add graphics relative to .kuiml file.

11) (Not important) Add message_string_id, title_string_id to DisplayMessageBox action.

12) (Maybe there is?) A simple element to show multilined text.

13) A way to handle mouse right click (for example to show my own pop-up menu on right click).

14) (Would be nice) A way to update POPUP_MENU on the fly (maybe just way to display/hide MENU_ITEM elements).

15) (Maybe there is?) A way to detect current mouse position over the widget. Maybe something like invisible PNS_JOYSTICK that sets params depending on where mouse is over now or where it just clicked (without need to drag something).

16) (Not so important) Way to check if CTRL/Alt/Shift is pressed when clicking.

GENERAL/EXPORT

17) If I export a new version of a plugin, what's the right place to put "VERSION" info?

18) (not so important) when exporting remember outputRefreshRate value set in current global settings.

BUGS?

19) <SCRIPT src=".." /> doesn't seem to work with absolute paths (always relative to skin)

MAPPINGS

20) make "dsp.sample_rate" not stripped in default "mappings.inc"

21) Somehow add "inputParametersSteps" info to actual custom_param, maybe like custom_param.meta.steps ? (BTW can we add ".meta" other then "meta.locked"?)

[Blue Cat Audio]

Here's a debugging skin I'm working on. It can be used as a "helper" when writing KUIML for Plug-n-Script, you can easily see the params and actions and click-copy names.

Uploaded a first version here:
https://github.com/ilyaorlovru/plug-n-script_skins

Tested on Windows, PnS 3.1, works with exported plugins as well.

Very nice! There is quite a bit of meta-programming in there, I love it!

[Blue Cat Audio]

Thanks for the requests! Many of them are already in the todo list. BTW the background_color attribute has just been added to the WIDGET element. Will try to do an update shortly .

(3) current track name is not available in many DAWs but we'll check this out.
(4) If you are using native DSP, the best way to do it is to load a shared library (dll) that contains static data. You would however have to handle locking etc.
(5) It would indeed be nice to include a library CPU-intensive tasks that would be implemented natively.
(6) Unfortunately this is not possible due to the Xml format. But there is a way to avoid escaping using CDATA. We'll try to support it in the future.
(7) It would indeed be very handy to support a couple of string functions in formulas. However it requires a fair amount of work - and as an alternative we would like to support scripts in VARIABLE definition (such as <VARIABLE script="print($_SYSTEM_TYPE_$=="Mac")"/>. What do you think?
(8) IF_DEFINED for variable: It has been in the air for a while but we are still thinking about it!
(9) Why would you want to silently ignore include failures?
(10) Yes, this one is annoying. However for Plug'n Script the issue is that you would have to manually add the included files after export.
(12) quality multiline text is a tricky thing, but that's in the long term plans for sure.
(13) There are a couple of things in work regarding mouse events (especially for right-click). Not sure how this will be implemented, though.
(14) This one is not easy, as it is not natively supported by operating systems (I am thinking about a simple visible attribute on a menu item), so it requires a fair amount of work.
(15) That's part of our reflection about mouse in general. Maybe it will be attributes available on a widget (something like my_widget.mouse_pos.x)
(16) Yes, this one is tricky too. Ideally it would be nice to be able to check the entire state of the keyboard within any GUI event / script. The problem is that operating systems behave quite differently in this regard - but we are working on it!
(17) I think versioning is currently not implemented for export.
(18) that's indeed a good idea.
(19) Thanks for reporting - this is indeed a bug - will be fixed shortly! (you may however not want to use absolute paths in general...)
(21) metadata support is a new thing - you cannot currently anything to it, but it will happen at some point in the future. Regarding steps / taper behavior, there might be something coming in the future.

[ilyaorlov]

Thanks for a quick reply!
(7) <VARIABLE script="print($_SYSTEM_TYPE_$=="Mac")"/> looks good for me!!
(9) Silent INCLUDES would be nice for a generic skin including a lot of graphics. For example after export you just delete the folders you don't need, and you get no error about that. Something like <INCLUDE_ONCE no_warning="true" file="MySkin/Knobs.inc" />

[Blue Cat Audio]

Our internal version now has an ignore_missing attribute for INCLUDE and INCLUDE_ONCE tags

[ilyaorlov]

That's great!
Maybe for (12) we could just use something like SYSTEM_TEXT, using default OS elements?

[ilyaorlov]

Probably a question for Angelscript, yet couldn't find an answer.
When writing GUI I sometimes have an element, and hide it:
log_area.display=0;
However, if I don't include this element, I get "No matching symbol 'log_area' ..." error.
Is there a way to check if "log_area" is defined/exists? To avoid getting this error?

[Blue Cat Audio]

No, this is not possible. That's the difference between a static compiled language and a dynamic language: errors are caught earlier (during compilation). If this was not the case, it would be very hard to avoid runtime issues in a large KUIML codebase.

[Blue Cat Audio]

That's great!
Maybe for (12) we could just use something like SYSTEM_TEXT, using default OS elements?

Unfortunately there are too many discrepancies between platforms, so it is not as simple as that

[ilyaorlov]

No, this is not possible. That's the difference between a static compiled language and a dynamic language: errors are caught earlier (during compilation). If this was not the case, it would be very hard to avoid runtime issues in a large KUIML codebase.

Yea, I also thought so. Though I could make it via param aliasing.

Code: Select all

// in script
Kt::Param@ a_log_invalidate;

Code: Select all

<PARAM id="log_invalidate" min="0" max="1000000" default="0" />
<ACTION_TRIGGER event_id="window.loaded.value_changed" condition_formula="window.loaded==1" script="@a_log_invalidate=log_invalidate" requires="log_invalidate"/>

And so changing "a_log_invalidate" in script (which always exists) makes this param change as well.

[ilyaorlov]

Here a preview of a customizeable skin for Plug-n-Script! Already can do some rather complex SVG-backgrounds!

[ilyaorlov]

A few questions on that!

1) Is there a way to set X/Y position of the opening WINDOW?

2) Would be cool to be able to overwrite TEMPLATES and DEFINES. For example I use some new elements defined in my skin, but I want the .kuimls also be working fine in original PnS Skin. So I'd like to put copies of these DEFINES/TEMPLATES in .kuiml without error that they're already defined.

3) I found CANVAS element and was very excited. Can I use it, is it ok? Would like to try to make meters with that.