What is your workflow while developing a plugin, since the IDE does not have any kind of GUI output

dee · 2013-09-09 02:24:23 UTC

I am new to juce! and audio developing and i am curiouse how to have a good workflow while developing and debuging a plugin, since i have no display of the plugin in Xcode.

Should i put some kind of post build intructions to copy the builted release from xcode to the final vst / au Folder? and then test on a normal Host? this seems tedious but Is there a mac Host you could recommend for this?

Maybe there might be a project which builds the plugin + a simple host just for this plugin which would be active while the plugin is being developed?

Everything seems very new to me so if you got any tips you could share about this i would be really greatful.

Thank you!

Andrew_J · 2013-09-09 05:09:29 UTC

There's a few ways of achieving this, but one of the easiest is mentioned in the last post here: http://www.juce.com/forum/topic/how-debug-audio-plugin-project

jimc · 2013-09-09 14:52:07 UTC

If you are using Xcode you probably want to use AU LAB.

I followed these instructions when I was starting out:

http://sample-hold.com/2011/11/23/create-a-fft-analyzer-part-iv-debugging-our-audio-unit-with-au-lab/

Also check: http://superuser.com/questions/419449/cant-find-au-lab-on-mac

If you get it set up right it'll automatically load the right plugin, exactly where you left it, and when you hit rebuild AU Lab will quit quickly and restart with your new build all in the right place. If you need more pointers let me know!

cheers, J.

dee · 2013-09-09 16:10:00 UTC

ok thank you! i am looking at it. This might be ridiculous, but if the plugin runs ok in AU Lab, may i assume that it will work well on all the other plugin formats supported by juce?

dee

dee · 2013-09-09 16:30:09 UTC

i am Looking at alternatives to SAVIHost and now looking at AU Lab Also!

Thank you,

dee

jimc · 2013-09-09 17:05:00 UTC

I've had plugins work just fine in AU Lab, but then the same AU format fail in Ableton. I just set Ableton up as the executable to debug, which worked fine (though it's not as quick to load as AU Lab)

dee · 2013-09-09 17:37:00 UTC

I am a completly noob, anyway. Juce Host demo Applications apparently would seems perfect for this!

because, it can load VST and AU, make some flows going in a way you can fully test the plugin in the circunstances you want and save it as something.filtergraph file. The only thing i can't find a way to do is to run the something.filtergraph file and automatically open ith juce host demo with this configuration. It seems to work only from juce host demo and open something.filtergraph from there.

Any points about this?

dee · 2013-09-09 18:06:19 UTC

between thank you for the links :) was really worth and helped me understanding a bit more how to deal with this.

Andrew_J · 2013-09-09 22:43:07 UTC

Sorry about mentioning a windows only solution - I didn't take notice that you mentioned you were using XCode .

I actually use the juce host demo myself. On windows and with Visual Studio I can launch the plugin host and supply a command argument which supplies the full path to the filtergraph file. Hopefully you can do something similar in XCode.

Rail_Jon_Rogut · 2013-09-10 00:55:00 UTC

In XCode Edit the Scheme and in Executable just select the JUCE Host Demo app

Rail

sambecket · 2013-09-10 09:22:06 UTC

For prototyping we have like a "testbed plugin", this is where we test new algos, just fork it and go. And over the design of a plugin we go to many iterations, but i think the main companion of our design is Adobe Fireworks, since we do pixel perfects there, then exports png and set up the x, y w, h coordinates !!

samuel · 2013-09-10 15:10:01 UTC

You can use a StandaloneFilterWindow to embed your plugin in a standalone application without much hassle.

The juce_StandaloneFilterWindow.h can be found in modules/juce_audio_plugin_client/Standalone/ . The idea is to copy this file to your Source folder and modify it if desired.

I maintain two different JUCE projects to develop a plugin:

The first one is a regular plugin project.
The second one is a standalone application (also created with the Introjucer) of the plugin, using the StandaloneFilterWindow.h, which also includes the files of the Source folder of the plugin project. This is the project I use to develop my plugin.

An example of this approach can be found at my metering plugin: https://github.com/klangfreund/LUFSMeter/tree/master/projects