COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :
Old 08-20-2019, 07:06 AM   #1
DKDiveDude
Human being with feelings
 
DKDiveDude's Avatar
 
Join Date: Mar 2015
Location: North Carolina
Posts: 194
Default Why iPlug 2 and not RackAfx or Juce?

I have been programming computer code for 36 years, from Basic, Pascal, C, Javascript, Java, to C++ and Assembly Language. I have some thoughts on a completely unique approach to a subtractive synthesizer, would I would love to use and release as a VST (or VST2 or VST3) instrument. Secondary I could perhaps be interested in releasing it in other formats (AU and AAX), and to a lesser degree as a stand-alone instrument.

I would love a framework that would make the work easier for me, as for example with tools that would let me easily add graphic elements, quickly compile and test, so I can focus on the DSP math. However my primary concern would be one that has the absolute fastest DSP processing, if there is much of a difference, as my ideas would need a lot of calculations.

Right now I have been tinkering around with RackAFX since yesterday, which was my very first day trying to get familiar with some simple DSP code, but before I get to involved with RackAFX I have one to me concerned question.

Would someone please explain to me why I should choose to work and create using iPlug 2, instead of for example RackAFX or JUCE? Please again keep in mind that main primary concern is a framework that allows for the absolute fastest DSP code.
__________________
Divers works best under pressure!
DKDiveDude is offline   Reply With Quote
Old 08-20-2019, 07:42 AM   #2
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by DKDiveDude View Post
let me easily add graphic elements, quickly compile and test

...

main primary concern is a framework that allows for the absolute fastest DSP code.
Easy graphics isn't going to happen with IPlug or Juce. You will be spending the bulk of your development time dealing with GUI issues. IPlug doesn't have that many ready to use GUI controls. While Juce has more and more customizable GUI controls, you can easily end up having issues with graphics performance.

Both IPlug and Juce require you to do your GUIs with code, there are no fancy visual GUI designers. (The GUI designer in Juce is obsolete and has been left in the Projucer to support legacy projects.)

Quick compilation and testing is not going to happen when you are using C++.

I recall that RackAfx has been frowned upon because it doesn't allow you to write the most optimized DSP code. That may have been fixed in later versions or there may be some way to bypass the performance limitations. You'd need to investigate carefully what the situation is currently with that.

Based on my current understanding I would rank the well known plugin frameworks as follows :

-Juce. While I personally consider it the "best", it has the major disadvantage that the licensing model may not be suitable for everyone. If you want to release closed source plugins, you will need to pay for it or use their peculiar licensing option that requires you to show a splash screen and allow sending information to their internet servers from the user's computer. No limitations how you can write your DSP. Doesn't have the best graphics performance, but can usually be dealt with some effort.

-IPlug. The old IPlug is as far as I know deprecated and IPlug2 isn't yet "production ready". No limitations how you can write your DSP. May require quite a lot of work to get a GUI on screen. (This was the case with at least the old IPlug, there wasn't even ready to use slider or knob controls, you needed to get bitmaps from somewhere to get the slider or knob on the screen.)

-Steinberg's VST SDK and VSTGUI. I haven't tried this for years, but it might be decent enough. No limitations how you can write your DSP.

-RackAfx. My understanding is that it isn't widely used due to issues in how the DSP needs to be written. It is considered more like a tutorial framework before you move to something else.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

Last edited by Xenakios; 08-20-2019 at 08:11 AM.
Xenakios is offline   Reply With Quote
Old 08-20-2019, 07:57 AM   #3
DKDiveDude
Human being with feelings
 
DKDiveDude's Avatar
 
Join Date: Mar 2015
Location: North Carolina
Posts: 194
Default

Quote:
Originally Posted by Xenakios View Post
Easy graphics isn't going to happen with IPlug or Juce. You will be spending the bulk of your development time dealing with GUI issues. IPlug doesn't have that many ready to use GUI controls. While Juce has more and more customizable GUI controls, you easily end up having issues with graphics performance. Both IPlug and Juce require you to do your GUIs with code, there are no fancy visual GUI designers. (The GUI designer in Juce is obsolete and has been left in the Projucer to support legacy projects.)

Quick compilation and testing is not going to happen when you are using C++.

