One of the key advantages of having a blog is that it can act like a diary and this is useful for following processes that I need t complete every once in a while. To keep things current, I build my own versions of CTRLRX for Mac Intel and Mac Silicon. For Windows builds, I have to rely on the CTRLRX community and associated releases. This is why I can provide great support for Mac and reasonable support for Windows (with caveats – if something needs fixing – you have to wait on releases from GitHub). I have yet to delve into Linux but CTRLRX will work there too if I ever have the time to work it out.
Anyhow, I went off tangent. For today’s post, I have to remember how to compile AU and VST3 versions of CTRLRX plugins for Intel. I completed a build for the editor but in my wisdom, forgot about the AU and VST3 versions. I created these in June and a lot has happened in that time. Thankfully, I keep notes so will ready through and will update and add to this page.
First off, what can I recall from memory? To fix my current build issue, I plan to retrace my steps (there may be errors).
Well, I remember I need to use a specific version of JUCE and ProJucer. ProJucer and Xcode are the two important bits of software needed to build a version of CTRLRX. We start by downloading an older version of ProJucer from the GitHub. Version 6 is currently sitting around 4 pages in and a link can be found here (link).
Download the CTRLRX project and place it into your Mac home folder.
Unzip the Boost package found under CtrlrX vX_X_XX –> Source –> Misc –> Boost
Opening up ProJucer, and set paths via Global.
- Go to file –> Globals
- Navigate to the source locations inside the JUCE folder, inside the CTRLRX download. CTRLRX download contains all of the necessary build files include the correct version of JUCE.
- In ProJucer, open up the juicer file. For this example, ‘CtrlrX 5.6.33.jucer‘ .
- Select ‘to open the project in’Exporter’ as Xcode.
- Click the bluish icon next to the Xcode selection.
- Change the version number of the output from 10.11 to 10.13 to avoid compile notices.
- Under build, switch from debug to release candidates.
- In XCode, under the projects, select your architectures. I have a build purely for Intel and a build purely for Silicon. It is possible to make this universal but to avoid bloat and for bug fixing, my preference is to split the builds.
- Set you build language as C++ 14 (which is why the earlier version of JUCE is needed – we’re running JUCE 6 which is fine for our purposes).
- Select a valid architecture in Xcode.
- Build your shared code.
- Select the editor version and build.
- Select the AU version and build.
- Select the VST version and build.
- If all is cool – you can just build all for the future. I prefer to check each one for trouble shooting purposes.
- I seem to remember that for build errors, you can delete the build folder and start again.
- I also had to alter the destination for the build.
Well, that’s pretty impressive recall. It will be interesting to see how much of it is correct.
Useful resources:
CTRLRX forum, I used posts from the forum and remember posting a solution, then finding out that someone had already posted s solution (link). I’m going to find my solution to job my memory.
Reading through is interesting, I can see that the VST3 needed a code sign via the terminal which I must have complete for the Silicon version of the TOPD-UF1 exports.
codesign -f -s - _path_to_CtrlrX.vst3_
Synthmania67 experienced the same problem that I’m facing right now. The link can be found here (link).
and Damien’s solution here:
Concerning the cycling problem when compiling, here is the trick, at least on Sonoma :
...setting "Deployment location" to "No" in the build settings. I have no idea what this does, but I was able to build the VST3 successfully...
I’m going to give this a whirl.
Yep, that worked a treat. I now have the AU version built.
While I’m at it, I’ll build a VST3 version. I do not have an Apple Develop account (well, an active paid one currently) for now so not sure if I can code sign it. On that basic, users will either have to trust – or not and either approach is fair.
Okay… now I have a VST3 version build and I’m ready go.