What is KVR Audio? | Submit News | Advertise | Developer Account

Options (Affects News & Product results only):

OS:
Format:
Include:
Quick Search KVR

"Quick Search" KVR Audio's Product Database, News Items, Developer Listings, Forum Topics and videos here. For advanced Product Database searching please use the full product search. For the forum you can use the phpBB forum search.

To utilize the power of Google you can use the integrated Google Site Search.

Products 0

Developers 0

News 0

Forum 0

Videos 0

Search  

jesusonic has a neighbour: protoplug

VST, AU, etc. plug-in Virtual Effects discussion

Moderator: Moderators (Main)

sqz
KVRer
 
22 posts since 15 Sep, 2009

Postby sqz; Thu Jun 26, 2014 2:13 am jesusonic has a neighbour: protoplug

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
User avatar
Beware the Quoth
 
21098 posts since 3 Sep, 2001, from R'lyeh Oceanic Amusement Park and Funfair

Postby whyterabbyt; Thu Jun 26, 2014 2:33 am Re: jesusonic has a neighbour: protoplug

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?
To laymen, software development is something akin to wizardry. Neither time, nor effort are involved. If software is missing features they want, or has bugs, it is solely because someone has been too lazy to wave their magic wand.
User avatar
KVRAF
 
6995 posts since 2 Aug, 2005, from Guitar Land, USA
 

Postby RunBeerRun; Thu Jun 26, 2014 8:46 am Re: jesusonic has a neighbour: protoplug

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
KVRAF
 
4104 posts since 11 Feb, 2006, from Helsinki, Finland
 

Postby mystran; Fri Jun 27, 2014 10:17 pm Re: jesusonic has a neighbour: protoplug

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).
Image <- plugins | forum
KVRian
 
594 posts since 11 Aug, 2004, from Marcoussis, France
   

Postby Wolfen666; Sat Jun 28, 2014 5:20 am Re: jesusonic has a neighbour: protoplug

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
KVRAF
 
4104 posts since 11 Feb, 2006, from Helsinki, Finland
 

Postby mystran; Sat Jun 28, 2014 3:55 pm Re: jesusonic has a neighbour: protoplug

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++ ?
Image <- plugins | forum
KVRian
 
594 posts since 11 Aug, 2004, from Marcoussis, France
   

Postby Wolfen666; Mon Jun 30, 2014 10:01 pm Re: jesusonic has a neighbour: protoplug

For me it looks like a script language very close to C++ in its appeareance, I don't know...
KVRAF
 
4104 posts since 11 Feb, 2006, from Helsinki, Finland
 

Postby mystran; Mon Jun 30, 2014 11:35 pm Re: jesusonic has a neighbour: protoplug

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).
Image <- plugins | forum
User avatar
KVRAF
 
2292 posts since 7 Sep, 2004, from Paris (France)
 

Postby Blue Cat Audio; Tue Jul 01, 2014 7:25 am Re: jesusonic has a neighbour: protoplug

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!
KVRist
 
102 posts since 29 May, 2010, from Austin

Postby robertszalapski; Tue Jul 01, 2014 11:32 am Re: jesusonic has a neighbour: protoplug

I am intrigued...
KVRAF
 
4104 posts since 11 Feb, 2006, from Helsinki, Finland
 

Postby mystran; Tue Jul 01, 2014 1:12 pm Re: jesusonic has a neighbour: protoplug

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?
Image <- plugins | forum
KVRAF
 
3527 posts since 16 Dec, 2002, from over there

Postby VariKusBrainZ; Wed Jul 02, 2014 9:17 am Re: jesusonic has a neighbour: protoplug

VSTforx recently had lua scripting added too

http://www.vstforx.de/index.php/product ... ua-api/125
User avatar
KVRAF
 
1876 posts since 5 Nov, 2009
 

Postby arkmabat; Wed Jul 02, 2014 9:29 am Re: jesusonic has a neighbour: protoplug

nm
User avatar
KVRAF
 
19396 posts since 14 Sep, 2002, from In teh net
 

Postby aMUSEd; Sat Aug 09, 2014 7:55 am Re: jesusonic has a neighbour: protoplug

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.
User avatar
KVRAF
 
19396 posts since 14 Sep, 2002, from In teh net
 

Postby aMUSEd; Fri Aug 15, 2014 5:35 am Re: jesusonic has a neighbour: protoplug

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.

Moderator: Moderators (Main)

Return to Effects