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

[ilyaorlov]

And a few fresh questions, please:

1) How to display multiline text?
Somewhy this example from the manual doesn't work

<TEXT multiline="true" width="100" font_face="Tahoma" value="This is a skin. Hello World!"
text_h_align="left" word_break="true" />

2) Can we somehow display arbitrary messagebox (with text generated in KUML script)? As It seems DisplayMessageBox can only display "fixed" strings?

--- and not so important, but still interested --

3) Can we modify FORMULA_CURVE.formula from KUIML Script?
The manual says formula is represented in a script as a simple function y(x). So I thought maybe we can take an arbitrary function "double y(double x)" and assign it to FORMULA_CURVE?

[Blue Cat Audio]

For (1) it should be marked as deprecated. It used to be available only on Windows, then we deprecated the feature (we'd like to add it back in the future). Maybe the doc has to be updated, I will double check.

For (2) it is not possible at this stage. We should indeed add an option to use STRING objects instead of static strings in the future. For some reason we have never had the need for it...

Regarding (3), you cannot modify a formula curve from a string at runtime, but this could be added in a future release. The problem is that you may have runtime issues if the syntax is incorrect. Using scripting to define more complex functions is in our plans, but it has its own problems too, as you cannot reference external variables inside the script that defines the function - Unless they are manually listed so that the compiler can generate smart proxies for them. So there is a bit of work here too

[ilyaorlov]

Yea, I understand! Thanks for answer, appreciate your work!

[ilyaorlov]

Added a few examples of FFT analyzer based on Plug-N-Script.

It's still not very optimised and linear (not log scale, as we're used to), but maybe a helpful piece of code for someone learning and moving on.

First version is very simple and uses available 32 outputs.

Second version uses more complex data sending from CXX to KUIML, so array of arbitrary size can be transmitted, and more that 32 bars we can have as output. It also lets click on frequency band to see it's values.

Added to examples:
https://github.com/ilyaorlovru/plug-n-script-examples

[ilyaorlov]

By the way, linear bar-based FFT seems to be convenient for examining and measuring harmonics.

[Blue Cat Audio]

Very nice!!

[ilyaorlov]

Thanks!

Please, some more questions & wishes:

DSP related:

1) Wish there was a way to communicate between DSP and KUIML independently of DAW/ASIO buffer size.

As I see now there are:
a) KUIML <SKIN refresh_priority="normal" refresh_time_ms="10" .. >
b) ASIO buffer size
c) "Global settings - Output data refresh rate"
and they all affect the rate at with input and output parameters are updated. Is it possible to eliminate (at least some of) these dependencies?

Will possible binary API be safe of that in some way?

2) When going native and including "windows.h" there's a conflict with "shutdown" function in "winsock.h". What's the proper way to fix that? (I know I can not include "winsock.h", but if I need it?

KUIML related:

1) What events exist? I know about "PARAM.value_changed" and "window.loaded.value_changed", maybe there are some more?

2) Is there a way to know if plugin window is open/active or not?

3) Is there an easy way to execute script when clicking on something? Something like <INVISIBLE_ACTION_BUTTON script=" ... " />

4) It would be cool to be able to create and use SVG images on the fly. Like maybe KUIML_WIDGET allowing to insert/refresh in-script-generated SVG images.

5) What is PROPERTY for? What is GROUP for? (not clear from manual how to use it and for what, so maybe a couple examples)

Thanks again!

[Blue Cat Audio]

Hi,

1) For DSP/GUI communication, it is important to understand that the DSP is only called everytime an audio buffer has to be processed. So outside of a few ms every buffer, the code has nothing to do. Also, the GUI polls the DSP data using a timer so that the audio processing thread is entirely free of any lock and does not have to wait for the GUI thread (which would cause audio dropouts). So the data computed by the dsp can only be made available to the GUI thread once a while. Why would you need more control over this communication channel once you can share larger binary data?

2) The signature of the shutdown function is different so it should be a problem. What kind of error message do you have?

