Software construction, tools and goals
A decade ago, the objective was to have a build farm and do continuous integration (on each commit, build the application and run unit tests). Now, the objective is continuous delivery. This means that the new build is directly put into production. All the major applications are doing this, from Chrome to Spotify. You may not get every version on your machine, but you should consider a build as something you could deploy.
The nice thing is that there are tools to ease this workflow.
I started taking a heavier interest in clang-tidy a few months ago, as I was looking at static analyzers. I found at the time that it was quite complicated to work on clang internal AST. It is a wonderful tool, but it is also a very complex one. Thankfully, the cfe-dev mailing list is full of nice people.
I also started my journey in the LLVM/clang land with the help of this blog post.
As some may know, I’ve switched from wdl-ol to JUCE 5 for my free plugins. In the past, I had to modify by hand all the projects created by the Projucer. And each time JUCE is updated, I need to add these changes to the generated project.
Not anymore.
On the develop branch, and in the next minor release ATK 2.1.2, modules for the Projucer will be available. This will enable an easier integration of ATK in your project, as you will “just” need to add these modules to the Projucer (and some additional include files to make ATK compliant with JUCE hierarchy).
There are currently 11 new modules (shameless comparison, that’s far more than the new DSP module, even if there are some filters than I’m missing, but feel free to propose a pull request with new features!).
See the explanation on the release branch and let me know what you think: https://github.com/mbrucher/AudioTK/tree/develop/modules/JUCE
As some may have seen online, ROLI released a new version of JUCE. The nice thing is that they added a new tier for people like me who don’t sell plugins but who don’t want to release their code under the GPL license for diverse reasons (for me, it was formerly incompatibility between VST3 license and the GPL).
With JUCE 5, you have support for all major APIS, from VST2 to Audio Unit v3 and also AAX or VST3. And you can develop your own plugins. The caveat with this tier is that you have a splash screen and a tracking of your users… (actually, there is a flag to remove both). the advantage is that on MacOS, there is no more SDK conflicts, and I have Audio Unit 3 support
So I’ve started playing with Projucer and built a barebone ATK plugin that doesn’t do anything. What I can say is that the worst part is handling universal binaries, support 32bits plugins, as the JUCE project builder overwrites all my changes. Even adding ATK is painful with the project manager.
So instead, I’m going the WDL-OL here, and keeping this ATKJUCE plugin as the simple plugin I’ll duplicate by changing the names and its content. I have my builders that build the plugins and creates the installers, all that while keeping the same JUCE core code (it is shared by all plugins).
The next step is trying to make sense of the API to build a nicer GUI than what I currently have (probably something flat). Indeed, the tutorials on the GUI are small and too basic, but WDL-OL was no better in that aspect, but with more examples.
Sometimes Visual Studio and Xcode projects just get out of hand. The private project I’m working on has 130 subprojects, all in a single solution, that’s just too much to display in one window. And then I learnt that projects can actually be moved to folders, just like what is possible for files in a project (so you don’t have Source Files and Header Files, but something custom, for instance following the file hierarchy).
They are activated differently, and it’s sometimes not as straightforward, but it works great once it is set up. And as this works for Xcode projects and Visual Studio projects, I was really eager to sort out my Audio Toolkit main project, so it will be the basis of the tests here.
A few months ago, I encountered an issue with Scons and the SubstInFile2 tool. When it is used in a variant dir, when the emitter is called, the variant dir is not yet populated. Unfortunately, the emitter tries to open the file in the variant dir, so this does not work.
The only thing to do is to use the source node in the emitter instead of the variant node. So line 112:
keys = subst_keys(str(s.srcnode()))
And this is it!
To ease profiling and testing, I have wrapped the library with SWIG.
I chose Eclipse as my new Linux IDE, instead of Konqueror + KWrite. The purpose was to be able to launch a SCons build from the IDE, get the errors in a panel and double-clicking on one of them would direct me to the location of the error.
So Eclipse seemed to fit my needs:
So I will know show you two ways of enabling SCons support for Eclipse.
Some times ago, I proposed an optional build for SWIG if the SWIG binary was not found on the system. Here I propose an enhancement, a new library builder that will be registered in the environment env as PythonModule. It takes the same arguments as a classical SharedLibrary, but it does some additional steps :
I was looking for some days in SWIG documentation how I could release the GIL (Global Interpreter Lock) with SWIG. There were some macros defined in the generated code, but none was used in any place.
In fact, I just had to enable the thread support with an additional argument (-threads) and now every wrapped function releases the GIL before it is called, but that does not satisfy me. Indeed, some of my wrappers must retain the GIL while they are used (see this item). So here are the features that can be used :
When the whole thread lock is enabled, the GIL is locked when entering the C function (with the macro SWIG_PYTHON_THREAD_BEGIN_BLOCK). Then it is released before the call to the function (with SWIG_PYTHON_THREAD_BEGIN_ALLOW), retained after the end (SWIG_PYTHON_THREAD_END_ALLOW) and finally it is released when exiting the function (SWIG_PYTHON_THREAD_END_BLOCK), after all Python result variables are created and/or modified.