Its just an idea I'm trying to grasp: decompiling several free plugins, 3 or 4 of them, and recompiling them into a single channel strip VST and new GUI, but keeping all the original controls available. How easy should it be to work the (rather cryptic) decompiled code into a new GUI?

This would be just an exercise for a newcomer to get into the reverse engineering and plugin building stuff. Bonuses would be being able to bypass parts of the new unified VST, and being able to route them differently. How advanced is this project and you have any guidance on where to start?

Peace,

I'm a noob yes, thanks for nothing if you just came to weigh down on the idea...

 

Not easy unless you are familiar with the code itself or very experienced at it. Let us put it this way, you are better off starting from scratch and coding your own channel strip. For someone who is inexperienced learning C++ will be faster and dont forget JUCE https://docs.juce.com/master/tutorial_create_projucer_basic_plugin.html

 

Last edited: Aug 29, 2019

Start with Plogue Bidule. If that works for you move on to Reaktor, learn C++ to world class contractor standard and study DSP to an MSc degree level or better.

Alternatively stick with Plogue Bidule.

Oh yes and get a degree in graphic design.

 

Last edited by a moderator: Aug 29, 2019

It's nearly impossible.

You cannot decompile most of executables and get their exact code, all decompilers reconstruct original code with errors or partially. In particular, it's very probable that you could't recompile the decompiled code. May be, yes, may be... But decompilation is useful, you can explore algorhithms in a high level programming language (like C, not in assembly), comprehend their logic and write your own code (or change the code of an original executable).

Any plugin (in most cases) makes all the things needed to be executed properly (graphics, audio processing, interaction with a user etc.), sometimes they expose the GUI part to a host (DAW). Every plugin must expose function calls to a host (DAW) it interacts with. A single plugins must have all the instruction for such things. In different plugins these instruction are different (they use their own copies of these instructions, and they can differ as developers often use different frameworks, different programming languages, different compilers). It's absolutely needed but almost imposiible to reasign these operations to a single set of instructions. You have to rewrite almost all the plugins from scratch.

Decompiling, recompiling... It's not like just zipping and unzipping.

If you really need something similar, try this:
http://my.nyrvsystems.com/store/product/1
But it seems abandonware, no updates since 2016.

 

Last edited: Aug 29, 2019

That's sort of true. There are very, very few publicly available decompilers that can do much more than recover assembler level machine code constructs. So you don't get C++ code, you get mostly Assembler.



Assembler is the MOV, PUSH, SUB code between the original C++. Going from C++ to Assembler is easy, coming back the other way around is next to impossible. I used to be a Motorla 68000 Assembly coder. Steppenwolf. Born To Compile. Been there, done that, never going back.

Honestly, Plogue bidule will give you what you want.

 

If you have SOURCE CODE for the free plugs, from the SAME developer & SAME era, that may be possible.

But for starters, you can try making custom channel strips via

• Reaper Native https://www.soundonsound.com/techniques/reaper-creating-custom-channel-strip
• 3d pty solution https://forum.cockos.com/showthread.php?t=182233&page=153
• via JSFX

PS: you need Reaper

 

A lot, very hard. Especially if you want to add a GUI.