I recall that RackAfx has been frowned upon because it doesn't allow you to write the most optimized DSP code. That may have been fixed in later versions or there may be some way to bypass the performance limitations.
Thank you for that answer. It did make me question how RackAFX would not allow me to write the most optimized code, as I thought in all of the above frameworks I could use my own, that is the exact same DSP C++ code?
__________________
Divers works best under pressure!
DKDiveDude is offline   Reply With Quote
Old 08-20-2019, 08:23 AM   #4
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by DKDiveDude View Post
It did make me question how RackAFX would not allow me to write the most optimized code, as I thought in all of the above frameworks I could use my own, that is the exact same DSP C++ code?
RackAfx may have been implemented for example so that sample-per-sample processing needs to be used everywhere. This can become a problem when virtual methods or function pointers are involved, the compiler isn't usually able to optimize the code properly in those cases. IPlug, Juce and others do use virtual methods for the audio processing but the audio is processed in larger buffers instead of sample-by-sample, so the virtual method call overhead doesn't matter that much. The code inside the audio processing methods may further be optimized because it involves looping through the samples. (So the compiler may be able to figure out various optimizations itself or it may be possible to manually write SIMD code for the processing loops.)

The above is just speculation on my part and I am actually now a bit curious to see myself what exactly has been considered as the problem in RackAfx...Maybe there are some publicly available code examples?

edit :

If RackAfx allows you to write your DSP into a function similar to the following, you should be good to go as far as optimizations go :
Code:
void MyPlugin::processAudio(float** inbuffers, float** outbuffers, int numFrames) {}
In Juce it is :
Code:
void MyPlugin::processBlock(AudioBuffer<float>& buffer, MidiBuffer& midiMessages)
In IPlug :
Code:
void MyPlugin::ProcessDoubleReplacing(double** inputs, double** outputs, int nFrames)
There are some other variants of it possible, but the important point is that you get to process whole buffers at once.

RackAfx is by the way deprecated by its author. He has made a new framework.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

Last edited by Xenakios; 08-20-2019 at 10:01 AM.
Xenakios is offline   Reply With Quote
Old 08-20-2019, 03:19 PM   #5
AHarker
Human being with feelings
 
Join Date: Jul 2010
Posts: 21
Default

I advise you to give each of them a quick try to get a feel for how they work for you. Ultimately if you are writing your own C++ DSP code then the limitation for that is with you. iPlug 2 would certainly allow you to do that.

iPlug 2 is designed with a few things in mind - firstly so that you write minimal code to get your plugin up and running - and certainly to start with you can concentrate on DSP and parameters only (that is something that was the case also in iPlug 1). The second relevant item is iPlug2 is *very* different to iPlug 1 in terms of graphics - full vector graphics support and a concentration on speed (depending on what backend you choose).

Quote:
Originally Posted by Xenakios View Post
Easy graphics isn't going to happen with IPlug or Juce. You will be spending the bulk of your development time dealing with GUI issues. IPlug doesn't have that many ready to use GUI controls.....

-IPlug. The old IPlug is as far as I know deprecated and IPlug2 isn't yet "production ready". ... May require quite a lot of work to get a GUI on screen. (This was the case with at least the old IPlug, there wasn't even ready to use slider or knob controls, you needed to get bitmaps from somewhere to get the slider or knob on the screen.)
I'd like to point out several things here. There is no need to spend most of your time on GUI - that will depend on your plugin -you can even use the host provided egg-slider GUI without writing any code. iPlug 2 also has quite a few provided vector controls - you no longer have to use bitmaps. Xenakios - it doesn't sound like you've tried out iPlug 2 but hopefully you'll find things are quite a bit different now.

Ultimately these three things are trying to provide different things. JUCE comes with a lot of stuff, but with that you get a lot of DSP libraries (and other kinds of libraries) that you might have no useful and a whole ecosystem to deal with - on the other hand you can build complex apps with it. I have no experience of RackAfx expect reading about it, but some differences have been pointed out here. iPlug 2 aims to be relatively lightweight, permissively licensed and deploys to a wide range of options (including WAMS or web audio modules).

It's impossible to say which one will fit you best. JUCE or iPlug will let you write all your own DSP code and that should run the same in either. If you need lots of DSP library bits JUCE has more. If you want something that just makes the plugin side of things easier then iPlug 2 is worth considering. You can just clone the GitHub repo and try compiling the examples.

Alex (full disclosure - one of the devs on iPlug 2)
AHarker is offline   Reply With Quote
Old 08-20-2019, 03:44 PM   #6
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by AHarker View Post
There is no need to spend most of your time on GUI - that will depend on your plugin -you can even use the host provided egg-slider GUI without writing any code. iPlug 2 also has quite a few provided vector controls - you no longer have to use bitmaps. Xenakios - it doesn't sound like you've tried out iPlug 2 but hopefully you'll find things are quite a bit different now.
Obviously, the GUI doesn't need to require much or even any work. But at some point people will always want something custom and fancy and then the problems can begin.

Yeah, that's right, I haven't so far tried out IPlug2 because it looks like external dependencies are involved. I absolutely hate dealing with building external dependencies or trying to use ready-built .lib files of those. Is there a way to use IPlug2 in a way that doesn't require those dependencies and yet allows doing something useful with the GUI/graphics?