KUIML 1: value_changed events are available on all objects (parameters, strings,...). You also have an event fired by the TIMER object. (btw window.loaded is a parameter - all parameters exposed by GUI objects also have their own value_changed event: myWidget.visible, myWidget.mouse_over etc.). KUIML is data model driven, so most events are mostly simple data model value change events.
KUIML 2: if the plug-in window is opened, the window.loaded parameter is true. When the window is closed the GUI is not active anyway so no code can be run in the GUI.
KUIML 3: You can indeed use the INVISIBLE_ACTION_BUTTON widget and point it to an ACTION of type "Script":

Code: Select all

<INVISIBLE_ACTION_BUTTON action_id="myScript"/>
<ACTION type="Script" script="DoSomething();"/>

KUIML 4: the <svg> tag is actually already supported (but not documented yet). It only supports simple core svg tags but it works pretty well. There is also a special widget (KUIML_WIDGET) which supports dynamically generated KUIML code, so you could indeed generate svg on the fly and load it there.
KUIML 5: Custom properties let you store any kind of data, but this is currently accessible only from C++ and it cannot be accessed by Plug'n Script. GROUPs are a simple way to create aggregates of objects. It is mainly used for persistency, copy/paste or drag and drop groups of elements.

[Blue Cat Audio]

By the way the KUIML documentation has been updated with a couple more details on recently added features.

[ilyaorlov]

Thanks a lot!

<svg> tag is incredibly useful! It's great to use when we need some background for example, and there is no simple "background_color" attribute on cells (btw, why?)

I'm making a simple skin using inline SVG and I like it a lot. Thought it would be cool to incapsulate all SVG graphics inside a skin, even knobs and meters, is this theoretically possible?

[ilyaorlov]

About "shutdown" function. When I include "windows.h", using MinGW64 GCC Compiler on Windows 7, I get this error:
============
error: conflicting declaration of C function 'void shutdown()'
DSP_EXPORT void shutdown(){
In file included from C:/Program Files/MinGW64/mingw64/x86_64-w64-mingw32/include/windows.h:92,
from C:\VST\PLUG-N-SCRIPT\C++ scripts\fft_analyzer\fft analyzer v3b.cc:8:
C:/Program Files/MinGW64/mingw64/x86_64-w64-mingw32/include/winsock.h:304:34: note: previous declaration 'int shutdown(SOCKET, int)'
WINSOCK_API_LINKAGE int WSAAPI shutdown(SOCKET s,int how);
=============

I fixed that using
#define WIN32_LEAN_AND_MEAN 1
though it's probably not the best way?

Ilya

[Blue Cat Audio]

Thanks a lot!
<svg> tag is incredibly useful! It's great to use when we need some background for example, and there is no simple "background_color" attribute on cells (btw, why?)

Cells are not visible (it's just layout structure). We could add a background color attribute to widgets though, but I am not sure it would make sense in all cases. Nice skin by the way!

I'm making a simple skin using inline SVG and I like it a lot. Thought it would be cool to incapsulate all SVG graphics inside a skin, even knobs and meters, is this theoretically possible?

It is currently not possible. I am not entirely sure about the performance if all graphics were included in the skin. But that's something (one more thing!) we'd like to investigate in the future!

[Blue Cat Audio]

About "shutdown" function. When I include "windows.h", using MinGW64 GCC Compiler on Windows 7, I get this error:
============
error: conflicting declaration of C function 'void shutdown()'
DSP_EXPORT void shutdown(){
In file included from C:/Program Files/MinGW64/mingw64/x86_64-w64-mingw32/include/windows.h:92,
from C:\VST\PLUG-N-SCRIPT\C++ scripts\fft_analyzer\fft analyzer v3b.cc:8:
C:/Program Files/MinGW64/mingw64/x86_64-w64-mingw32/include/winsock.h:304:34: note: previous declaration 'int shutdown(SOCKET, int)'
WINSOCK_API_LINKAGE int WSAAPI shutdown(SOCKET s,int how);
=============

I fixed that using
#define WIN32_LEAN_AND_MEAN 1
though it's probably not the best way?
Ilya

WIN32_LEAN_AND_MEAN is a good start whenever working on Windows (there are way too many #defines that screw up the build otherwise).
If you want to use sockets in a project, I think you can just abstract out the part of the code that uses it and use the win hearder that includes it in another cpp file and add it to the project.

[ilyaorlov]

Thank you for your reply!

(1) (Easy way to fill a background would be nice, thou, without layer_stack + svg "hack")

---------------------

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

[Blue Cat Audio]

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!