AudioFilterStreamer fix needed

With the updates in the latest tip (709), the code of the standalone plugin format got broken in the juce_AudioFilterStreamer.cpp file, in the body of setFilter() at the end of the file.

I think the fix is easy, replacing the old calls to setAudioCallback with the matching addAudioCallback and removeAudioCallback introduced in the latest version.

Old code:

void AudioFilterStreamingDeviceManager::setFilter (AudioProcessor* filterToStream)
{
    if (streamer != 0)
    {
        removeMidiInputCallback (String::empty, streamer);
        setAudioCallback (0);

        delete streamer;
        streamer = 0;
    }

    if (filterToStream != 0)
    {
        streamer = new AudioFilterStreamer (*filterToStream);

        setAudioCallback (streamer);
        addMidiInputCallback (String::empty, streamer);
    }
}

New code:

void AudioFilterStreamingDeviceManager::setFilter (AudioProcessor* filterToStream)
{
    if (streamer != 0)
    {
        removeMidiInputCallback (String::empty, streamer);
        removeAudioCallback (streamer);

        delete streamer;
        streamer = 0;
    }

    if (filterToStream != 0)
    {
        streamer = new AudioFilterStreamer (*filterToStream);

        addAudioCallback (streamer);
        addMidiInputCallback (String::empty, streamer);
    }
}

Sorry, yes, I forgot to update that file… As you suggest, it’s an easy fix, thanks for posting.

Another fix i discovered in the standalone wrapper is to save the plugins state BEFORE releasing the DeviceManager, some plugins still don’t like the opposite:

StandaloneFilterWindow::~StandaloneFilterWindow()
{
    PropertySet* const globalSettings = getGlobalSettings();

    globalSettings->setValue (T("windowX"), getX());
    globalSettings->setValue (T("windowY"), getY());

    deleteAndZero (optionsButton);

    if (globalSettings != 0 && deviceManager != 0)
    {
        XmlElement* const xml = deviceManager->createStateXml();
        globalSettings->setValue (T("audioSetup"), xml);
        delete xml;
    }

    if (globalSettings != 0 && filter != 0)
    {
        JUCE_NAMESPACE::MemoryBlock data;
        filter->getStateInformation (data);
        globalSettings->setValue (T("filterState"), data.toBase64Encoding());
    }

    deleteAndZero (deviceManager);

    deleteFilter();
}

Is it a good point in your opinion ? (never had any problem with this version)

Well, there’s no harm in doing it that way round, but presumably anyone using this class will be hosting their own plugin code - and if your plugin code is so flaky that it can only save when the audio is running, it’s your code that needs fixing, not the wrapper!

i discovered that when i was juceifiyng some open source vst out there, can’t remember which ones, but sure probably the problem should be fixed upstream in the plugin itself. anyway it doesn’t do any harm as you say :slight_smile: