AudioProcessor program change notification

Audio Plugins
1

It seems that setCurrentProgram() is to handle program changes from the DAW.

How should changes from the AudioProcessorEditor be promoted to the DAW?

updateHostDisplay() seems a bit too heavy to notify about simple program changes as the AudioProcessor expets that anything could have changed, consequently it tears down streaming, stops and resumes audio processing.

This is probably kind of OK for native plugins, but for DSP based plugins this is catastrophic! 

Initiating the whole DSP setup, with large coeff pages, etc. might take a noticible time. Glitch free audio processing is not achiviabale, because the DSP is disconected and another audio route is created, previous memory, i.e. delay lines is also not accesible anymore (though its arguable if keeping delay lines, etc. is desired at all). But it simply takes to mutch time for automation.

What would be the right way to notifiy the DAW that the program has changed?

Thanks and cheers,

Raketa

 

2

http://www.juce.com/api/classAudioProcessor.html

getStateInformation (juce::MemoryBlock &destData)=0
  // The host will call this method when it wants to save the filter's internal state. 

Always have a tab open in your browser with the JUCE API documentation, it is all in there! :-)

3

Thanks Peter,

sure, my Browser has the JUCE API docu burnt-in... ;)

but - I probably overlook something here - I don't get how this anwer glues to my "how to inform the host DAW about a program change initiated from the plugin UI"?

Thanks for any hint, unblocking my perception,

Cheers,

Raketa

4

I use setParameterNotifyingHost(..) to set all parameters in the overwritten setCurrentProgram(..) function. This should notify the host about changes.

You should be carefully when you call this function from within the processing thread. This maybe happens when you support MIDI Prg Change or MIDI controllers.

5

After my reply, I felt a bit insecure about it, because I only took a quick glance at my working code. I know from debugging that the host can call the getStateInformation quite often, but maybe indeed setParameterNotifyingHost is really the one to use (which I also use).

6

Thanks, Patrick,

but how do you let the host keep track of the program number than?

Cheers,

Raketa

7

Thanks, Peter,

for the clarification.

(I still feel I have overlooked something though, as my plugin is surely not the only one that needs to inform the host about a program change...)

 

Thanks,

Raketa

1 Like
8

The problem persists up today. And no jucer seemed to be able to share any insight here?

9

Most commercial plug-ins do have their own preset system and there is only one default preset in the hosts vst standard presets list. Users often want preset files today and that does not work very well with the standard vst preset list / manager…
You also have to save all the presets within the state when you do that. Some hosts load the whole preset list and select the preset the user have loaded when saving the arrangement.
I used to call updateHostDisplay() in our older free plugins that had no own preset system.

1 Like
10

Thanks @kunz, yes we also have our own preset handling. Nevertheless when used in film production people seem to be used to switch preset scenes. A prerequisite is that the preset name is also switched, which can’t be easily achieved with any kind of proprietary workaround. So we need to be able inform the host and I don’t know what makes it so difficult to provide an interface which can handle such a basic plugin feature without disturbing streaming?

void audioProcessorChanged (AudioProcessor*) override
{
    if (auto* pluginInstance = getPluginInstance())
    {
        if (pluginInstance->getNumPrograms() > 1)
            EditController::setParamNormalized (paramPreset, static_cast<Vst::ParamValue> (pluginInstance->getCurrentProgram())
                                                           / static_cast<Vst::ParamValue> (pluginInstance->getNumPrograms() - 1));
    }

    if (componentHandler != nullptr)
        componentHandler->restartComponent (Vst::kLatencyChanged | Vst::kParamValuesChanged);
}

If I change the last line to remove the kLatencyChanged flag, the problem disappears.

    if (componentHandler != nullptr)
        componentHandler->restartComponent (Vst::kParamValuesChanged);

I don’t see a reason why the plugin in that situation always claims that latency has changed?
Do I have to patch and maintain my own JUCE code again?

Further I am taking my time to review features of JUCE and nobody from JUCE seems to be able to - at least - clarify here for other 3 years now.

1 Like
11

Yes, it would be nice to show the preset name also in the VST standard preset browser without interrupting audio processing. I gave up on this.
It looks like updateHostDisplay() is too general for such a small change like the preset name.

12

Roli, three years, not able to spare a word?
Even, “we really don’t care” would give me at least a free afternoon, what do you think?

13

We can only create wrappers around functionality that the plugin APIs support - AFAIK there’s nothing in them to do what you need and updateHostDisplay() is the only option.

14

@jules, I probably don’t understand what you trying to say here, but

componentHandler->restartComponent (Vst::kParamValuesChanged)

is not “in them”?

15

Would it be possible to provide a light wight way of informing the DAW about the plugins state change? How about a bool parameter for updateHostDisplay(bool latencyChanged=false)?

16

Hmmm, most of the plugins I use support the vst program list, and seem to be able to report program names to the host without any processing issues. And the hosts I use support it… I’m curious how this is possible!

2 Likes
17

BUMP

This is a big deal on iOS in AUv3 and would definitely express how much this is needed.