There are the scripted JSFX plugins well pointed by @junh1024, and the modular ones like Bidule/MUX.
If we talk about C++, the best quality open source plugins are the Air Windows ones (https://github.com/airwindows/airwindows).

They' don't have GUI, but that's a good thing if you want to "mix" them. It saves you the time to decouple the GUI code from the DSP code.

Framework to use: JUCE, no question.

Edited: and as others have said, decompiling is not an option. That's hacker level madness and you'll need to know assembler and have shitloads of time.

 

Last edited: Aug 29, 2019

Yeah, i see. So it is way above my level, better to code my own from scratch huh. Even if decompiling gets out of the way? For once: since I want to get the same functionality from the original plugins, couldn't I use some sort of .vst host (I might be able to code it myself) to run them in the background of a new GUI, without compiling an unified VST?

The response was on point anyway. I'm not from the tech background in any sense, I can only do some max msp and supercollider, better get C++ expertise first.\

 

Commodore Amiga days right there! 6502 and 8088 as well!

This is what Nyrv would do as I recall:

 

Yes. And it is available at sister site thanks to r2r.

 

And i'm thankful for that. Unfortunately it is far away from the original vision, but of course that is the price of not knowing how to do it myself. That is it, for me the issue is solved: gotta get deeper into C++ to bring it to life.

If anyone wants to continue the debate, feel free, i'm leaving the topic.



Thanks folks.
Much respect for the knowledge.

 

Those were the days!!!

At last we can start with silly rude jokes!!!! Yaiii

 

Airwindows has some things which are helpful to gain patreon followers but not for development/use e.g,

• 80bit > 64 dithering sounds impressive, but 1000dB of clipping headroom, anyone?
• 100+ plugs sounds impressive, but: who needs 10 dithers? 3 compressors? 10 channel strips (I assume)?

I'd like to suggest an alternative: MDA VST: https://sourceforge.net/projects/mda-vst/
Yes the coding style is a bit oldskool. But, it has been PROVEN to be useful and modificable because:

• REAPER includes pseudo stereo, which is based on mda-stereo
• I've modified mda-dither to be surround compatible (but not released)

 

That's very cool, the same VST SDK includes MDA plugins as examples. The MDA plugins were free but closed source, that means you didn't get the source code at all. They opened the source code because they stopped the development 4 years ago. Also, they use Visual C 6 (1998 I think) C++, only compatible with Microsoft Windows Visual C 6 compiler and above, not standard C++. I wonder what C++ uses Air Windows... I think it's also old, but no so much...

Reaper includes many things, almost all of them improved and adapted DIY-style by Frankel and company. The FFT is based in a 1996 source code developed for Sun UNIX Workstations. JSFX language (Reaper's EEL2) is based on some arcane EEL language, Frankel took it at a basis and completely outperformed the original. What I'm saying is that "modifiable" and "modifiable by Frankel and company" are two completely different worlds.

I'm not saying you've to look all Air Windows plugins, the same author explains them and says most of them are experimental or plainly weird.

But there're a few that are great and very helpful. They actually sound impressive. Guitar conditioner, a Hass-like effect,... a lot.
They're open-source because the author got rid of the painful GUI creation when he coded commercial plugins and he focuses on the sound only now.

Personally, I don't care at all if the coding style is old. If it sounds good that's all. But if I had to start a plugin based on an existing codebase, I'd look first into Air Windows code. Because the DSP algorithms in some uses have actually improved.

Matter of taste and mindset, though, I'd love to test your plugin BTW. Kudos for that work.

 

Last edited: Aug 31, 2019

Yes, you're right. But what you mean is a DISASSEMBLER. The decompiler decompiles, the disassembler makes disassembly. The decompiled code is a code in a higher level language (C, C++ etc.), the disassembly is a code in an assembly language, low level language (not machine language but near to it). And only the disassembly is accurate enough (if no tricky copy protection is involved).

 

I think, yes. It seems to be the way NYRV Agent works. This is a plugin which loads other plugins, doesn't show their GUI, instead of them shows their own controls associated to parameters of loaded plugins and then controls parameters of loaded plugins via automation (or, may be, there is a different way to control parameters, I don't know). You can select parameters that will be mapped on your GUI. It's not an easy goal but this goal is realistic and it's absolutely possible.

 

Last edited: Sep 1, 2019

why not just use Bluecat Patchwork ?


speaking of coding, you can perhaps start with Reaper and JS(FX) to code custom plugins first and THEN try merge them into one?

 

A decompiler is a computer program that takes an executable file as input, and attempts to create a high level source file which can be recompiled successfully. It is therefore the opposite of a compiler, which takes a source file and makes an executable. Decompilers are usually unable to perfectly reconstruct the original source code, and as such, will frequently produce obfuscated code. Nonetheless, decompilers remain an important tool in the reverse engineering of computer software.

https://en.wikipedia.org/wiki/Decompiler

There are very, very few decompilers that can produce anything more than richly labeled disassembly, which is the point I was attempting to make. The notion that you can go from machine code to C++ is bordering on the insane. Simply identifying a table of pointers as the virtual table of a C++ object's methods, is itself almost impossible if the original compiler does not embed symbolic data, which is then included in the shipped executable. All you ever get from decompilation is rich assembly. You almost never get high level code with either C or C++. It has as much to do with the desire of competing software developers to obfuscate their code one from another as with the sheer complexity of the task proposed.

 

You're absolutely right. But what you call "decompiler" is a disassembler. Program that isn't able to decompile but is able to make disassembly. Why do we have to call "decompiler" a program that can't decompile at all? Decompiler is for decompilation, disassembler is for disassembling. If we can't get code (at least partly) in a higher level language it's not a decompilation. Assembly isn't a high level language.

I don't understand something?

https://en.wikipedia.org/wiki/Disassembler

 

Commodore Amiga days right there! 6502 and 8088 as well!

+1

For me it was an Apple ][+ for the 6502 and a Z80A add on card to run CP/M

 

Last edited: Sep 1, 2019