jesusonic has a neighbour: protoplug

VST, AU, AAX, CLAP, etc. Plugin Virtual Effects Discussion
RELATED
PRODUCTS

Post

Today somebody pointed me to this: http://www.osar.fr/protoplug

Im really delighted to see an opensource realtime lua effectengine out there.
This is great new, I can't wait to see a lua stompbox and upload my scripts :D
(Im aware of effort like 'the owl' e.g., very cool but very specific learningcurve)

@Cockos: can we opensource jesusonic now? thnx :D:D
======================================
music goes beyond music for the masses

Post

Fast : Use the speed of LuaJIT, and perform DSP tasks as efficiently as old school C implementations.
I know JIT compilation can make a significant difference, but Im sceptical it makes as significant a difference as this. I also cant find any benchmarks that support it; the LuaJIT page benchmarks seem to be strictly Lua vs LuaJIT.
Anyone know of something more conclusive?
my other modular synth is a bugbrand

Post

It looks cool, you can recode & compile basically on the fly. The distortion patch runs at about 7% cpu in Savihost. 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.
The only site for experimental amp sim freeware & MIDI FX: http://runbeerrun.blogspot.com
https://m.youtube.com/channel/UCprNcvVH6aPTehLv8J5xokA -Youtube jams

Post

whyterabbyt wrote:
Fast : Use the speed of LuaJIT, and perform DSP tasks as efficiently as old school C implementations.
I know JIT compilation can make a significant difference, but Im sceptical it makes as significant a difference as this. I also cant find any benchmarks that support it; the LuaJIT page benchmarks seem to be strictly Lua vs LuaJIT.
It depends on what your Lua code does.. but for "native compilation friendly" code (which would typically include all the usual DSP number crunching), LuaJIT can actually generate really good code (it's possibly the best JIT for a dynamic language; apparently Lua is a little bit easier to compile efficiently compared to JavaScript etc).

edited, in case people wonder how getting near C could possibly make sense:

Essentially the way tracing compilers (including LuaJIT and the javascript JITs in various browsers) work is that they initially interpret (or sometimes naively compile; LuaJIT 2.x uses interpreter) the code and record things like actual types of variables and other potential invariants seen. If you then look at the traces actually recorded, you get a version of the code that is a lot closer to what you'd have in a static language like C and similar compilation strategies can be used.. and that's the version of the code that is actually optimized.

For example, if a given variable always has a numeric value, it can be compiled as a number and while semantically the language might only have a single numeric type (usually double float), if we only ever observe integer values that fit into a 32-bit register, it can be compiled as such. If some statically named methods are called on bunch of objects, C++ style vtables can be generated for those types. If a given branch (possibly in some primitive function) is never taken, it probably doesn't need to be compiled in at all. Once the dynamic language has been "converted" to something more reasonable this way, all the usual compiler optimizations can be used more or less directly. Not everything is feasible for a JIT due to compilation time constraints, but LuaJIT pretty much implements the rest of the standard stuff (honestly, the list of optimizations it does is pretty impressive).

The gotcha here is that the actual traces might not be the whole truth. The way this gets handled (in a way that still allows any valid code to run correctly) is to add some pre/post condition checks to the code (if we compile a trace with a given variable fixed as a number, then in the beginning of the trace there should be a checkpoint that ensures a numeric value is passed into that trace). If those checks fail at run-time, the code has to fall back to interpreting the general version (or at least branch to a different trace), so it makes sense to try to keep your code "type stable" such that ideally all the checks will always succeed (and ideally less checks need to be compiled in at all).

The other gotcha is that for some language constructs there might not be any sensible compiled version.. so you get a call to the standard interpreter instead. Fortunately this type of stuff is usually the highly dynamic (and especially reflective) stuff that isn't usually necessary for the type of code that needs high performance.

So.. the bottom line is that naive JIT compilation doesn't usually make such a huge difference (it's typically possible to beat an interpreter by a factor of 10 or so, maybe a bit more, but that doesn't get you to C speed)... but if you have a really good optimizing trace compiler that gets to work with type-stable source code, then what you get isn't really a straight translation of the actual program.. instead you get the code that the running program actually needs, which is almost always a subset of the full language semantics (and typically a lot less dynamic too, so can be optimized much further).

Post

I know that Bluecat is developing something like that too, it will be available soon I think :D Here is a picture from his facebook account :

Image

Post

Wolfen666 wrote:I know that Bluecat is developing something like that too, it will be available soon I think :D Here is a picture from his facebook account :
That one looks like it compiles actual C++ ?

Post

For me it looks like a script language very close to C++ in its appeareance, I don't know...

Post

Wolfen666 wrote:For me it looks like a script language very close to C++ in its appeareance, I don't know...
Well, .cxx is also one of the usual suspect when it comes to naming C++ source code files (basically, ignoring the uppercase .C sometimes used on Unix, the common ones are .cc, .cpp and .cxx).

Post

Thanks for mentioning this :-)

Wolfen666 is right, it is actually a scripting language which syntax is very close to C++ or Java. It is compiled with a JIT compiler. The choice for the file extension is just to make most text editors recognize the syntax automatically.

More on this soon!

Post

I am intrigued...

Post

Blue Cat Audio wrote: Wolfen666 is right, it is actually a scripting language which syntax is very close to C++ or Java. It is compiled with a JIT compiler. The choice for the file extension is just to make most text editors recognize the syntax automatically.
Oh right, I was already wondering if you'd managed to embed clang or something, but I guess not. Are you using a custom JIT or something standard?

Post

VSTforx recently had lua scripting added too

http://www.vstforx.de/index.php/product ... ua-api/125
Amazon: why not use an alternative

Post

nm

Post

OK I have run the Mac installer twice - where the heck does this get installed? I can't find any plugin with the name of Protoplug or Lua in AU components or VST plugins, or even in Application support.

Post

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.

Post Reply

Return to “Effects”