Back To School? Explore DSP & MIDI DIY with Blue Cat's Plug'n Script 3.2!

[ilyaorlov]

I've met a cruel bug that I'm suprised didn't show up earlier: exported VST3 plugins crash if script is using inputStrings.
It's both x64 and x86 (tested on Windows), both AngelScript and native, and seems like the previous (3.1) version was also affected.
It's only in VST3 (VST2 is fine) and only for inputStrings (outputStrings are fine).
Maybe it's only on my machine (Windows 7 64bit)? Could you please check it?

[ilyaorlov]

And a question I've been wondering for a long time.
Why in mappings.inc we have this:

Code: Select all

<PARAM_LINK from="$script_input$index$$" to="custom_param$index$" normalized="true" enabled="true" capture_enabled="false"/>
<PARAM_LINK from="custom_param$index$" to="$script_input$index$$" enabled="false" id="link$index$" normalized="true"/>
<PARAM_LINK from="custom_param$index$.capturing" to="link$index$.enabled"/>

Specifically:
1) what does capture_enabled="false" for PARAM_LINK means, and
2) why reverse link is enabled only when .capturing? It prevents us from modifying input params from script? What is the purpose?

[ilyaorlov]

I'm sorry for so many posts

Every time I export a plugin in PnS I then run PatchWork and open it to test what has been just exported. I wonder, can we make a button for that in KUIML? After building a plugin to click a button that runs an Action to open PatchWork standalone (32 ot 64 bit) and as a param use the path to the builded .dll or .vst3

The question is basically can PatchWork standalone open plugin (.dll or .vst3) via console param? smth like "
Blue Cat's PatchWork.exe -o c:/vst/my/plugin.dll"

It think you get the idea.

And I would appreciate a lot a bugfix for exported VST3/inputStrings thing. Yet it prevents releasing VST3 versions cause they crash. And inputStrings are a crucial part.

[ilyaorlov]

It would be also cool if we could access data model (model.*) directly from DSP API somehow. Though it's probably complicated.

[ilyaorlov]

I'm experimenting here with <WINDOW>, and I see they can be resizeable and we can track it's h_position and v_position. It's cool. Is it possible for the main plugin window also to be resizeable? And somehow to get top left position of it?

Also if we give SKIN an id, we can then read/write skin.width. Can we somehow access it without giving id to skin? (and thus changing data model) Maybe something like window.h_position, window.width etc?

And I can see we can make a new window full screen, it's really cool especcially for my metering plugins. Yet I cannot find a way to detect screen size to make window of that size.

[ilyaorlov]

Just to sum up everything above in short:

1) Waiting for the bugfix for exported VST3 - they crash if script has inputStrings.
2) Why don't we have direct back link from custom_paramM to dsp.inputM? Why only on capturing? What means capture_enabled="false" for PARAM_LINK?
3) (the answer is probably no) Can we run PatchWork standalone with command line params to open one exact plugin? Can we make a KUIML action to execute it?
4) Is there a way for DSP to access data model directly? (from model.model and shared.model)?
5) If we use WINDOW and want to make it fullscreen, how do we know screen resolution?
6) Is there a way to get main plugin window h_position, v_position (absolute coords)? So that we can open new windows relative to main window.
7) Can we make main window resizeable and content to take 100% of it (like we can with newly opened windows)?
Can we access SKIN attributes like ".width" without giving main skin an "id" (to prevent data model change)?
9) model.model can have a TIMER and ACTION_TRIGGER. Is it running in a different thread, as it's not a GUI and not a DSP?

[ilyaorlov]

10) It would be cool if we could run C++ functions from angelscript somehow. I understand this is OS dependent, but stil would open a lot of options. For example in AutoHotkey (which is also a scripted language), it's done like: DllCall("CreateNamedPipe","str", Name,"uint",OpenMode,"uint",PipeMode,"uint",MaxInstances,"uint",0,"uint",0,"uint",0,ptr,0,ptr)
11) Can KUIML CopyObject action copy string data to clipboard as plain text? To paste it anywhere else?

[Blue Cat Audio]

I've met a cruel bug that I'm suprised didn't show up earlier: exported VST3 plugins crash if script is using inputStrings.
It's both x64 and x86 (tested on Windows), both AngelScript and native, and seems like the previous (3.1) version was also affected.
It's only in VST3 (VST2 is fine) and only for inputStrings (outputStrings are fine).
Maybe it's only on my machine (Windows 7 64bit)? Could you please check it?

Will look into it shortly!

[Blue Cat Audio]

I'm sorry for so many posts

Every time I export a plugin in PnS I then run PatchWork and open it to test what has been just exported. I wonder, can we make a button for that in KUIML? After building a plugin to click a button that runs an Action to open PatchWork standalone (32 ot 64 bit) and as a param use the path to the builded .dll or .vst3

The question is basically can PatchWork standalone open plugin (.dll or .vst3) via console param? smth like "
Blue Cat's PatchWork.exe -o c:/vst/my/plugin.dll"

It think you get the idea.

And I would appreciate a lot a bugfix for exported VST3/inputStrings thing. Yet it prevents releasing VST3 versions cause they crash. And inputStrings are a crucial part.

Loading a single plug-in via command line doe snot make much sense because who knows where it should go, However PatchWork can load a preset via the commad line. So just create a preset with the plug-in and you can reload it like this:

Code: Select all

Blue Cat's PatchWork.exe "Path\to\your\preset\that contains\the plug-in.preset"

[Blue Cat Audio]

