Is Protoplug / LUA still a thing? (Updating my fork of it as a hobby project)

[] Peter:H []

I have found some joy scripting little FX by using the Protoplug/LUA plugin (https://www.osar.fr/protoplug/), you can check out a first outcome here: My catmul-rom spline based Amplitude shaper... viewtopic.php?p=8252889#p8252889
while refactoring this thingy I came to the conclusion that Protoplug itself first needs a brush up
But there's more in the pipe.

Anyways...It seems that the Protoplug project is abandoned by the author because it hasn't received updates in a while. So I have forked the source code repo and tried several updates on a proof-of-concept level... Meaning to say. There's no releasable outcome (yet).

Here's my little updates to Protoplug (we are not speaking about Lua scripts,it's about the plugin):

• Upgraded Build to Visual Studio 2019.
• Added a VST3 build, though this is not really what you want to use when you try out midi stuff with Protoplug. Damn VST3 is really stupid...
• Added a newer version of the luajit dll which is lightning fast.
• Upgraded to Juce 6, actually not adding more features to Protoplug, but to get it a little more up to date.

Anyway ... I do this as may hobby and I don't spend time to build "releases" because building good quality stuff is tedious. Second I don't own any other hardware than PC/Windows and won't change that.

If anyone would be interested in the updates to Protoplug I would first try to get my github fork clean and nice (Source Code level) and then probably I would add builds as well (Binaries). But please keep in mind only PC/Windows...

What you say? Anyone still using it? Anyone interested in the updates?

[Klinke]

I have developed a Looper (which needs the Livid Code controller as hardware) using Protoplug, so I am interested. But mainly because of the newer luajit version. I have already build Protoplug by myself, as I need more audio outputs then the default configuration, can I just replace the luajit.dll in the Visual Studio project, or are there additional steps necessary?

Thanks

[] Peter:H []

I have developed a Looper (which needs the Livid Code controller as hardware) using Protoplug, so I am interested. But mainly because of the newer luajit version. I have already build Protoplug by myself, as I need more audio outputs then the default configuration, can I just replace the luajit.dll in the Visual Studio project, or are there additional steps necessary?

Thanks

Cool!

Newer Luajit-Version: I have "forked" a repo from luapower, you can find it here: https://github.com/huberp/luajit. I dropped the followig dll into the protoplug installation folder and it worked... so yes, just replace the dll. https://github.com/huberp/luajit/blob/m ... /lua51.dll

More outputs: I would be interested in adding that as well... though my original idea was to add side-chain inputs. but more outputs would not be bad either. can you show me what you have changed and how to use it in the scripts? Or drop a PR here ... https://github.com/huberp/protoplug

Thanks and best regards
Peter:H

[Klinke]

Newer Luajit-Version: I have "forked" a repo from luapower, you can find it here: https://github.com/huberp/luajit. I dropped the followig dll into the protoplug installation folder and it worked... so yes, just replace the dll. https://github.com/huberp/luajit/blob/m ... /lua51.dll

Great, but when I just tested this, I detected that my Visual Studio Project does not work anymore on my current computer. I will investigate this later, or just try your fork in the case that you release it.

More outputs: I would be interested in adding that as well... though my original idea was to add side-chain inputs. but more outputs would not be bad either. can you show me what you have changed and how to use it in the scripts? Or drop a PR here ... https://github.com/huberp/protoplug

I think I just integrated this pull-request:
https://github.com/pac-dev/protoplug/pull/14

[Tj Shredder]

I would immediately support CLAP instead of VST3. VST3 can then be covered by an upcoming wrapper which you don’t need to care of…

[] Peter:H []

Newer Luajit-Version: I have "forked" a repo from luapower, you can find it here: https://github.com/huberp/luajit. I dropped the followig dll into the protoplug installation folder and it worked... so yes, just replace the dll. https://github.com/huberp/luajit/blob/m ... /lua51.dll

Great, but when I just tested this, I detected that my Visual Studio Project does not work anymore on my current computer. I will investigate this later, or just try your fork in the case that you release it.

You don't need to build the plugin to use the new dll. just replace the dll in C:\Program Files\Common Files\VST2\Protoplug\ProtoplugFiles\lib with the new one.

More outputs: I would be interested in adding that as well... though my original idea was to add side-chain inputs. but more outputs would not be bad either. can you show me what you have changed and how to use it in the scripts? Or drop a PR here ... https://github.com/huberp/protoplug

I think I just integrated this pull-request:
https://github.com/pac-dev/protoplug/pull/14

Thank's I will have a look!

[] Peter:H []

Just post here a success story because I feel happy ... it's my experiments with Protoplug that took a few major steps and that's very cool and rewarding

I'm now able to spin up threads with lua in protoplug and additionaly I can draw opengl stuff...
this involved a "tiny" bit of fiddling with MSys2 (environment for Windows to build stuff based on cmake), getting libraries like libwinpthread-1.dll, glfw.dll and more and adapting a few lua scripts coming from the guys from luapower. Threading and openGl was not included with out of the box protoplug ...

