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

[ilyaorlov]

[Blue Cat Audio]

1) I've noticed that in AngelScript we can access param.min and param.max values, but not param.default as "default" it is reserved word. Maybe there's another way?
2) Is there a way to detect which of plugin instances (if we have several plugin instances/windows open) is in focus (active, upfront)? One way to cheat is to detect mouse events over it's content or maybe there a better way?
Say we have a hardware controller controlling plugin instance that is currently in focus (though maybe manually pushing "active" button on a plugin is better way to do that).

As far as i remember the name translates to "defaultValue" in Angelscript because of this limitation.

I don't think there is an easy way to get the current active Window in the host application, so it is probably quite difficult to detect if the current plug-in is "active"

[ilyaorlov]

Yes, the .defaultValue works! Thank you for quick answers!

[ilyaorlov]

Another task I'm trying to solve is changing cursor when doing something with the widget, for example change cursor when it's is some areas of a canvas, or when doing custom drag/resize/editing operations etc.
I've tried "system" approach, but no luck yet

[Blue Cat Audio]

That's indeed in the plans to add an API for that in the future. You can achieve that already using overlayed widgets with different cursors, but adds a lot of complexity.

[ilyaorlov]

Ok, I managed to make it the hackers way (so the easy way would be great someday, anyway. Thanks!)

[ilyaorlov]

1) Maybe make a flag in the model to disable fades on bypass?

2) When opening popup_menus on mouse_down event mouse_down doesn't go back to 0 (probably cause widget loses focus). And if it was right click - cursor get's stuck and doesn't change until next right click up happens. I see the solution is to use mouse up event for triggering actions (that's what I do), but maybe it's not an expected behaviour?

3) What for is "_context" in attrributes? I don't get it right yet. Like "drag_context" or "persistence_context" or somewhere else I met it.

[ilyaorlov]

4) I've tracked the order of functions call in DSP, is this correct?

initialize
reset

[ main loop (some functions marked * may be called or not ]
updateInputParameters (*)
updateInputParametersForBlock (*)
computeOutputData (*)
getTailSize
getLatency
getTailSize
processBlock
[ end of main loop ]

shutdown

[ilyaorlov]

And when using processSample we get the same but instead of processBlock:
[processSample loop]
processSample
updateInputParameters (*)
[end of processSample loop]

[ilyaorlov]

5) (profiling dsp) It would be nice to include into AngelSctipt a getMicroseconds function (or like that) to be able to do some profiling more easily. Though it seems reading and writing to array takes so much time in AngelScript, it's difficult to make something with it, like a bottleneck to performance. But still profiling would be easier with that.

[Blue Cat Audio]

1) Maybe make a flag in the model to disable fades on bypass?

2) When opening popup_menus on mouse_down event mouse_down doesn't go back to 0 (probably cause widget loses focus). And if it was right click - cursor get's stuck and doesn't change until next right click up happens. I see the solution is to use mouse up event for triggering actions (that's what I do), but maybe it's not an expected behaviour?

3) What for is "_context" in attrributes? I don't get it right yet. Like "drag_context" or "persistence_context" or somewhere else I met it.

(1) I am not 100% sure about this one.
(2) That's probably a bug indeed. Mouse Capture changes is a tricky thing to handle. However the default behavior on all platforms (Mac or Windows) is to always perform click actions upon mouse up (even on hyperlinks), so that you can cancel your action by moving away. It is also the only way to be compatible with drag and drop.
(3) The context attribute is a private / undocumented thing used for persistency. It defines the context in which the persistency API is called (am I saving a preset, a complete sessions state, or is it for undo/redo?) and may be used by the saved object if it does not save the same information in a different context. You should not care about it in general.

[Blue Cat Audio]

Regarding the order of calls on the DSP side, it depends on the plug-in format and host application / context. So it is difficult to give a precise order. The only thing you can be sure of is the init sequence (that is called before anything else).

[Blue Cat Audio]

5) (profiling dsp) It would be nice to include into AngelSctipt a getMicroseconds function (or like that) to be able to do some profiling more easily. Though it seems reading and writing to array takes so much time in AngelScript, it's difficult to make something with it, like a bottleneck to performance. But still profiling would be easier with that.

A precise timer API could indeed help. However the problem is that since it's a function call, it would also impact the performance, so you would have to be very careful with it.

Arrays are indeed a bottleneck because each read/write access is a function call (which is not the case in C/C++). If you may use the same element within an array repeatedly, is is usually worth holding a handle to it (if it is a reference type), like we do in some of the samples.

But if you are really looking for high performance, it is probably worth using the Plug'n Script C API: it is the exact same as the Angelscript API, and except for the extra compilation step, it is really as easy to use as scripting (and you instantly get 5x performance gain).

[ilyaorlov]

Thank you!
Yes, indeed C API is great and a way to go.Though AngelScript has some advantages too!

Regarding order of functions call, specifically these two:
updateInputParametersForBlock
computeOutputData

are they called before processBlock or after? So the params we work are there before or after processBlock thing?

[Blue Cat Audio]

If I remember well, they are called as you would expect:
- updateInputParametersForBlock
- processBlock
- computeOutputData
But computeOutputData is not called for every single block.