Blue Cat Audio

ilyaorlov · Post by **ilyaorlov** » Fri Dec 06, 2019 11:12 am

Here's a working example 2:

Let's add a script to the same file.

<SKIN>

	<TEMPLATE id="TEST">
		<LOCAL_VARIABLE id="MYVAR" script="array&lt;string> ar = {&quot;0&quot;}; return ar[0];" />
		<TEXT value="$MYVAR$" />
	</TEMPLATE>

	<TEST />

	<SCRIPT script="int d=1;" />

</SKIN>

All works. Now let's make an error in the script, say change "int d=1" to "intt d=1". Reload. We get error in the script. Change back to "int d=1", reload, the DAW crashes.

ilyaorlov · Post by **ilyaorlov** » Fri Dec 06, 2019 11:15 am

If we rewrite the second example this way

Code: Select all

<LOCAL_VARIABLE id="MYVAR" value="44" />

There's no such behaviour. So I assume scripts in VARIABLES are powerful but vulnerable yet.

Blue Cat Audio · Post by **Blue Cat Audio** » Fri Dec 06, 2019 2:29 pm

Isn't there yet another popup in the background that you may have missed? This may happen sometimes, and if you manually reload the skin by another measn it will indeed crash. If not then there might be some cleanup missing when an error happens while building compile time scripts. It's a new (not much tested) feature

ilyaorlov · Post by **ilyaorlov** » Fri Dec 06, 2019 3:32 pm

Yea, I know about unclosed popups, but this time I don't see any!
Hopefully it'll be working fine someday, yet I have to avoid using it!

Blue Cat Audio · Post by **Blue Cat Audio** » Sat Dec 07, 2019 3:16 pm

Ok understood! Thanks for clarifying. There is probably a bug cleaning up dead compile-time scripts. I think this was indeed not deeply tested.

Blue Cat Audio · Post by **Blue Cat Audio** » Fri Dec 20, 2019 1:49 pm

ilyaorlov wrote: ↑Fri Dec 06, 2019 3:32 pm Yea, I know about unclosed popups, but this time I don't see any!
Hopefully it'll be working fine someday, yet I have to avoid using it!

Found the issue! It was a tricky one, as it requires several skins to be active at the same time (using KUIML widgets). It's a bug in the script engine and there is now a fix for it

.

It will be fixed with the next update (probably after the holidays). In the meantime script variables will indeed cause crashes (even when valid) when called from a KUIML widget hosted inside a skin that already uses scripts.

ilyaorlov · Post by **ilyaorlov** » Fri Dec 20, 2019 2:36 pm

Yooohoooo! Great to know!

ilyaorlov · Post by **ilyaorlov** » Fri Dec 20, 2019 2:48 pm

BTW I've got a wishlist for the next update

) Maybe some are not too complicated to implement.

1) (bugfix?) <EXPOSED_OBJECTS object_ids="*" /> in .kuiml causes error <"gui.BeginCapture" this object identifier already exists>
2) enhance mouse handling (just adding ".pushed" attribute to XY_PARAM_PAD and
XY_ZOOM_SELECT_PAD will help a lot with detecting mouse click position)

more complicated stuff:
3) KUIML action for (s)http POST requests (get server response into a KUIML string) - will let users do authorization/update checks/script exchange etc.
4) A buffer shared between all instances (even a simple shared string of say 2048-65536 bytes) would give huge possibilities.
5) Get track name from DAW (if available)

(maybe)
6) add attribute "use_empty_1x1_png"

for IMAGE_PARAM_... elements, so we don't have to use external empty.png

(not so important)
7) add message_string_id, title_string_id to DisplayMessageBox action (to be able to generate popup messages on the fly)
8 ) when exporting remember outputRefreshRate value set in current global settings.
9) way to calculate text length in Kt::Graphics (to be able to center/right_align text)

autumnmotor · Post by **autumnmotor** » Sun Dec 22, 2019 8:58 pm

Hi. I have an request.
Will processing like FFT (IFFT) and Biquad filter be implemented as API in the future?
Right now I have implemented these in Angelscript, but as you know it is very slow.
In digital signal processing, FFT and Biquad are frequent processes, so I would be grateful if they could be embedded as an API.

Thanks for reading my poor English!

ilyaorlov · Post by **ilyaorlov** » Tue Dec 24, 2019 3:36 pm

autumnmotor wrote: ↑Sun Dec 22, 2019 8:58 pm Will processing like FFT (IFFT) and Biquad filter be implemented as API in the future?
Right now I have implemented these in Angelscript, but as you know it is very slow.
In digital signal processing, FFT and Biquad are frequent processes, so I would be grateful if they could be embedded as an API.

Yes, it would be very cool, I was thinking about the same. Though there are so many CPU heavy tasks like that, i guess. BTW there are several algorithms to do FFT, some are slower, some are faster. Which one have you implemented? Have you tried to do the same in C++?

