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

[ilyaorlov]

A few more

The idea is to make a skin that can be easily customized. All parts (toolbar, body and statusbar, settings window) can be easily removed from the main skin file, so that you can write your own.

Toolbar, body and statusbar can have custom gradients (or flat) background with various options, with edges, making it more "3d" or without. Meters are color and size-customizable, we can limit meters to some number of channels, or we can use single meter for all input/output channels.

Body size, padding, text size and colors are also customizable.
=============

Still some ideas to implement, still some missing features to do...

[Blue Cat Audio]

Very nice!!

[ilyaorlov]

1) Is there a built-in action to reload current skin? I'm using a trick to slightly reduce GUI size and set it back after reload, but maybe there's a proper (and faster) way?

Do you mean just a "reload" option, or a way to change the file path as well? There is currently no such action but it could be definitely added in a future update as the feature is available but not exposed.

2) Is there a way to call main skin Angelscript functions from KUIML_WIDGET scripts? Seems like it's getting it's own namespace and cannot access variables and functions from the main skin scripts. Or it can somehow? I did function call through Kt::Action link, but it cannot pass params.

KUIML widgets can access the data model from the main skin, but they have their own instance of the scripting engine, so scripts functions, classes and objects are entirely independent. So if you want to share data between the main skin and KUIML widgets, you have to do it thru KUIML data model objects (params, actions, strings etc.).

3) Seems like every new KUIML_WIDGET significantly affects SKIN loading time. Why is that and is there a way to make it faster? Right now I'm avoiding using too many KUIML_WIDGETS, though it's a nice way to make skin more dynamic.

It should not make it THAT slower... It takes a bit of time to generate the content and perform the layout but it is usually not noticeable...

Do you maybe have lots of defines and templates in the main skin? By default the KUIML widgets import all defines and templates that have been defined before the widget (so that it behaves like a dynamically loaded include file), and it can take time to load them if there are really many of them. If you move the declaration of variables, defines and templates after the KUIML_WIDGET, you can limit the number of things imported. It is also possible to disable this behavior with some undocumented flags on the KUIML_WIDGET element:

Code: Select all

import_templates="false" import_defines="false" import_variables="false"

Also, instead of using many widgets, maybe you can just use one of them and dynamically generate its content (it can be as complex as you wish), just like we did for the stock kuiml widget to host the parameters in the default Plug'n Script GUI.

Hope this helps!

[ilyaorlov]

Thank you!

Yes, I mean an action to reload main skin (after editing it).
It's clear, how KUIML_WIDGET works now, thanks! I'm trying to make a skin that uses KUIML_WIDGET while in editing mode (for changing backgrounds etc), and when exported it uses static content, so it loads really quick. (KUIML engine is really quick!!!)

1. I'm trying to implement different fonts, and found an issue I can't understand. When adding font_face to "TEXT" element, the size of the text gets smaller, even when font_face is empty (or "Arial" as it seems the default font, right?) Can you clear it up for me, please?

<TEXT value="Hello world" /> <!-- this looks normal -->
<TEXT value="Hello world" font_face="" /> <!-- this looks smaller -->
<TEXT value="Hello world" font_face="Arial" /> <!-- same as this -->
<TEXT value="Hello world" font_face="Verdana" /> <!-- this looks bigger -->

If I set font_face="Verdana" to SKIN it starts to work as expected, but what happens when there's no SKIN font_face set? What's the default font?

2. It would be nice if elements support both syntaxes:
< ... display="false" />
and < ... display="0" />
It would eliminate need for extra VARIABLE for converting 0 to false, and 1 to true.

3. There's also an unexpected(?) behaviour of <IF> and other templates based on <REPEAT> when using inside KUIML_WIDGET. To illustrate:

<TEMPLATE id="REPEAT3">
<REPEAT count="3">
<TEMPLATE_INNER_CONTENT />
</REPEAT>
</TEMPLATE>

Inside main SKIN:
<REPEAT3>
<TEXT value="x" />
</REPEAT3>
(x x x)

Inside KUIML_WIDGET:
<REPEAT3>
<TEXT value="y" />
</REPEAT3>
(y) - no matter of REPEAT counts (even if 0).

[ilyaorlov]

4. Here's a vector knobs demo made with CANVAS and an invisible IMAGE_PARAM_KNOB (for knob mouse behaviour) using "empty.png" 10x10px and image_scaling for various knob sizes. I wish there was no need in empty.png file! Could be great if we could use IMAGE_PARAM_KNOB and IMAGE_PARAM_SLIDER without external images!

5. How can we know, when mouse is clicked inside XY_PARAM_PAD? To know the click coordinates. Hope it had "pushed" attribute, but seems it doesn't. Maybe there's a way?

[Blue Cat Audio]

Yes, I mean an action to reload main skin (after editing it).

So I guess it is mainly for debug purposes, right?

If I set font_face="Verdana" to SKIN it starts to work as expected, but what happens when there's no SKIN font_face set? What's the default font?

The default font face is system-dependent. On Windows I guess it is the MS Dialog font. The idea is that by default it looks like a normal native dialog. So it is recommended to set the default font AND size (because system font size may be completely different).

2. It would be nice if elements support both syntaxes:
< ... display="false" />
and < ... display="0" />
It would eliminate need for extra VARIABLE for converting 0 to false, and 1 to true.

Yes, that's definitely something that should be done at some point!