I didn't mean to trash to IPlug(2) or RackAfx in particular. I am also critical of Juce, it has lately become a growing problem for me that it's so easy to end up using so much CPU with it for the GUI.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 08-21-2019, 03:29 AM   #7
AHarker
Human being with feelings
 
Join Date: Jul 2010
Posts: 21
Default

By default I don't think any external dependencies are involved (they are included in the repo for the default settings) but that assumes you use NanoVG for the graphics. Of course you need the relevant plugin SDKs (as before) but you can certainly build in some form (app or AU) without any additional materials at all to get started.

For other graphics backends you require the dependencies, but Oli has uploaded pre-made builds of these and I'm not aware of anyone haiving significant issues using them. We also spend quite a while making build scripts to build them on your computer if you prefer, but I've stopped doing that because there is no need, and I'm able to build on Mac/windows without every thinking much about that.

You are welcome to give feedback on it if you try it and find it too much hassle, but I'd hope you'd find it pretty straightforward to at least get the examples up and running.

Quote:
Originally Posted by Xenakios View Post
I didn't mean to trash to IPlug(2) or RackAfx in particular.
I didn't take it as trashing :-) - I just wanted to point out that the comments about a lack of built in graphical controls are no longer true for iPlug 2. And yes, people often want fancy graphics, but that is up to the developer - there is a base set of vector controls that looks quite nice and at least allow you to delay GUI design until you get to that point.
AHarker is offline   Reply With Quote
Old 08-21-2019, 03:36 AM   #8
AHarker
Human being with feelings
 
Join Date: Jul 2010
Posts: 21
Default

FWIW you can view some of the default vector controls on this web example:

https://iplug2.github.io/NANOVG/IPlugControls/

Anything starting IB is a bitmap control. IV is vector drawn and there's one drawn from an SVG also.

This uses webgl for the drawing. You might need to be on chrome or safari for it to work, and you need to hit the "Start web audio!" button to see the GUI.

Alex
AHarker is offline   Reply With Quote
Old 08-21-2019, 06:24 AM   #9
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by AHarker View Post
I just wanted to point out that the comments about a lack of built in graphical controls are no longer true for iPlug 2.
Point taken, IPlug2 seems much more easy to start using than IPlug1 did as far as the GUI controls go. I was able to build the basic effect example with Visual Studio 2017 without too much hassle. Maybe I'll look if I try doing some test project of my own too...
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 08-21-2019, 06:50 AM   #10
DKDiveDude
Human being with feelings
 
DKDiveDude's Avatar
 
Join Date: Mar 2015
Location: North Carolina
Posts: 194
Default

Quote:
Originally Posted by AHarker View Post
I advise you to give each of them a quick try to get a feel for how they work for you. Ultimately if you are writing your own C++ DSP code then the limitation for that is with you. iPlug 2 would certainly allow you to do that.

iPlug 2 is designed with a few things in mind - firstly so that you write minimal code to get your plugin up and running - and certainly to start with you can concentrate on DSP and parameters only (that is something that was the case also in iPlug 1). The second relevant item is iPlug2 is *very* different to iPlug 1 in terms of graphics - full vector graphics support and a concentration on speed (depending on what backend you choose).



I'd like to point out several things here. There is no need to spend most of your time on GUI - that will depend on your plugin -you can even use the host provided egg-slider GUI without writing any code. iPlug 2 also has quite a few provided vector controls - you no longer have to use bitmaps. Xenakios - it doesn't sound like you've tried out iPlug 2 but hopefully you'll find things are quite a bit different now.

Ultimately these three things are trying to provide different things. JUCE comes with a lot of stuff, but with that you get a lot of DSP libraries (and other kinds of libraries) that you might have no useful and a whole ecosystem to deal with - on the other hand you can build complex apps with it. I have no experience of RackAfx expect reading about it, but some differences have been pointed out here. iPlug 2 aims to be relatively lightweight, permissively licensed and deploys to a wide range of options (including WAMS or web audio modules).

It's impossible to say which one will fit you best. JUCE or iPlug will let you write all your own DSP code and that should run the same in either. If you need lots of DSP library bits JUCE has more. If you want something that just makes the plugin side of things easier then iPlug 2 is worth considering. You can just clone the GitHub repo and try compiling the examples.

Alex (full disclosure - one of the devs on iPlug 2)
Thank you very much for that answer. I have downloaded your framework files via github, and since I have your attention I want to offer a few comments that might lead to some inspiration from you developers.