ilyaorlov · Post by **ilyaorlov** » Tue Dec 24, 2019 3:45 pm

I have additional request about error handling in KUIML.
1) It would be very handy to show a piece of code where the error was found, not only line/char no. Filename/line_no are sometimes not helpful, because content is generated on the fly with TEMPLATES for example, with REPEAT, with SCRIPT inside KUIML_WIDGET etc and line_no is irrelevant. So showing a piece of code causing an error would let us find the error much faster.

2) There's a "show_warnings" attribute in the SKIN, but I can't understand if it works. For example I often have Warnings when converting/truncating double to int. But I see these Warnings only if another Error happens, stopping the SKIN from working. I would like to see the Warnings all the time when in development mode, or to supress fully, when in production mode. Can I and how to?

3) It would be great to be able to save errors to log. An option for the SKIN like `log_errors_to_file="c:/pnserrors.txt"` would be great to save warnings and errors for future analysis.

If the KUIML error handling improve some day it would be very nice!

Blue Cat Audio · Post by **Blue Cat Audio** » Sat Dec 28, 2019 9:34 am

autumnmotor wrote: ↑Sun Dec 22, 2019 8:58 pm Hi. I have an request.
Will processing like FFT (IFFT) and Biquad filter be implemented as API in the future?
Right now I have implemented these in Angelscript, but as you know it is very slow.
In digital signal processing, FFT and Biquad are frequent processes, so I would be grateful if they could be embedded as an API.

Thanks for reading my poor English!

Yes, it would indeed be nice to have a native DSP API of some sort... Still thinking about it

Blue Cat Audio · Post by **Blue Cat Audio** » Sat Dec 28, 2019 9:43 am

ilyaorlov wrote: ↑Fri Dec 20, 2019 2:48 pm BTW I've got a wishlist for the next update ) Maybe some are not too complicated to implement.

There are already a couple of these in our list

.

1) It indeed looks like a bug.
2) It's indeed in the list - together with a better way to create custom widgets (still work in progress regarding design, as there are many ways tp doing it)
3) A http(s) client is indeed something I'd like to add in the future. Either as an action or a different object with an asynchronous callback. Probably similar to what you can find in javascript. There are however security issues that have to be considered first

.
4) A buffer shared between all instances: what do you mean? Between all DSP script instances, or in the KUIML GUI?
5) Get track name from DAW: I think it only exists for a few hosts/plug-in formats. It may be added in the future if available.
6) add attribute "use_empty_1x1_png" : what do you want to use it for?

7) It's indeed in the list. The current (ugly) way of doing it is to generate content on the fly for a KUIML widget holding the message box.
8 ) when exporting remember outputRefreshRate value set in current global settings: good point!
9) way to calculate text length in Kt::Graphics (to be able to center/right_align text): it's in the list - Graphics object API is still experimental at this point, so a few things are missing.

(MORE) Regarding error reporting, there are indeed a couple of things to improve. Template source code matching is definitely not an easy one, but it would help deciphering some cryptic errors

.

Warnings are enabled by default, so the option is just here to disable them if you cannot fix the warning and still want to use the skin in production.

ilyaorlov · Post by **ilyaorlov** » Sun Dec 29, 2019 11:36 am

Hello! Thanks a lot for detailed answers, as always!
4) A buffer shared between all instances: I don't know how to do that properly, but either a string shared between all DSP (preferred), or between all GUIs (or both, which would be cool).
I imagine a lot of plugins that would benefit of that intercommunication. Some measurement tools. etc.

6) add attribute "use_empty_1x1_png"

for IMAGE_PARAM_...
Take a look at the screenshot - it's entirely generated in KUIML, and the knobs use invisible IMAGE_PARAM_KNOBS for behaviour. For "invisibility" I use external "empty.png" 1x1px and then image_scaling to make invisible knob of desired size. If there's no need for real "empty.png" keeping all other behaviour the same, it would be nice for my case. Though not a serious trouble.

(NEW) Another cool thing would be an action to "reload" skin. Now I'm using changing "gui.zoom" back and forth which makes the skin reload twice. It would be nice to have a dedicated action for that skin reloading (for development purposes mostly).

ilyaorlov · Post by **ilyaorlov** » Mon Jan 06, 2020 12:18 pm

Ah! Another forgotten thing.

For INVISIBLE_PARAM_MENU_BUTTON it would be very nice to make attribute like [ mouse_scroll="reverse" ] for that behaviour. Because when we're having a list of params, we scroll up one line and the list goes down one line (with numeric values it's ok, but for listed values it's unintuitive). If we just use "reverse" attribute the mouse scrolling is ok, but the list goes reverse too

Blue Cat Audio

KVR Audio

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