Development environment on Mac - how do you organise yours?
-
- KVRer
- Topic Starter
- 14 posts since 19 Jun, 2013 from London, UK
I've recently managed to get my first AudioUnit project together, using a mish-mash of sample code and online tutorials to get it up and running on Xcode 5. 90% of the time writing the plugin was getting the project set up, making sure it was recognised by AU Lab (and Logic) etc. with about 10% dedicated to functionality (it was a delay unit with a few operations applied to the delayed signal). And I know that Xcode 6 is probably going to break something, and Apple hasn't given us AU templates since long before I started trying to make them.
Now that I've got that set up, I'd love to be able to make a few more effects while learning all about DSP. However, the time it takes to actually set up the project again is daunting. I've noticed that many of you create plugins that are cross-platform (Windows/Mac) and support both VST and AU. I was wondering how you go about organising projects like that - do you have a core Git repo for setting up a project template? What kind of build system do you have in place? Do you have a project setup script that creates Xcode/VS projects ready to build out of the box? I'm asking mostly about Mac/AU (that's what I'm using) but any advice about setups would be welcome.
Now that I've got that set up, I'd love to be able to make a few more effects while learning all about DSP. However, the time it takes to actually set up the project again is daunting. I've noticed that many of you create plugins that are cross-platform (Windows/Mac) and support both VST and AU. I was wondering how you go about organising projects like that - do you have a core Git repo for setting up a project template? What kind of build system do you have in place? Do you have a project setup script that creates Xcode/VS projects ready to build out of the box? I'm asking mostly about Mac/AU (that's what I'm using) but any advice about setups would be welcome.
- KVRian
- 1169 posts since 24 Feb, 2012
Have a look at https://github.com/olilarkin/wdl-ol or http://www.juce.com/
JUCE features JUCER, an IDE for IDEs if you want. Afaik, Iplug solves this IDE mess via a collection batch scripts.
JUCE features JUCER, an IDE for IDEs if you want. Afaik, Iplug solves this IDE mess via a collection batch scripts.
Fabien from Tokyo Dawn Records
Check out my audio processors over at the Tokyo Dawn Labs!
Check out my audio processors over at the Tokyo Dawn Labs!
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
I agree, those frameworks provide the necessary files to handle OS X (and Windows) plugins, with the proper projects (you can use Xcode to develop, test, and then the batch scripts to create AU, VST... plugins in the case of WDL-OL)
-
- KVRer
- Topic Starter
- 14 posts since 19 Jun, 2013 from London, UK
Thanks, I've used JUCE but was put off by the license and how much I needed to rely on their libraries. WDL-OL looks promising.
Other than that, are there any DSP-specific project management techniques that would be good to know about? One thing I've noticed about DSP from ~10 years experience of programming (~4 professionally) is that the development/debugging process is drastically different from anything else I've done and I've got no idea what kind of attitude to approach it with, if that makes sense...
Other than that, are there any DSP-specific project management techniques that would be good to know about? One thing I've noticed about DSP from ~10 years experience of programming (~4 professionally) is that the development/debugging process is drastically different from anything else I've done and I've got no idea what kind of attitude to approach it with, if that makes sense...
- KVRian
- 1169 posts since 24 Feb, 2012
Debug wise, I tend to use VSTPluginAnalyser and Reaper most of the time.
It's well worth developing your own DSP lib in a test-driven manner. This greatly reduces the need for debugging during final product implementation.
Math toolkits such as Mathlab or Scilab can be a great help for first basic proof of concepts. Scilab is open source, which allows checking out how they built their modules.
On a side note, JUCE isn't particularly strict. In contrary, it probably the cleanest and most reasonable C++ lib I've found to date, really. IMHO, the 800 pounds for the commercial license are a good investment, you can't imaging how much time JUCE (and the introjucer) will give you in return!
It's well worth developing your own DSP lib in a test-driven manner. This greatly reduces the need for debugging during final product implementation.
Math toolkits such as Mathlab or Scilab can be a great help for first basic proof of concepts. Scilab is open source, which allows checking out how they built their modules.
On a side note, JUCE isn't particularly strict. In contrary, it probably the cleanest and most reasonable C++ lib I've found to date, really. IMHO, the 800 pounds for the commercial license are a good investment, you can't imaging how much time JUCE (and the introjucer) will give you in return!
Fabien from Tokyo Dawn Records
Check out my audio processors over at the Tokyo Dawn Labs!
Check out my audio processors over at the Tokyo Dawn Labs!
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
I don't think that signal processing development is really different than scientific computing, but it is different than usual IT development. But if you write tests and have a proper test framework, it is easier. In my case, I have unit tests for basic functionality, and Python scripts before integration in actual plugins (and with WDL-OL, the most work is actually the GUI). I have everything on github if you want to check: https://github.com/mbrucher/AudioTK