AU wrapper and dynamic plugin name

[Pca]

Hi,

I’m working on a wrapper plugin based on Juce. It’s working fine but I have an issue related to the plugin name using AU interface.

The context: my wrapper is renamed with the regular plugin file name + (CP) suffix (ex: thePlugin.dll => thePlugin(CP).dll). When it is loaded, it opens a companion file (ex: thePlugin.cpd) to get (amongst others) the path to the regular plugin, then load it, instantiate the wrapper code and return to the host. The aim is to add some extra functionalities to a regular plugin.

No problem with VST, my wrapper it totally transparent to the host when I load the (CP) version of the plugin because it is copying the original plugin description before returning to the host. But when I try it using the AU format, I see only one plugin in the host’s list labeled with the default wrapper name, even several ***(CP).component are present in the Plug-Ins/Components folder.

So I guess that my issue is related to the plugin name since it is defined as static information in AppConfig.h (JucePlugin_Name) and used as is by JuceUICreationClass::description, which is a static method… that seems to be called before the plugin is instantiated anyway.

Well… finally I’m searching for a solution allowing my wrapper to return different strings from JuceUICreationClass::description depending on the wrapped plugin. I need to return distinct names, even if they are not the exact name of the original plugin. So my idea is to extract the wrapper file name from within JuceUICreationClass::description since this filename is similar to the original plugin’s name.

Do you have another idea?

If this idea is good, can you tell me how to proceed? I’m definitely not used with ObjectiveC (it’s precisely why I’m using Juce) and I have absolutely no idea on where to find any tip.

Many many thanks in advance!!!

/Phil

[atom]

i have the same issue i also have a wrapper. For vst there is a line you need to change in the wrapper code (i was going to suggest it anyway):

for VST the getEffectName() should be something like (unless it is possible for the filter pointer to be invalid, then a check for that should be added)

bool getEffectName (char* name)
    {
        if (!filter->getName().isEmpty())
            filter->getName().copyToUTF8 (name, 64);
        else
            String (JucePlugin_Name).copyToUTF8 (name, 64);
        return true;
    }

for AU i imagine the method description should be changed to something like (not tested!)

static NSString* description (id, SEL)
        {
            void* pointers[2];
            UInt32 propertySize = sizeof (pointers);
            
            if (AudioProcessor* filter = static_cast <AudioProcessor*> (pointers[0]))
                if (!filter->getName().isEmpty())
                    return [NSString stringWithString: nsStringLiteral (filter->getName().toUTF8())];
            
            return [NSString stringWithString: nsStringLiteral (JucePlugin_Name)];
        }

[Pca]

Yes indeed, I did exactly the same change in the VST getEffectName However I think it is not strictly necessary in my case since the wrapper replicate the wrapped plugin description info, so it inherits the descriptiveName, and finally the host gets the good name. But the change you suggest here makes sense, definitely.

And yes again, it is precisely the AU wrapper’s static description method that should be changed, but I’m still wondering how. Maybe it’s time for me to learn a bit more about ObjectiveC :roll:

[atom]

What i’ve seen so far that each host does this differently. Some work without that change, but for example Reaper does not. Some use the file name to report plugin names, it’s weird.

For AU i found that depending on the version of the host (the older the bigger the problems) the name from the compiled code will be taken but sometimes the name embedded in the .rsrc file is taken, the OSX API does not open the binary and fetches the name from that static file. In the past i used to replace the name in that file. I had to create a special name for the plugin name in Introjucer that would hold enough characters (it’s all static) so later i could search for that name and replace it.

Some people here said that the new AU specification (if there is such a thing) says that the rsrc file is not needed anymore, but i can’t confirm that, i assume that now the name is taken the same way as the VST.

[Pca]

Yep, modifying the wrapper content from my management application is an option that I considered (I have service app for global wrapper upgrading and so on). But I gave up because I am afraid it is not viable because we will certainly soon sign everything redistributable.

The only viable solution must come from within the wrapper plugin… unfortunately…

[msepsis]

ping on this topic… Jules is there any recommended course of action here?

AFIK making the custom change to be able to give a wrapper a unique name will break JUCE when there are updates. This is a bit of a bummer as some users would like to be able to develop AUs or VSTs with things like CTRLR which uses the JUCE libraries. The problem is that any exported instance of a VST or AU is always named “CTRLR” in the host, which becomes problematic when our custom developed AU/VSTs are not called “CTRLR”… which is every case. How can users tell the difference between a ctrlr built JP8080 VST vs a Waldorf Microwave VST when both instances are referred to as “CTRLR” in the DAW, well… they can’t, and that’s a hard sell.

The issue gets compounded if we have several AU/VSTs developed within ctrlr. every plugin instance is called and referred to as “CTRLR”… it’d be like if everything built and compiled out of MAX/MSP had to be called “MAX”. That wouldn’t go over well It’s a bit of a show-stopper when it comes to unveiling our creations to the masses, so it’d be really great if there was some way to get there from here w/o breaking stuff.

[jules]

I don’t have any insights to share, I’m afraid - it’s been a while since I worked on that area, and I can’t remember exactly how it all works.

[Pca]

From my experience, it’s not possible to change the plugin name dynamically. The AU host is getting the name from the resource file, not from running code as it is the case for Windows VST. And for VST under MacOSX, the plugin name is taken from the info.plist…

So in my case, I have a wrapper manager application that copy a generic wrapper then modify its file name and the content of info.plist and .rsrc file, and then the wrapper plugin appears in the host plugin list as other regular plugins.

It’s quite tricky but it’s working :?