Request: Change default name in juce_VSTPluginFormat.cpp getHostName()


I know this is a stretch because JUCE has officially stopped focusing on VST2 but… I’m working on a plugin that acts as a host for another VSTi. The VSTi that my plugin hosts requires a specific product name be provided by audioMasterGetProductString in order for it to work properly. I was looking through the juce modules to see where this can be set and found that it’s all happening in juce_VSTPluginFormat.cpp when the function getHostName() is called. The function looks like this:

static pointer_sized_int getHostName (char* name)
String hostName (“Juce VST Host”); //<— this is what I want to change

    if (auto* app = JUCEApplicationBase::getInstance())
        hostName = app->getApplicationName();

    hostName.copyToUTF8 (name, (size_t) jmin (Vst2::kVstMaxVendorStrLen, Vst2::kVstMaxProductStrLen) - 1);
    return 1;

As you can see the function starts with a default string that JUCE provides and then looks for an application name. This works great for standalone apps but not so well for my plugin. I’m hoping for a way to set that string (apart from editing the juce module itself because then I need to maintain the change everytime I update the library). It would be great if we could get access to the variable so we can set the default name on our own, or at the very least, expand this feature so that it will default to the plugin name if it is not an application. Would this be possible to add?

Thanks in advance!

@reuk do you think this change can be added?
Either give us the option to set the hostName string ourselves, or take the name from the plugin if you’re not running an application.

I’m taking some leave this week. I’ve added this to my backlog, and I’ll try to give a proper answer next week.

Thanks for your patience. I’ve added a preprocessor definition which can be used to set the name of the host:

@reuk That is perfect, thank you! I’ve noticed one other issue that I believe may need to be fixed in the JUCE module regarding juce_VSTPluginFormat.cpp. In the function constructEffect(const ModuleHandle::Ptr& module) there is an assertion that the “object” member of the Vst2::AEffect structure must not be nullptr. However as far as I understand there is no problem for the object member to be nullptr for a working plugin so I was wondering if it would be possible to remove that assertion. When I comment it out the plugin I’m working with loads correctly and has no issues but I would like to be able to test my hosted plugins in debug builds so removing that assertion would be very helpful. @reuk, do you know of any reason why that assertion exists? Would it be possible to remove it? Below is the code. Thanks again!!

static Vst2::AEffect* constructEffect (const ModuleHandle::Ptr& module) {

        if (effect != nullptr && effect->magic == 0x56737450 /* 'VstP' */)
            jassert (effect->resvd2 == 0);
            jassert (effect->object != nullptr); //<-- this is the problem line

            _fpreset(); // some dodgy plugs mess around with this
            effect = nullptr;
    catch (...)

    return effect;

It looks like that assertion has been there since the very first VSTPluginFormat commit in 2009. It’s not clear to me whether it’s valid for that pointer to be null, and I would be reluctant to remove this assertion which hasn’t caused any problems for other users (as far as I can tell, anyway). Which plugin is causing the problem? If it’s your own custom plugin, could you just set the pointer to some non-null value?

You should be able to hit ‘continue’ on your debugger to resume execution after hitting a jassert.

Thanks @reuk. From what I understand, the “object” pointer is for the AudioEffect class which is only applicable if a VST is made in C++. I don’t think it’s even being used - JUCE uses a C standard dispatcher, which any host should do. If JUCE is actually trying to use the object pointer somewhere in code, then wouldn’t a fake pointer cause a crash?

I don’t think it’s used on the hosting side, but it seems that most plugins set it, otherwise I’m sure we’d have had lots of complaints about this assertion firing! As such, I think the assertion is probably valuable to indiciate that the plugin likely failed to load correctly.

If there are examples of well-known or commonly-used plugins which don’t set this pointer, then there would be a much stronger case for removing the assertion.