The screenshot shows protoplug with a opengl cube spining in a seperate window using it's own thread ... thus not distracting the audio processing. After making threads work I was today able to put openGL Code into it's own thread.
Next step will be to get imgui to work within Protoplug ... https://github.com/sonoro1234/LuaJIT-ImGui
It's yet far from releaseable and still needs much work, but anyway fun.

ProtoplugThreadGLFW.jpg

 

[Kirkwood West]

this is wicked... just learning about protoplug today.

[Dewdman42]

I'm definitely interested in rescuing this project or contributing to it. The original code is 10 years old now and the developer Pierre is MIA since long time ago. I would like to get it up to speed with JUCE7 and in such a way that hopefully rolling forward it will be easier for open source community to continue supporting it. All the forks so far have done just a few little changes and bumped the can down the road, but really it needs more refactoring to move forward.

I don't have a lot of JUCE experience so it will take me a while, but this is what I intend to do:

1. I will start with the following fork from getdunne (dev of Unify), because he allegedly removed the Type library that doesn't have proper MIT license. So its a good place to start from. I'm unable to build is fork right now to test that out, but that is what I will start with.
   
   https://github.com/pluginguru/protoplug-free
2. I will set it up to build with cmake, which hopefully should make it less painful to get windows and linux builds happening, I am primarily MacOS, but will try to build windows too.
3. Will update the code to eliminate build errors and warnings under JUCE7, the code was written under JUCE5 I believe, numerous things were deprecated since then, so this code needs to be updated in general
4. I will look at what you did to update the JIT compiler to something more modern and faster.
5. I will be updating the Lua includes to include more and better support functions
6. Will include AU, AUmfx, VST, VST3 builds. VST build will not have the SDK so will be turned off by default but manual instructions for how to add it if you have the SDK and license to do so.
7. Eventually LV2 and when JUCE supports CLAP maybe that too.
8. If possible under JUCE7 will add possibility to have more midi ins and outs, and more audio ins and outs
9. Will provide instructions for local manual build, but eventually also GitHub actions to automatically build it

This scripter has a lot of promise but due to lack of ongoing developer support I do not feel its worth the time to write scripts with it because it could stop working at any time, and already is in fact outdated compared to current JUCE libraries. There is no Mac Arm build either, etc. So there is no point to write scripts with this plugin unless we can establish a better open source foundation for it to continue to be supported easily enough rolling forward.

Alternatives

PlugNScript, is actively supported and capable. Not free and uses bloody angelscript which is not as handy as Lua by a long shot.

KushView Element has a Lua scripter built in that is coming on line soon. still has some bugs to work out, but it may very end up being a better solution for Lua scripting in the long run then bothering to support ProtoPlug. Developer is still actively working on it(slowly)

Loomer Architect, has Lua scripting built in.

Soundigy MidiLab has basically used Protoplug's Lua scripter under MIT and expanded it, but this also has not seen much updating from the author, so hard to justify paying money for something that is not being actively supported.

[kidslow]

Have recently traded some emails with Michael, developer of Kushview Element. He is definitely responsive and active, and said he would specifically welcome additional Lua script testing and contributions when I brought that up. That's where my focus will go, such as I have a focus, lol. But don't let me dissuade you from your windmills.

[Dewdman42]

I am testing out the developer build of kushview Element also. I am VERY hopeful about the future prospect of Kushview Element's Lua module, but it's not ready for prime time yet IMHO. He's very committed to it, so it will get there eventually.

This week I actually did a test lua script, somewhat complex 500 lines of lua code... ported over from something I did previously with LogicPro Scripter javascript and later from PlugNScript angelscript. it crashes Element when you load the script... probably has bugs to be worked out, but can't figure that out when it crashes so easily. Honestly nothing in lua should ever crash its hosts IMHO, so there is work yet to be done there, but I like the direction it's going a lot.

I also took that same lua script and attempted to drop it into ProtoPlug, which involved changing it to use ProtoPlug's API (and while I was at it I had to actually modify the API), but in any case, in a few hours I was able to get it working. so for now, ProtoPlug is really the best Lua audio/midi plugin IMHO. Loomer Architect is also worth a look too though, but it's $100 for beta version.

Regarding ProtoPlug I spent some time the past few days attempting to build it with JUCE7 and to extend its API since it did not have functions for creation ProgramChange and Aftertouch messages. I was not able to get it to build with JUCE7 yet, maybe I'll come back to that later. I have also decided that I don't like the way he did the lua wrappers around JUCE. Michaael is doing it much more smartly with KushView Element FWIW. The ProtoPlug way involves way too much memory allocation and copying by value of things back and forth between buffers and lua tables, etc. and mixed ways of thinking about things. My honest appraisal about ProtoPlug is that the author had a focus on audio and perhaps instruments, not on midi plugins. IN the case of instruments, midi comes in and doesn't go out and so his simple approach worked fine, but when I attempted midi scripts it became needlessly overly complicated in terms of how to script things in lua.

