String assertion in VSTPluginInstance


When calling getProgramName() for plugin Zeta+ I get this String assertion:

String::String (const char* const t)
    : text (StringHolder::createFromCharPointer (CharPointer_ASCII (t)))
    /*  If you get an assertion here, then you're trying to create a string from 8-bit data
        that contains values greater than 127. These can NOT be correctly converted to unicode
        because there's no way for the String class to know what encoding was used to
        create them. The source data could be UTF-8, ASCII or one of many local code-pages.

        To get around this problem, you must be more explicit when you pass an ambiguous 8-bit
        string to the String class - so for example if your source data is actually UTF-8,
        you'd call String (CharPointer_UTF8 ("my utf8 string..")), and it would be able to
        correctly convert the multi-byte characters to unicode. It's *highly* recommended that
        you use UTF-8 with escape characters in your source code to represent extended characters,
        because there's no other way to represent these strings in a way that isn't dependent on
        the compiler, source code editor and platform.
    jassert (t == nullptr || CharPointer_ASCII::isValidString (t, std::numeric_limits<int>::max()));

I get it for this String:

const String VSTPluginInstance::getProgramName (int index)
    if (index == getCurrentProgram())
        return getCurrentProgramName();
    else if (effect != nullptr)
        char nm [256] = { 0 };

        if (dispatch (effGetProgramNameIndexed,
                      jlimit (0, getNumPrograms(), index),
                      -1, nm, 0) != 0)
            return String (nm).trim();            <-  String const. that caused the assertion

    return programNames [index];

Changing to String (CharPointer_ASCII (nm)) made it work, but is that OK for every plugin?
It seems that all my plugins are working well after this change, but I only have like 7 plugins…


Thanks. Casting it to a CharPointer_UTF8 would also work (probably exactly the same) Unfortunately there’s nothing in the VST spec to say what kind of character encoding these strings should use, so any extended characters might end up getting garbled.