Blue Cat Audio

XeonKnight · Post by **XeonKnight** » Thu Apr 12, 2018 8:39 pm

Blue Cat Audio wrote:Do you mean the frequency response of an EQ for example, as shown below?

Close, I was considering implementing a filter but wanted to have the frequency response graph behind the filter graph. Similar to the waveform preset in the lower left only drawing the entire frequency response 10hz-20khz. Like most EQs do, including the eq in Patchwork if you click on the spectrum.

Blue Cat Audio · Post by **Blue Cat Audio** » Fri Apr 13, 2018 7:52 am

Oh so you meant the analyzed spectrum... Right now it is not really possible, as there is no raw data output for the dsp (yet).

ilyaorlov · Post by **ilyaorlov** » Fri Jul 06, 2018 4:27 pm

Hello!

First of all thank you for a very inspiring piece of software. It really helps to make first steps and dig a deeper into signal processing. You made this process way easier!

Now I'm trying to make a script that measures compressor Attack and Release (I develop hardware compressor and found no good tools for easy measuring). My tool consists of two Plug-n-Script plugins, one generates signals, other measures them and does calculations. So far I've got almost no problems with algorithms, but I'm a little stuck with DSP/KUIML interaction.

FIrst of all I used envelope follower script to see the envelope. As I want to see fast changes (to see attack properly) I tried to set CURVE_FROM_PARAM_OVER_TIME refresh_time_ms="1", but as I found out my host doesn't update output params often enough. computeOutputData() is called about 40-50 times a second and doesn't go much faster even if I change output data refresh rate.

So i tried to send not a single level value but a pack of values packed in "doubles"

(that was a bit of pain, I wish we had possibility to send raw data and output strings to KUIML). And I tried to use TIMER to update each 1ms and update PARAM that is used to display CURVE_OVER_TIME. It helped a bit, but as I found out TIMER also doesn't update that often really, so the curve still has steps. Maybe I should mess with SKIN refresh_time_ms? Or 1ms is too fast anyway?

I tried to use "feedback" from KUIML to DSP modifying "custom_param1" to let DSP know when something is done. I see updates in the GUI, but DSP doesn't receive the data custom_param1 modified by script. Only if I modify custom_param1 with mouse, but not with script. I've read about "BeginCapture" for params, but I couldn't make it work. Is it supposed to work like this?: custom_param1.BeginCapture(); I see BeginCapture works in Axiom skin with other params, but in PnS it throws error (No matching signatures to Param::BeginCapture. ) Thought I added custom_param1;custom_param1.BeginCapture to EXPOSED_OBJECTS, don't know where's the problem.

So my questions are:

1) Are there plans to let users send output raw data (maybe output arrays or strings) from DSP to KUIML?
2) What is the best way to display fast changing volume on graph? Such as viewing compressor attack and release.
3) How the CURVE element can be used? Only for copying other curves made with FORMULA_CURVE and CURVE_FROM_PARAM_OVER_TIME? Can a CURVE be drawn with an array of x/y points or something like that?
4) How BeginCapture and EndCapture should be used in PnS?
5) What is a good solution to communicate between two plugins? Say if one plugin parameter changes other plugin responds to that? Only through writing/reading files, or maybe there's another level of communication? Like windows messages or through memory or through tcp/ip or whatever? (I guess I can send params forward though audio stream).

Thanks in advance for great tools!

Blue Cat Audio · Post by **Blue Cat Audio** » Tue Jul 10, 2018 10:02 am

This sounds like a very interesting project!

Plug'n Script is indeed a bit limited regarding output data (it is currently possible to communicate with parameters only). We actually have plans to add more capabilities in the future, such as output strings, raw buffers or curves/surfaces, but there is still quite a bit of work.

As their names suggest, the input parameters are only for DSP input, so you cannot modify them from DSP, and the capture stuff is not accessible from the DSP anyway.

Timers in the GUI cannot be much shorter than 10 ms (and it may depend on the host application too). There is however maybe a way to get faster updates, if you change the refresh priority of the GUI. This simply requires modifying the main plug-in skin (adding refresh_priority="normal" to the skin). So you will probably want to copy the skin from the plug-in data folder into your documents and modify it there.

Output parameters will be refreshed only once per audio buffer, so it can be the limiting factor, whatever the output data rate. Maybe you can use smaller buffers in your host? In the end it might still be a bit too long for your measurements (what is your typical attack time?), but it could still improve the display.

Another way of doing it would be to do pre-analysis of the data in the DSP instead of displaying RAW data: since you know the shape of the curve in advance, you could maybe try to find out the typical points of the curve before sending just a few coordinates to the GUI that would display a curve with these?

Regarding communication between instances, there is currently nothing special in place with scripts, so using a shared file is probably the only way.

ilyaorlov · Post by **ilyaorlov** » Fri Aug 03, 2018 7:03 pm

Thank you for explanation! Things got clearear!

I'd like to share a few ideas:

1) I found "Reload script" button too small to find (and it's the most useful one), so changing the skin a bit made possible to refresh script clicking on plugin name. It's much bigger/easier-to-click and saves screen space, cause you can hide side panel.

it's a change in "default.xml" skin:
<ROW>
<TEXT string_id="$script_name_string$" id="script_title.text" width="0">
<INVISIBLE_PARAM_TOGGLE_SWITCH param_id="dsp.input1" width="100%" height="100%" cursor="system::hand">
<TOOLTIP text="Reload script"/>
</INVISIBLE_PARAM_TOGGLE_SWITCH>
</TEXT>
</ROW>

2) Another happy moment - I found a way to communicate with plugin from the "outer world" via virtual COM-ports. I made a few port-pairs with help of com0com and then used "file" object to open COM-ports and read and write to it. So I can send data from Plug-n-Script to my Arduino for example, or another program (I use Autohotkey a lot, for example). Thats a great thing for me. Sadly I couldn't find a way to open the same COM-port in Angelscript for both reading and writing, so I have to use two ports for that.