1) TrackAFX comes with an application, Windows or Mac. When creating or opening a project it start your C++ coding program and loads the appropriate files. One can very easily insert a wealth of graphic elements and with a click of a button insert the associated code into your project files. With a click of another button, again from within this App, one can click "Build" to compile the project, then click "Load" to test the plugin right from within the App, click "Unload" to return back to development, and repeat. One day when you get a bit of time you might want to check it out for some inspiration. The developer was actually a DSP teacher for many years, and found his students spent most of the time with the GUI instead of coding, which is why he developed TrackAFX.
2) Also the developer has made many tutorial videos.
3) I was quite surprised the iplug2 documentation folder in my unzipped computer folder, did not contain groups, classes, and files documentation. Also that information seemed a bit hidden on github, as at first glance the documentation folder there looked identical to my local one, until near the bottom of the webpage I clicked the link with the text "doxygen version here."

As I understand it VirtualCZ was made with iPlug2, so it must be pretty good. Now if only it had the great Development App like TrackAFX, as that seems very tempting for a beginner in DSP coding like me, who also want to spent most my time coding rather that developing the GUI.
__________________
Divers works best under pressure!
DKDiveDude is offline   Reply With Quote
Old 08-21-2019, 10:29 AM   #11
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by DKDiveDude View Post
Secondary I could perhaps be interested in releasing it in other formats (AU and AAX)...
Am I incorrect that RackAfx does not support AAX? You can export to ASPiK and go from there...
earlevel is offline   Reply With Quote
Old 08-21-2019, 10:52 AM   #12
DKDiveDude
Human being with feelings
 
DKDiveDude's Avatar
 
Join Date: Mar 2015
Location: North Carolina
Posts: 194
Default

Quote:
Originally Posted by earlevel View Post
Am I incorrect that RackAfx does not support AAX? You can export to ASPiK and go from there...
It does support AAX, I just checked in the development application, but strangely it does not seem to mention it on the product web page. It also support exporting to VST2, VST3, and and AU.
__________________
Divers works best under pressure!
DKDiveDude is offline   Reply With Quote
Old 08-21-2019, 06:10 PM   #13
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by DKDiveDude View Post
It does support AAX, I just checked in the development application, but strangely it does not seem to mention it on the product web page. It also support exporting to VST2, VST3, and and AU.
OK. The documentation seems to say that RackAFX7 relies on exporting to ASPiK for AAX/AU/VST3, but I don't know if that means previous support has been removed from RackAFX or what, maybe it's just the new preferred way. I haven't used RackAFX.
earlevel is offline   Reply With Quote
Old 08-22-2019, 09:12 AM   #14
DKDiveDude
Human being with feelings
 
DKDiveDude's Avatar
 
Join Date: Mar 2015
Location: North Carolina
Posts: 194
Default

Quote:
Originally Posted by earlevel View Post
OK. The documentation seems to say that RackAFX7 relies on exporting to ASPiK for AAX/AU/VST3, but I don't know if that means previous support has been removed from RackAFX or what, maybe it's just the new preferred way. I haven't used RackAFX.
I actually have not gone so far with it. I only downloaded it and noted how easy it was to add GUI elements, of which I tested a few.
__________________
Divers works best under pressure!
DKDiveDude is offline   Reply With Quote
Old 08-22-2019, 09:59 AM   #15
AHarker
Human being with feelings
 
Join Date: Jul 2010
Posts: 21
Default

Quote:
Originally Posted by DKDiveDude View Post
1) TrackAFX comes with an application, Windows or Mac..... One can very easily insert a wealth of graphic elements and with a click of a button insert the associated code into your project files....
Interesting to know. I think that is probably a bit beyond the scope of what we have planned at the moment, although I hope that the live edit function will get some attention at some point (build the plugin as an app change to LiveEdit mode (in the debug menu) and you can edit the GUI - although not currently in a way that goes back into your code - I suspect that would be the ultimate goal, but I've not worked on this bit.

Documentation is a work in progress - we know that needs some love ;-)

VirtualCZ was made in iPlug indeed

The Stilwell audio stuff is also iPlug (https://www.stillwellaudio.com)

I've released as part of surrealmachines this plugins (https://www.surrealmachines.com/prod...achines-vstau/)

There's a lengthier thread about what's been made in it in this forum.

Anyway - good luck in your coding whatever route you choose in the end!
AHarker is offline   Reply With Quote
Old 08-23-2019, 05:14 AM   #16
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

there is no significant reason why the DSP processing shouldn't be equally performant in the 3 frameworks you mention*.

AFAIK ASPIK is built on top of the VST3SDK and VSTGUI. I have a lot of respect for Mr Pirkle's work but personally I find the code style extremely verbose. e.g. here is the gain example: https://github.com/willpirkleaudio/A...moVolumePlugin , vs the gain example in iPlug2 https://github.com/iPlug2/iPlug2/tre...es/IPlugEffect

* depending on the precision of values used for audio processing specified by host/plugin format/your code, iplug might do some copying to/from scratch buffers, casting float to double etc. The performance impact of this is likely to be minimal compared to any DSP you do in your own code.
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 08:15 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.