canDo bug in JuceVstWrapper and a problem with FLStudio


FLStudio 5 insisted that my VST is an effect and not a synth althoug isSynth() returns true. I find out that it sends effCanDo and I found two problems.

  • FLStudio ask if can do '“receiveVstMidiEvent” instead of “…events”
  • JuceVstWrapper comapred the cando strings with strcmp != 0 instead of == 0

The fixed code is bellow, the problem is that FLStudio still thinks my VST is an effect :frowning:

long canDo (char* text)
	long result = 0;

    if (strcmp (text, "receiveVstEvents") == 0 || strcmp (text, "receiveVstMidiEvents") == 0 || strcmp (text, "receiveVstMidiEvent") == 0 )
        result = filter->takesMidiInput() ? 1 : -1;
    else if (strcmp (text, "sendVstEvents") == 0 || strcmp (text, "sendVstMidiEvent") == 0)
        result = filter->producesMidiOutput() ? 1 : -1;
    else if (strcmp (text, "receiveVstTimeInfo") == 0)
        result = 1;
    else if (strcmp (text, "conformsToWindowRules") == 0)
        result = 1;

    return result;


Another issue I have with FLStudio (and probably with Cubase also) is that when the VST exists because the host don’t like it for some reason, the host disapears from memory…in the debugger I get here:

    if (isThreadRunning())
        // very bad karma if this point is reached, as
        // there are bound to be locks and events left in
        // silly states when a thread is killed by force..
        Logger::writeToLog (T("!! killing thread by force !!"));

To reprdocue:

Compile JuceAudioPlugin demo and change isSynth() and takesMidiInput() to return true instead of false

Try to insert the juce_vst as an instrument in FLStudio 5 and FLStudio is gone or breaks into the above code…


Jeez… I obviously wasn’t on top form when I wrote that strcmp stuff!

Bit surprising about the threads not dying properly - in DllMain it does try to kill all the Juce threads when the DLL is unloaded… have you started a thread that doesn’t die gracefully within the 3 second timeout? Haven’t got time to play with this right now, but let me know if you find any more clues.


I didn’t start any thread myself, maybe some were started indirectly by JUCE like in the transport, messaging, GUI, etc. I will check it out more since it happens only in Cubase when my plug is rejected. One way to bypass this problem is make my plug act as a good plug and get reject since in normal shutdown there problem does not happen…but I guess we want to find it anyway!

One general commenct about JuceVstWrapper is that in its current form it can be seen as part of JUCE but more of a sample code of how to use the audiofilterbase as a VST since the code cannot be extended in the VST area. For example I am adding VST logging stuff to the code and I have to do it there and not in audiofilterbase. Maybe it can be improved in the future to be a class within the library or something. Another problem is that this code is not used within Tracktion so its not as tested as most of JUCE code…
If someone was writing only VST I would not recommend to use a layer on top unless you plan to have AU and other formats as well. I am using it since I am planning to gain from the other formats support in the future. In the same project I am hosting my VST-only plugins and for them I use the VST SDK directly with JUCE for the audio, midi and GUI stuff


mistake…no news yet…