The amazing CMT Attack Release plugin brought me to try the Plug N Script.
Blue Cat, I think your platform is a game changer. I've been trying a few other platforms and I can't get anywhere with them. Everything in the world of plugin-making feels unfriendly, broken and/or under documented. Yours is the first plugin-making platform I tried that turns on without errors, shows a sample plugin, and lets me tweak the code and see what it does. It is not that simple anywhere else.
Lots of great decisions too. Like letting me use my own code editor instead of investing time to try to make one.
But the game changer is being able to export to standalone plugins. That part is usually a huge barrier without a great platform doing the heavy lifting.
Obviously a great deal of work and care has been put into this already. I feel that you are very close to having Plug'n Script become a solution for indie developers trying to make small commercial plugins. To that effect I wanted to give you some feedback:
1. The exposed source code. It wouldn't be hard to go the extra mile and encrypt the code. I don't think it has to be anything impenetrable, just not exposed. Developers have a right to some privacy in terms of the way they solve audio challenges. The plugins should be judged on how they work and sound, not the code approach that a developer applied.
2. Easy tool to add a background. You have some nice and simple on/off design elements. If there was an option to choose a background image file for the plugin, it could add a lot of character/uniqueness to the interface without requiring code.
3. The menu bar. It feels very much like the Blue Cat experience. But each maker may want a different feeling. So having a few variations of the bar can help plugins feel more unique. I think there should be at least 3 more options:
- The ability to choose the highlight color (currently blue). Preferably not as a dropdown but as a color code.
- A wide and slim version of the menu with the buttons in a single row, for plugin designs that are longer and don't need a logo on the right (see the bar that Waves uses)
- Menu bar style variations. At least color choices away from black, maybe silver/gray. But it could give the option of the current shaded style or a flat color (with the ability to add a color code).
4. This might be nitpicking, but I could also use a "ghost" knob that lets me use my own png image file for the circular knob and you just put the rotating line/marker on top. This would go very well with the ability to add my own background, then I can be in a lot of control of how the GUI feels to the end user. The idea is that I can visually design my knob, import the png file, and then use the knob as any other knob in your system without having to write code.
I'm going to try to find time to play with it some more. So far I'm very excited about Plug'n Script.
Blue Cat's Plug'n Script V3 Released - Now with VST Plug-in Export!
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981 - KVRAF
- Topic Starter
- 5821 posts since 8 Sep, 2004 from Paris (France)
Thank you for sharing!ilyaorlov wrote: ↑Wed Dec 19, 2018 1:02 pm By the way, there's a github repository for that project (for those, who are interested in how it's made).
https://github.com/ilyaorlovru/cmt
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- Topic Starter
- 5821 posts since 8 Sep, 2004 from Paris (France)
@jochicago: thank you for the feedback. We could indeed encrypt the script code to make it unreadable, but we haven't done it so far because it would be pretty easy to crack, and we do not want people to think that it is completely safe.
(2) could indeed be implemented in a future release. But it may also require that you can adjust the position of all the elements as well.
For (3) and (4) the current way to do it is to write KUIML code for it (if you can write dsp code, KUIML is a piece of cake). We are looking at doing a WYSYWIG editor with more options in the future but it is a rather complex thing.
(2) could indeed be implemented in a future release. But it may also require that you can adjust the position of all the elements as well.
For (3) and (4) the current way to do it is to write KUIML code for it (if you can write dsp code, KUIML is a piece of cake). We are looking at doing a WYSYWIG editor with more options in the future but it is a rather complex thing.
-
- KVRist
- 302 posts since 28 May, 2011
Hey, jochicago, glad to see you're interested too!
I agree with most of your thoughs. Though visual things are really possible with KUIML, just need to dig deeper. It's not that simple, but not impossible to redesign toolbar and change background. Though if it would be easier I'd we glad too.
I agree with both of you about Angelscript code encryption. It would be a nice option, even if it's not totally safe. The developers would feel a bit less "naked". Especially when your source code is not that beautiful
))
My "bottleneck" now is the communication between .cxx and .kuiml. We can only send data using 32 output params (only 32 float values at once, and quite slowly) and we can send data back from KUIML via input_strings (I have to use input_strings because input_params are somewhy not "writeable" from KUIML scripting engine, only if you change them by hand (with a keyboard/mouse)).
So if I want to send a big chunk of data (for example to draw a plot, to output FFT data or anything like that) I have to do a lot of strange things, trying to pack data into 32 floats and send them one by one (or in packages), waiting for KUIML to receive them and to respond back. It's possible but really slow and difficult.
1) I wish we had more ways to send data from .cxx to .kuiml (and maybe back too).
Probably it would be cool to be able to fully use CURVES and SURFACES and STRINGS etc.
2) Another nice thing would be to be able to select which formats to export (when building plugins). It could just speed things up when doing it again and again.
Though, Blue Cat, thank you for what you've done already, it's quite amazing!
I agree with most of your thoughs. Though visual things are really possible with KUIML, just need to dig deeper. It's not that simple, but not impossible to redesign toolbar and change background. Though if it would be easier I'd we glad too.
I agree with both of you about Angelscript code encryption. It would be a nice option, even if it's not totally safe. The developers would feel a bit less "naked". Especially when your source code is not that beautiful
))My "bottleneck" now is the communication between .cxx and .kuiml. We can only send data using 32 output params (only 32 float values at once, and quite slowly) and we can send data back from KUIML via input_strings (I have to use input_strings because input_params are somewhy not "writeable" from KUIML scripting engine, only if you change them by hand (with a keyboard/mouse)).
So if I want to send a big chunk of data (for example to draw a plot, to output FFT data or anything like that) I have to do a lot of strange things, trying to pack data into 32 floats and send them one by one (or in packages), waiting for KUIML to receive them and to respond back. It's possible but really slow and difficult.
1) I wish we had more ways to send data from .cxx to .kuiml (and maybe back too).
Probably it would be cool to be able to fully use CURVES and SURFACES and STRINGS etc.
2) Another nice thing would be to be able to select which formats to export (when building plugins). It could just speed things up when doing it again and again.
Though, Blue Cat, thank you for what you've done already, it's quite amazing!
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- Topic Starter
- 5821 posts since 8 Sep, 2004 from Paris (France)
We'll definitely think about encryption for future releases - if possible something than cannot be broken in a few seconds...
Regarding complex data sharing between the dsp and the GUI, this is indeed a limitation we are aware of. While sharing curves and surfaces is quite challenging because it would require the ability to dynamically share script classes, we are looking at ways to share arbitrary binary data (as input or output of the DSP). The API is not defined yet but we'd like to have a very simple way to read/write into binary blobs on both sides.
Regarding complex data sharing between the dsp and the GUI, this is indeed a limitation we are aware of. While sharing curves and surfaces is quite challenging because it would require the ability to dynamically share script classes, we are looking at ways to share arbitrary binary data (as input or output of the DSP). The API is not defined yet but we'd like to have a very simple way to read/write into binary blobs on both sides.
-
- KVRist
- 302 posts since 28 May, 2011
While waiting for binary data intercommunication 
, here are a few examples I'd like to share.
The (1) example is about drawing arbitrary plot using FORMULA_CURVE (you just have to make a very complex curve. But this script show how to do it automatically. You just add Y points in KUIML like this:
<!-- ADD POINTS -->
<ADD_POINT y="0" /> <!-- for x = 0 -->
<ADD_POINT y="1" /> <!-- for x = 1 -->
<ADD_POINT y="-1" /> <!-- for x = 2 -->
.. and so on.
And the rest is done automatically (three formulas are created to draw stepped, linear and smooth plots out of these values).
There's also a demo how to link this values to params sent from .CXX
The (2) example is advanced Formula Viewer. It uses FORMULA_CURVE and other elements to display arbitrary formulas. You can zoom/switch formulas and compare formulas one to another. Adding formulas is easy. The version (2) adds Kaiser-Bessel Window formula (ughhh, that was complex) for those interested in FIR filters and FFT analysis. Also version (2) creates different elements for each formula, so you can freely use Log() functions in it.
The (3) example is an attempt to transfer a big amount of data from .CXX to KUIML to display it as level values using CUS_VMETER elements. As CXX can send only 32 output params at once, it's a limitation for sending lots of data. So this script uses only 16 output params to send arrays of any size from CXX to KUIML. Version 2 also implements "data packing" so 3 values are sent in one outputParam. It increases the speed x3 times.
Feel free to examine, use and develop further:
https://github.com/ilyaorlovru/plug-n-script-examples
, here are a few examples I'd like to share.The (1) example is about drawing arbitrary plot using FORMULA_CURVE (you just have to make a very complex curve
. But this script show how to do it automatically. You just add Y points in KUIML like this:<!-- ADD POINTS -->
<ADD_POINT y="0" /> <!-- for x = 0 -->
<ADD_POINT y="1" /> <!-- for x = 1 -->
<ADD_POINT y="-1" /> <!-- for x = 2 -->
.. and so on.
And the rest is done automatically (three formulas are created to draw stepped, linear and smooth plots out of these values).
There's also a demo how to link this values to params sent from .CXX
The (2) example is advanced Formula Viewer. It uses FORMULA_CURVE and other elements to display arbitrary formulas. You can zoom/switch formulas and compare formulas one to another. Adding formulas is easy. The version (2) adds Kaiser-Bessel Window formula (ughhh, that was complex) for those interested in FIR filters and FFT analysis. Also version (2) creates different elements for each formula, so you can freely use Log() functions in it.
The (3) example is an attempt to transfer a big amount of data from .CXX to KUIML to display it as level values using CUS_VMETER elements. As CXX can send only 32 output params at once, it's a limitation for sending lots of data. So this script uses only 16 output params to send arrays of any size from CXX to KUIML. Version 2 also implements "data packing" so 3 values are sent in one outputParam. It increases the speed x3 times.
Feel free to examine, use and develop further:
https://github.com/ilyaorlovru/plug-n-script-examples
You do not have the required permissions to view the files attached to this post.
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- Topic Starter
- 5821 posts since 8 Sep, 2004 from Paris (France)
That's a very nice trick to create interpolation formulas!
It is amazing that the dsp communication "hack" actually works without too much overhead. We'll definitely work on binary data shortly to simplify your work!
Thanks for sharing!
It is amazing that the dsp communication "hack" actually works without too much overhead. We'll definitely work on binary data shortly to simplify your work!
Thanks for sharing!
-
- KVRist
- 302 posts since 28 May, 2011
Thanks! I would be glad to have more appropriate and stable option for sending that data!
I also think that it'd be very good to allow output strings be sent, cause they also can be used for that purpose.
And the first thing I met when started developing a plugin - is that we can't just output a string (print) to user interface. Print function that prints to log is great/sometimes much better for debugging, but just outputting a string would be good too!
I also think that it'd be very good to allow output strings be sent, cause they also can be used for that purpose.
And the first thing I met when started developing a plugin - is that we can't just output a string (print) to user interface. Print function that prints to log is great/sometimes much better for debugging, but just outputting a string would be good too!
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- Topic Starter
- 5821 posts since 8 Sep, 2004 from Paris (France)
Yes, strings would be the easiest way to carry more complex data. You need however to make sure they have been pre-allocated to avoid drop-outs during real time audio processing.
-
- KVRAF
- 2797 posts since 26 Jul, 2015 from Philadelphia
Not sure if that has been asked before but would it be possible to increase the number of channels from 8 to 16? With 8 channels you can do stuff for up to 7.1 surround, but many of the more recent immersive formats (7.1.2, 7.1.4, 2nd order AmbiX, 3rd order AmbiX, FB360, etc) need between 9 and 16 channels of audio.
Follow me on Youtube for videos on spatial and immersive audio production.
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- Topic Starter
- 5821 posts since 8 Sep, 2004 from Paris (France)
We have not thought about it yet, but why not. It may require a separate version though for backward compatibility reasons.
-
- KVRAF
- 2797 posts since 26 Jul, 2015 from Philadelphia
Steinberg introduced an integrated VR workflow based on 16 channel Ambisonics in Nuendo 8.3 and later also in Cubase 10. Plugins that can be used in that workflow are rare. It's a niche market, but given that there is not much around it might be an interesting one. I would pick it up immediately.Blue Cat Audio wrote: ↑Mon Apr 01, 2019 9:13 am We have not thought about it yet, but why not. It may require a separate version though for backward compatibility reasons.
Not to mention that 7.1.2 Atmos seems to be becoming the standard for surround.
I obviously don't know your code. But given that you are already supporting 8 channel surround, bringing that up to 16 channels is probably not a big deal for you, especially if you keep the versions separate.
Follow me on Youtube for videos on spatial and immersive audio production.
-
- KVRer
- 2 posts since 30 Mar, 2019
Hi,
I'm currently developing a multi-track looper in Plug 'n Script based on native C++.
I'm relatively new to C++ but as the performance of my Angelscript version was problematic in terms of performance I kind of had no choice.
I got my prototype running on Mac Os and am now trying to make it work on Windows.
The project compiled in Visual Studio w/o any warnings but when I load the dll in Blue Cat PnS it throws a bunch of error messages:
Loading script file: C:\Users\quarc\source\repos\Audio Plugins\x64\Debug\MofflR.dll
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(1:3)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(1:3)
Error: Unexpected token '/' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(4:2692)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(4:5716)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(4:9316)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(6:8181)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(6:8842)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(25:8)
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(27:1206)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(27:1206)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(64:557)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(64:1294)
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:569)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:569)
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:911)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:911)
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:1284)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:1284)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(71:1093)
Error: failed to initialize script
It would be great if you could give me an idea how to debug this issue.
What do the numbers at the end of each line refer to? It's definitely not the line in the source code.
Or maybe you have an idea what the issue may be.
Thank you
I'm currently developing a multi-track looper in Plug 'n Script based on native C++.
I'm relatively new to C++ but as the performance of my Angelscript version was problematic in terms of performance I kind of had no choice.
I got my prototype running on Mac Os and am now trying to make it work on Windows.
The project compiled in Visual Studio w/o any warnings but when I load the dll in Blue Cat PnS it throws a bunch of error messages:
Loading script file: C:\Users\quarc\source\repos\Audio Plugins\x64\Debug\MofflR.dll
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(1:3)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(1:3)
Error: Unexpected token '/' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(4:2692)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(4:5716)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(4:9316)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(6:8181)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(6:8842)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(25:8)
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(27:1206)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(27:1206)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(64:557)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(64:1294)
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:569)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:569)
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:911)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:911)
Error: Expected identifier in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:1284)
Error: Instead found '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(66:1284)
Error: Unexpected token '<unrecognized token>' in C:/Users/quarc/source/repos/Audio Plugins/x64/Debug/MofflR.dll(71:1093)
Error: failed to initialize script
It would be great if you could give me an idea how to debug this issue.
What do the numbers at the end of each line refer to? It's definitely not the line in the source code.
Or maybe you have an idea what the issue may be.
Thank you
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- Topic Starter
- 5821 posts since 8 Sep, 2004 from Paris (France)
It is just because the file extension is not recognized, so Plug'n Script tries to load the dll as a source file. Change the .dll into .x86 or .x64 (depending on the architecture you are using) and it load properly.
-
- KVRer
- 2 posts since 30 Mar, 2019
Great, that did the trick!
Thanks a lot.
Thanks a lot.
