jesusonic has a neighbour: protoplug

[pac-dev]

Protoplug dev here. I just came across this post, thanks for the feedback!

Blue Cat's plugin looks nice. Looks like they leave the script editing to an external editor - maybe I went a little over the top by embedding a code editor into the plugin's GUI. The embedded editor allows you to edit the main script (which gets saved into the host's project), and an external editor is still necessary to edit any include files and headers anyways.

If you're on Windows, it'll load but to compile you need one of those Microsoft C++ things, not sure which one, I have 3 installed in Sandboxie.

Hmm, normally all the runtime dependencies are included in the distribution for windows - maybe i'll check if it works on a clean windows VM. What host and OS version was this on? (You're talking about running scripts in protoplug, right? If it's about compiling protoplug itself, of course, you need a c++ compiler).

Found them finally - they were installed to \Users\username\Library\Audio\Plug-Ins\VST, which is not the correct path for plugins on Mac. None of my hosts look there.

Yeah, as you might have guessed, I'm not much of mac user, but I'm still resolute on keeping a proper mac release - apparently that failed pretty hard. Creating a pkg wizard-style installer may have been ill-advised, a more appropriate way of distributing plugins would be through a dmg archive that lets you drag the plugins to wherever you want, correct?

Anyways, I'll get that into the next release - among other things - and I'll post here when it's out. Now I'm trying to automate the release cycle, and mac is not playing nice with cross-platform automated releases. I'm not sure how the hell ctrl does it (looks like pure magic).

@mystran - thanks for the detailed explanation. Right now, I think one of the only factors that make a speed difference between C and protoplug/LuaJIT is the floating point width: In LuaJIT, all floating-point numbers are doubles, while in C you'd normally use smaller floats for musical DSP. This could result in 2x processor usage for the LuaJIT version, assuming all floating-point operations are vectorized in the compiled C version. But of course, they're not always vectorizable: it depends on the algorithm. In short, performance relative to C will depend on what your script does: it could between equal performance and 2x processor usage. That's still ridiculously fast, but I guess the formulation on the website is mildly misleading (but not entirely wrong...)

[mystran]

If you're on Windows, it'll load but to compile you need one of those Microsoft C++ things, not sure which one, I have 3 installed in Sandboxie.

Hmm, normally all the runtime dependencies are included in the distribution for windows - maybe i'll check if it works on a clean windows VM. What host and OS version was this on? (You're talking about running scripts in protoplug, right? If it's about compiling protoplug itself, of course, you need a c++ compiler). ¨

About 99.9% of "those MSVC thingies" refers to dynamically linked .DLL files which then require MSVCRTxxx.DLL etc from the MSVC++ redistributable, which needs to be separately installed. Many (most?) devs just compile their VST with statically linked runtime to avoid this, so we can have our "just drop the DLL there" type install.

[edit: and one of the "downside" that MS gives, namely the separate CRT state, is actually nice in a plugin as well, as you don't accidentally end up changing some CRT state for the host]

@mystran - thanks for the detailed explanation. Right now, I think one of the only factors that make a speed difference between C and protoplug/LuaJIT is the floating point width: In LuaJIT, all floating-point numbers are doubles, while in C you'd normally use smaller floats for musical DSP. This could result in 2x processor usage for the LuaJIT version, assuming all floating-point operations are vectorized in the compiled C version.

AFAIK, there's no auto-vectorization in LuaJIT. Correct me if I'm wrong, but AFAIK it simply uses SSE2 scalar code (like you're probably going to compile most C as well) and scalar singles and doubles run roughly the same speed on any modern CPU (sometimes doubles might be faster). The main down-side of doubles is that you end up with twice the memory (and cache pressure) for you buffers, but usually that isn't a problem for audio, where you might even want to use doubles (depending on algorithm) for the extra precision.

Now if you compare scalar code with vectorized version of something that actually vectorizes well .. then that's another story .. but if you care about that, you're probably going to be writing your own vectorized routines, rather than relying on the compiler to try to get it right.

[pac-dev]

Bumping the ol' thread because of several things:

• Since yesterday there's a forum so anyone can post their scripts: forums.osar.fr
• The OSX installer is now less stupid
• Linux now has proper per-distro packages thanks to the Open Build Service

see the downloads page

I haven't added any scripts but someone asked for a dynamics compressor, so I might try throwing together a basic one... I guess a really basic one would be literally a few lines of code, though I'm not much of a dynamics compressor guy. A spectral compressor, now that would be cool!