So my thoughts about ProtoPlug is that it needs some serious refactoring, both in the code simply to make it build under modern version of JUCE using cmake, but also in the lua includes which are the basis for the API...and the API needs to be re-thought out much better. perhaps it needs to be more of a direct wrapper around JUCE MidiMessage and MidiBuffer....that is what Michael did for Kushview Element when it comes out. but ProtoPlug's api needs a lot of work and someone devoted to supporting it.

so as of now I have come to the conclusion, for simple little one off scripts, I will use PlugNScript. The reason is because it is absolutely supported by the developer.

For anything more complicated i will just code it in JUCE/C++.

ProtoPlug - needs work and support. potential if someone actually did that.
Kushview element - not ready yet, but has promise and developer is currently committed
Loomer Architect - still beta but also has promise, somewhat limited to 960PPQN precision
soundigy Midilab - based on protoplug, in theory he would support it, but he really isn't doing much dev on it.

bottom line is that PNS is really the only currently stable and supported audio/midi scripting platform as of today, and actively supported by a well regarded developer with many products on the market and they use PNS internally for their development as well. It's unfortunate that it's bloody angelscript, but I feel that as of today it's the only reliable choice.

the others are works in progress and maybe one will will arise champion lua midi scripter, but its still race on.

Also want to make special note about LogicPro's Scripter, which frankly I think is the best midi scripter on the market today. In every way. Unfortunately it only works in LogicPro and only does MIDi. The others do audio also. But Scripter's APi makes more sense and is easier to use then any of the others. It uses Javascript which I think I prefer over Lua, though Lua is growing on me as I get to know it. It also provides access to some DAW meta information such as articulationID. But anyway, I just want to point out that it's really a great scripter. If my preferred daw. (Dp) had something similar, I would definitely use that instead of messing around with these other alternatives floating around, none of which are really everything we want.

[] Peter:H []

Hey folks ... I'm still not prepared to let Protoplug go.

• I looked into upgrading it to Juce 8: Damn, this seems a bit of a pain as the original author did some weird stuff with custom fonts that is no longer supported from juces side.
  And my update to juce 6 already showed some "tiny" incompatibilities in the integration of Lua.
  Anayways I hope I can find time and motiviation to take look into this.
  Anybody a C++ god and willing to update Protoplug?
• On the success side: I have started to create something like Oscillos Mega Scope: My Use Case is that I want to collect audio data from a number of channels and display them in one view. And as stupid Bitwig is not able to accept multiple Ins PsyScope Pro is not an Option ...
  Therefore I have added LuaSockets to Protoplug and was recently able to pull of TCP Socket based Client code that sends samples and a Server that collects up to 4 inputs. It's still a PoC but it shows the potential.
  LuaSocket would even enable me to send audio data to a outside server ...

The screenshot shows a BDR (red) and CLAP (green) sent to my receiver and displayed there

[] Peter:H []

Just a little update on my attempts to build a beat synced "Multi-in" Oscilloscope on my own.
As you might have followed this thread, I have build a PoC solution for a "multi-in" Oscilloscope based on Protoplug/Lua and LuaSocket. A few programming sessions later this thingy is beat synced and has gone through a bunch of optimizations...

The TCP/IP approach means, that the source channels transmit their sample data via TCP/IP to the receiver side where it is collected and displayed. TCP/IP allows me to run my source channels in the DAW and the receiver side elsewhere ...

And this is what you see here in one of the screenshots: Source Channels is Bitwig and receiver side runs in Tone2 Nanohost which is a standalone progi for VSTs

My Oscillo.png

the 2nd screen is a larger view of the beat synced display showing 2 inputs and the RMS of the tow inputs.

Screenshot 2025-01-01 180831.png

[koalaboy]

Just to note that the recent Renoise 3.5 update includes LUA scripting of phrases, and this is also available in Redux with pass-through of MIDI to the DAW.

[Nebula_Audio]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

Time for some necromancy. So, I have revived protoplug. Here's the new forked repository, it's now available in universal AUv2, CLAP, VST3 and LV2 formats.

https://github.com/subhankardas15071992-cloud/protoplug (https://github.com/subhankardas15071992-cloud/protoplug)

The whole code has been migrated from JUCE 5 to JUCE 8. The library files have been recreated from the scratch because the old ones are no more functional and I also wanted to make protoplug compatible with the new Apple Silicon mac:

This is the first plugin to be revived under my new Nebula Audio Re-Animator Project. Under this project I will be reviving even more abandonware open-source plugins. And rest be assured, all of them will be free. I originally started this thing because I used to use protoplug on my Intel MacBook Air but after upgrading to latest M5 MacBook Air I wasn't able to use it anymore.

Of course if anyone wants to support the Nebula Audio Re-Animator Project they can donate on through this Gumroad link: https://subhankar42.gumroad.com/l/xdmspy (https://subhankar42.gumroad.com/l/xdmspy)

As for protoplug, this is just the beginning. I will be incorporating more features in it to make it evolve even further instead of being relegated to just a revived old plugin.