3. There's also an unexpected(?) behaviour of <IF> and other templates based on <REPEAT> when using inside KUIML_WIDGET. To illustrate:
Inside KUIML_WIDGET:
<REPEAT3>
<TEXT value="y" />
</REPEAT3>
(y) - no matter of REPEAT counts (even if 0).
[/quote]
Yes, there is a bug that was indeed identified last week: The TEMPLATE_INNER_CONTENT tag is dropped when templates are imported in a KUIML_WIDGET. It has already been fixed and will be released in the next update.

[Blue Cat Audio]

4. Here's a vector knobs demo made with CANVAS and an invisible IMAGE_PARAM_KNOB (for knob mouse behaviour) using "empty.png" 10x10px and image_scaling for various knob sizes. I wish there was no need in empty.png file! Could be great if we could use IMAGE_PARAM_KNOB and IMAGE_PARAM_SLIDER without external images!

Nice one! I think maybe an INVISIBLE_PARAM_KNOB and slider would indeed be useful in this case.

5. How can we know, when mouse is clicked inside XY_PARAM_PAD? To know the click coordinates. Hope it had "pushed" attribute, but seems it doesn't. Maybe there's a way?

Right now there is no way to get the mouse coordinates from KUIML code. I am currently looking at various ways to do it without affecting performance. There is quite a bit of design work to make it both clean and efficient! It would probably be additional attributes like widget.mouse.x,y attributes. However it raises many questions (such as the behavior when the mouse is outside a widget etc.)

[ilyaorlov]

Thanks for quick reply!

1.Yea, reloading skin is for debugging, thought it's not critical: the gui resize trick is working fine.

2. So, how to know the default font?
font_face="default" seems to set it to Arial in my case (Windows 7)

3. That's great!

4. Yea! I like it too! For those interested, here's a draft example:
https://github.com/ilyaorlovru/plug-n-s ... nvas_knobs

5. Seems like you're trying to make it right and thus a bit complicated? Maybe adding a ".pushed" attribute to XY_PARAM_PAD (like to other knobs and switches) is a quick way? It would allow us to easily know the relative mouse coordinates (by the way relative coordinates will stay the same way with zooming). And hopefully it can be implemented faster! )

[ilyaorlov]

By the way, I found a way to know current dir inside KUIML_WIDGET!

I load body content inside a script function, so I just add a couple VARs in the beginning before pasting it into innerKUIML. (kuiml_dir and filename are parsed from $script_gui_path$)

<VAR id='KUIML_DIR' value=\""+kuiml_dir+"\" />
<VAR id='KUIML_FILE' value=\""+kuiml_filename+"\" />

This way we can use relative dirs inside our .kuimls for using external/relative relative graphics.

Hopefully the skin will be ready for public some day )

[Blue Cat Audio]

That's indeed a way to do it. The problem is that Plug'n Script cannot be aware of it during compilation, so you will have to manually copy these files when building a plug-in. In the next version there will probably be a cleaner way to do this (using a subdirectory with the name of the script), so that assets are properly copied during the build phase.

[ilyaorlov]

That's a good idea!

I can't calm down with mouse click position Came up with a hybrid idea of XY_PARAM_PAD + INVISIBLE_PARAM_TOGGLE_SWITCH. Works 80% of time

[ilyaorlov]

It's possible to do with XY_ZOOM_SELECT_PAD tracking zoom changes! ))
And we can even track right click checking zoom level!

And combined with another PNS_JOYSTICK we can get both click and dragging operations.
The disadvantage is that event happens on mouse release, so it's not fully versatile (yet don't know how to track mouse down event), but still good for some purposes.

[puremusic]

Newbie to Plug'n'Script here. Looking at it to see if it could be made to do something for me.

I’d like to setup polyphony using one keyboard midi input, to two external mono sound module device midi outputs. By this having the first note sent the first device, the second to the second, back and forth.

If someday I get a third device, then I’d distribute the polyphony across three.

Is there a simple way to do this with Plug'n'Script? Thanks!

[ilyaorlov]

Newbie to Plug'n'Script here. Looking at it to see if it could be made to do something for me.

I’d like to setup polyphony using one keyboard midi input, to two external mono sound module device midi outputs. By this having the first note sent the first device, the second to the second, back and forth.

If someday I get a third device, then I’d distribute the polyphony across three.

Is there a simple way to do this with Plug'n'Script? Thanks!

Hey, Puremusic!

IMHO it depends mainly on how you setup/route your output devices. Plug-n-Script has one MIDI output, though MIDI has 16 channels, so you can split your notes into 16 channels and send MIDI-output of PnS to each instrument (if your DAW supports it). Then you setup your instruments so that they react only to one of MIDI channels. This is one way to do it, probably there are more!

[ilyaorlov]

Another small suggestion about KUIML:
1) add "separator" attribute to REPEAT, so that we could use index_list with not only ";" separator.
It could let us do something like REPEAT inside REPEAT to split string first by ";" and then split substrings again into smaller pieces.

2) add "ignore_missing" to LOAD_FONT like to INCLUDE (for skin flexibility when fonts files are suddenly missing/were deleted)

3) it would be nice if font_face="" would act like no font_face at all. Cause now we can either use font_face or use default font. But for custom skin where you can choose font_face it would be nice to be able to leave font_face blank and get the default font (seems like Segoe UI on Windows, but still not exactly).