This is a way to write to COM-port:

file serialOut;

// while initilizing
if(serialOut.open("\\\\.\\COM15","w")>=0) {
print("Opened OUT port COM15");
} else {
print("Failed to open OUT port COM15");
}

// ... and somewhere in code...
serialOut.writeString("PNS volume: " + inputParameters[0] + "\n");
serialOut.setPos(0); // to send data immediately

// reading from COM-port worked yesterday, but today it's not working somewhy

still testing...

///////////////////////

1) one question is about opening file for both "r" and "w" to use one COM-port in both directions. Right now I couldn't find the solution, only to use two different COM-ports. Maybe there's a way to do it in AngelScript/PNS?
2) another is about closing COM-port. Maybe there is a function in Plug-n-Script API that is called when script is closing/reloading/something like that? So that I can close opened "file". Or should I just not care, and Angelscript does that for me?

ilyaorlov · Post by **ilyaorlov** » Fri Aug 03, 2018 7:58 pm

Regarding my compressor attack-release measurement project, I found saving level data in SVG images is a good thing, so I can get big nice graphs (starting from the same "pre-attack" point), so it's easy compare it, for example to match one compressor to another and so on.

By the way, how can we get current datetime in Plug-n-Script? For example to save file using datetime in it's name.

ilyaorlov · Post by **ilyaorlov** » Fri Aug 03, 2018 8:06 pm

Right now I'm working on "Threshold/Ratio" measurement and got another question:
is there a way to make a parameter be both controlled manually and automatically from DSP? For example I want to be able to set "threshold" manually, but also to be able to turn on "auto-threshold" option, so that threshold knob is updated automatically. Right now I used output and input params and PARAM LINK to connect output param to input. This seems to work but has some problems like INPUT param is updated only visually, but still remembers it's last value set manually and is not updated in "updateInputParameters" until you really move it by hand (or change another input parameter).

So is there a correct way to implement this?

And one also question: CURVE_FROM_PARAM_OVER_TIME "duration_ms" is not changeable from the script? Updating "refresh_time_ms" works fine, but updating "duration_ms" fails. Maybe I'm missing something.

Sorry for too much messages

Thank you once again for a great tool, opening so many new possibilities!
Will be glad to see it growing and expanding.

Blue Cat Audio · Post by **Blue Cat Audio** » Tue Aug 14, 2018 1:23 pm

Thanks for sharing your findings. Opening COM ports looks like a very interesting feature we were not even aware of

. The "rw" option does not exist in the file API (it's using fopen behind the scenes), but maybe you can try "w+" or "r+" that should allow both writing and reading.

When the file object is released the associated file is closed, so it is not strictly necessary to close it manually. But you can call the "close" method to close it (see the file API).

Blue Cat Audio · Post by **Blue Cat Audio** » Tue Aug 14, 2018 1:30 pm

Your SVG curves are very nice! There is a date API addon in angelscript but it is not included with PLug'n Script. Maybe we can add it in a future release!

Input parameters are indeed not writable from the DSP and that's on purpose. In your case, you probably want to use two different parameters: threshold_mode (auto/manual), and manual_threshold_value and when in auto mode simply ignore the manual threshold value. Since in "auto" mode the value is computed by the DSP there is no need to link it back to the input, right? You can maybe just display its value (as an output parameter)?

Pure-fire · Post by **Pure-fire** » Sun Sep 09, 2018 6:08 am

Hello Blue Cat,
do you can add more than 48 InputParameters ()?
For example 256. Very few 48 for some opportunities.

Blue Cat Audio · Post by **Blue Cat Audio** » Mon Sep 17, 2018 6:28 pm

It is currently not in the plans. What kind of plug-in do you intend to write that needs so many parameters?

MasterTuner · Post by **MasterTuner** » Sun Oct 28, 2018 7:41 pm

Am somewhat tempted to buy this, but can't find any tutorials, or tutorial youtube videos on it.
I have some past programming experience in C etc, but would be really nice to have a tutorial or forum that could help get me started.

Tappistry · Post by **Tappistry** » Mon Oct 29, 2018 12:25 am

MasterTuner wrote: ↑Sun Oct 28, 2018 7:41 pm Am somewhat tempted to buy this, but can't find any tutorials, or tutorial youtube videos on it.
I have some past programming experience in C etc, but would be really nice to have a tutorial or forum that could help get me started.

Agreed, some basic "get off the ground" videos would be helpful.

Blue Cat Audio · Post by **Blue Cat Audio** » Mon Oct 29, 2018 10:25 am

I don't think videos are appropriate for software development tutorials, but we indeed have plans to work on more tutorials in the future. Have you already read the user manual? It contains a summary of the steps required to build a new plug-in as well as a complete description in details for each step.

MasterTuner · Post by **MasterTuner** » Mon Oct 29, 2018 5:18 pm

Looked in the Plug n Script manual for what kind of functions I would have access to.

Couldn't find these, but wondered if there was easy access to these things I might want to include in my plugin:
a Flanger
Chorus
Phaser
Wet/Dry functionality

Blue Cat Audio

KVR Audio

Blue Cat's Plug'n Script V3 Released - Now with VST Plug-in Export!