I'm experimenting here with <WINDOW>, and I see they can be resizeable and we can track it's h_position and v_position. It's cool. Is it possible for the main plugin window also to be resizeable? And somehow to get top left position of it?

Also if we give SKIN an id, we can then read/write skin.width. Can we somehow access it without giving id to skin? (and thus changing data model) Maybe something like window.h_position, window.width etc?

And I can see we can make a new window full screen, it's really cool especcially for my metering plugins. Yet I cannot find a way to detect screen size to make window of that size.

The window of the plug-in is actually owned by the host application, so it would be dangerous to override its properties to be notified of position changes etc. so it would be very tricky to expose it to the KUIML skin.

Regarding the dimensions of the main plug-in window, if the host supports dynamic resizing, you can simply change the size of the skin. I don't think window.width / height would work, as it would refer to the actual parent window (the one from the host). If we can come up with a better name, it would indeed be nice to have it exposed even when the skin has no id.

You can however overcome this issue by creating a root cell inside the skin with its own id. It would actually have the exact same size as the entire skin. And if you set its size, the skin would change its size too. I guess that's why the skin dimensions re not exposed yet.

5) If we use WINDOW and want to make it fullscreen, how do we know screen resolution?
7) Can we make main window resizeable and content to take 100% of it (like we can with newly opened windows)?

To make a window full screen, I guess it is a better idea not to set its size but use the maximization feature. But it is currently not available yet from code (only user-driven when they click on the maximize icon). It can be enabled using the enable_maximize="true" option, but it has not been extensively tested yet.

I am not sure I understand (7) though. What do you exactly mean? If it is resizable and the content inside is set to width="100%" and height="100%", I think it should take the entire area (that's the way it works for our tone maps window for example).

[Blue Cat Audio]

4) Is there a way for DSP to access data model directly? (from model.model and shared.model)?
9) model.model can have a TIMER and ACTION_TRIGGER. Is it running in a different thread, as it's not a GUI and not a DSP?

The models indeed live in their own thread, that is shared among plug-in instances (so that communication is entirely thread safe). The model cannot be access by the DSP directly, because it could cause priority inversions. The whole system is optimized to make sure that the DP never depends on other threads and potentially locking data model structures (which is the case for KUIML models). So the way to do it is to store your data/behavior in the high-level model and copy it to dsp data (defined by the DSP layer) when it should be passed to the DSP.

Hope this clarifies!

[Blue Cat Audio]

And a question I've been wondering for a long time.
Why in mappings.inc we have this:

Code: Select all

<PARAM_LINK from="$script_input$index$$" to="custom_param$index$" normalized="true" enabled="true" capture_enabled="false"/>
<PARAM_LINK from="custom_param$index$" to="$script_input$index$$" enabled="false" id="link$index$" normalized="true"/>
<PARAM_LINK from="custom_param$index$.capturing" to="link$index$.enabled"/>

Specifically:
1) what does capture_enabled="false" for PARAM_LINK means, and
2) why reverse link is enabled only when .capturing? It prevents us from modifying input params from script? What is the purpose?

Haha good question! It looks like you are now reaching the ugly implementations details of Plug'n Script .

Just to clarify a bit (and although you probably know that already), since Plug'n Script lets you define your parameters dynamically (range, names, number of parameters etc.), which is not supported by most plug-in formats/hosts, the parameters at the DSP/script level are all 0 to 1 values ("script_input" parameters), and the actual parameters that the user sees are defined in the skin ("custom_params"), based on the metadata exposed by the DSP when the script (or DSP dll) is loaded. When you export the plug-in, you have the option to actually make the DSP params exactly the same as the custom params (and you can get rid of them if you want - only in the exported plug-in) or still use the "generic parameters".

Since with have both sets of parameters, they have to be kept in sync. The problem is that if you link them both ways, you create a feedback loop, and when you load presets (which actually change the properties of the parameters such as the range...), you end up with random values because of the feedback loop between parameter that have changing ranges. So the custom parameters used for display and control in the GUI will modify the dsp parameters only when captured, which means only when the user touches a knob or enters a value. The dsp parameters are the reference (and they are persistent), the other ones are just for display and user input.

The "capture_enabled" parameter was actually developed specifically for this use case and is probably useless anywhere else. By default a link will forward the capture state (= user editing state) of the source parameter to the destination parameter. But if you do this in this particular case, there is one scenario where it does not work: when controlling the plug-in with MIDI, it starts/end capture on the DSP parameters (so that undo is properly managed as well as host automation even when using MIDI). if the GUI of PnS is opened and the capture state is forwarded to the GUI parameters, it also enables the reverse link (from the custom params to DSP params). So you get a feedback loop that screws up the parameter values (because MIDI and GUI operate in different threads in an asynchronous manner...).

That's typically the kind of implementation details you may want to avoid... So if you mainly use PnS to export plug-ins that are becoming rather complex, I think it is worth doing the DSP first in PnS with the generic GUI, and when it is working fine, export the plug-in and create the skin from scratch with pure KUIML. It avoids having to deal with dynamic parameters, and you can directly use the "regular" dsp.input parameters with appropriate ranges and properties...

[Blue Cat Audio]

And sorry again for the unusual delay. There was quite a bit to cover and I wanted to make sure i had enough time to do it properly

[ilyaorlov]

Thank you for exceptional explanations Now the mistery of reverse_link is unveiled!

I'll be trying out different ideas based on that all! Thanks again!

[ilyaorlov]

So here's a resizeable main window! I'm really glad it's possible with KUIML!
And experiments with multilined text widget.

All will be included in the next Letimix skin update.