Site navigation

CMake based plugin not showing up in Logic 9 and Garage Band 10.3 although working in Logic Pro X and auval passes

Audio Plugins
#1

I got some feedback from a user that my plugin does not show up in Logic 9 and Garage Band 10.3 but works with Ableton Live and passes auval without errors on his system.

I tested the plugin with Logic Pro X myself but was able to reproduce it with Garage Band 10.3 on my own system. Funny enough, I got a mail from another customer last week telling me that the plugin works great in Garage Band – he didn’t specify a version though, it’s possible that it was running under an older version of garage band.

Does this ring a bell to someone? The plugin is mono in/out only, is it possible that recent versions of Garage Band don’t accept mono-only AU plugins for some reasons?

#2

Possibly: CMake iLok GarageBand

Rail

#3

Don’t think this is the culprit.
I had the same return regarding Logic 9 on project using the new juce cmake.

#4

As this is no iLok protected plugin, I’m not sure if the issue linked by @railjonrogut could really be related, seems a bit to iLok specific to me.

@otristan I’m using CMake as well, this issue refers to my open source plugin by the way, so you can find the sources here. Do you have e.g. a previous version not built with CMake that worked, so that you come to the conclusion that this might be a CMake issue?

#5

I have other project using my own plugin wrapper that works with Logic 9
and the last two uses juce own plugin wrapper and cmake and I had report they fail in Logic 9.
Works fine in GB though but I had to disable the resourceUsage thing because of iLok protection.

So not sure this is 100% related but this gives me a hint toward this.

#6

I had a quick look at your project. I could get it to pass auval with no issues, but was unable to load the plugin in Garageband 10.3.5, like you.

When running auval -a I noticed that your plugin was the only plugin with an all-upper-case plugin code. When I changed the plugin code from SOJD to Sojd, I was able to see the plugin inside GarageBand, although when I tried to load it, I got the following error:

The Audio Unit “OJD” could not be loaded for your project, and may need to be updated.
Contact the manufacturer for an updated version or further assistance.

I adjusted isBusesLayoutSupported to report that stereo configurations were supported too, and after that I was able to load the plugin in GarageBand.

2 Likes
#7

@reuk can you maybe add at some point a way to force AU detection using

add_custom_command(
        TARGET ${target} 
        POST_BUILD
        COMMAND killall -9 AudioComponentRegistrar
    )
#8

Wow, thank you very much @reuk for looking into that in such a detailed way, really appreciate the effort you put into supporting us here on the forum.

I planed to add stereo support for the next update anyway, so this part of the problem should be solved through that automatically. However, I assume changing the plugin code will mean that it would break DAW sessions worked with the current version, right? :neutral_face:

#9

I’m not sure - I think there’s a good chance this will vary between hosts. I was able to save a REAPER project containing a Sojd version of the plugin, overwrite the plugin with a SOJD version, and reload the project successfully. However, other hosts may behave differently, so I’d recommend running your own tests.

#10

Ok, thanks for checking that out as well. I’ll do my own tests, of course, and hearing that Reaper works is already a great thing, if the other two main AU hosts Logic and Ableton Live are not affected too, I guess I’ll definetively change it. Will keep you updated on the results!

#11

Just wonder why it does not work with the upper case code while it worked in the past? Is this a bug in the CMake code? I also need to migrate existing plugins to cmake. I dont think changing the plugin code is a safe solution.

#12

AFAICS, changing the plugin code means changing JucePlugin_PluginCode, which means changing JucePlugin_AUSubType (because JucePlugin_AUSubType is defined as JucePlugin_PluginCode), which is used in juce_AU_Wrapper.mm and juce_audio_plugin_client_AU.r as “component subtype”.

However, according to the (maybe quite outdated) Audio Unit Programming Guide (https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/AudioUnitDevelopmentFundamentals/AudioUnitDevelopmentFundamentals.html), that “component subtype” doesn’t matter much:

However, host applications make no assumptions about your audio unit based on its subtype. You are free to use any subtype code, including subtypes named with only lowercase letters.

And according to up-to-date documentation (https://developer.apple.com/documentation/audiotoolbox/audiocomponentdescription/1410467-componentsubtype), it can be whatever one wants:

A 4-byte code that you can use to indicate the purpose of a component. For example, you could use lpas or lowp as a mnemonic indication that an audio unit is a low-pass filter.

So the reason why that plugin is (not) being loaded might be something else completely.

1 Like
#13

I just noticed the documentation changes for this issue in the juce 6.0.5 commit f2e0552.

This affects us, too. We have both our plugin codes and manufacturer code in all uppercase letters. I wonder what Apple was thinking here - we can’t just change these, it would break all our user projects. Has anyone found a solution to this?

Just thinking out loud - if AU doesn’t care about these codes changing from all uppercase (e.g. ABCD) to the required format (e.g. Abcd) maybe we could hack Projucer or the AU wrapper code to make this change automatically? That way we could leave VST2, VST3, AAX etc. untouched.