What is your plugin development testbench / workflow?


#1

Hey boys and girls

Was wondering about one thing: when you develop an audio plugin, what is your workflow really? For example I'd assume its complicated to reload an Audio Unit in my favorite DAW every time I wrote some code and want to check it out with real sound.

Are there any kind of easy testbenches out there? Maybe even one based on JUCE that attaches directly to the JUCE generic layer instead of using any specifc API like VST or AU.

I was kind off surprised to see that JUCE does a great job on scaffolding audio plugins,  but doesnt include a test runner i.e some kind of barebone workbench to see it in action. But maybe that's an idea for a future extension that people would like to have? Would be contributing in that case!

Anyhow, maybe I am just thinking in the completely wrong direction, or I am just using the wrong DAW to start with, or there is just no real necessity for these kind of "fast iterations" between programming to integration and product testing.

So, what do you think, and how are you people exactly doing this? ;)

PS: I know about AU Lab, but lets just assume it doesn't exist here.

EDIT: Maybe there is already a way to integration test plugins in JUCE but I just didn't stumble upon it yet? I am really starting off here and would like to get some advice on how to do some rapid iteration development, thanks for your suggestions all! :)


#2

For plugins, it's very convenient to use the StandaloneFilterWindow class in a separate project. It let's you run the plugin as a standalone application, with some standard audio harness around it, so it's very convenient to do all short-iteration-development in this project and then build the plugin project for actual plugin testing.

It's a pity you have to set this up this yourself when developing plugins. It would be great if the Introjucer created both a plugin project and a standalone project automatically, plus a solution that holds both these projects.


#3

What I do is, in Visual Studio, in the debugging section of the project I'll launch the Juce plugin host with an argument that contains a setup with my plugin plus maybe a synth to test input. All you have to do is ensure the latest version of your plugin dll is visable to the plugin host. So once you hit debug, it should launch the plugin host and have your plugin running straight away.


#4

I think Plugin Host is exactly what I looked for and would have built if it didn't exist yet. Thanks a lot for the pointer!


#5

Thanks for that advice, but actually I spent a lot of time getting my head around this issue, with little succes:

http://www.juce.com/forum/topic/build-errors-if-i-add-audiopluginclient-module

In fact I totally understand the plugin has to be scaffolded in a seperate type of project setup that isn't compatible with one that would build an GUI application. So I built a GUI project and initialized the StandaloneFilterWindow in it. But then there wasn't really any clean way to reference the plugin code directly i.e link to it from the app (meaning implementing/linking/pointing to the createPluginFilter() function).

The problem is that in OSX you cant link to what the plugin project outputs: a component (that is slightly something different than just a library). You'd have to load and access that dynamically and even generically (you'd access the functions/objects by name and stuff, no header files involved, kinda like in dynamic typed languages). Anyway. Then again I could have created a second target on the plugin project that produces a static library from exactly the same source files and resources and config and so on, but that would have missed the whole point of having scaffolding right? Because I couldn't just kind copy/paste the component target and make it a static lib, you d have to enter *all* the config by hand.

Last option was: just compile the plugin code directly into the app and hope the linker is gonna be flexible on the interpretation of the word *extern* when looking at the prototype of createPluginFilter() in the StandaloneFilterWindow header. But actually it didnt even get that far because if I'd include the PluginProcessor.cpp into my app main.cpp, the whole config of the two scaffolded JUCE projects would totally clash. I'd have to decouple the AudioProcessor implementation from the project first in a way that I could use it in several projects at once.

All in all, I found that not very straight forward. 

Maybe I got something wrong here. How the *%$ do you manage to use that StandaloneFilterWindow with your plugins exactly? Or are you just on Windows and can simply link to the DLL which is produced by the plugin project? ;)

Anyhow I am happy with using Plugin Host app from JUCE extras, its *exactly* what I was looking for! But just out of curiosity I'd like to know how you solved this.

Thanks for the help! :)

 


#6

I create a parallel project with a stand alone app. It does accelerate iteration rounds as I just press CMD-R to run, set breakpoints easily, no need for an AWS or host.


#7

Majority of my development I use the JUCE Plugin Host. I also wrote a few plugins to use with the plugin I’m currently working on available here https://socalabs.com/developer-tools/

For an effect, it’s usually signal generator -> my plugin -> oscilloscope -> spectrum analyzer -> audio out. For a synth, I replace the tone generator with the midi in.

I’m planning to write a midi looper and an audio looper so I can have consistent input to my plugin while I’m testing. Just haven’t gotten around to it yet.

ABTester is useful once I get the plugin finished and want to start optimizing to make sure I don’t break anything. ChannelMute is useful to hear what the left and right are doing without having to disconnect cables.