My own VST3 host can correctly load VST3 plugins.
On some plugins, preset selection works fine, on others it does not work. What could be the reason?
I obtain the ProgramChangeParameterId from :
FUnknownPtr<IUnitInfo> unitInfo(App_editController);
if (unitInfo)
{
const unsigned int program_list_count = unitInfo->getProgramListCount();
ProgramListInfo programlist_info = {};
for (unsigned int i = 0; i < program_list_count; ++i)
{
tresult t = unitInfo->getProgramListInfo(i, programlist_info);
if (!t) // 0=kResultTrue
{
BankPreset.bank_id = programlist_info.id;
if (found_i == 0)
{
ProgramChangeParameterId = programlist_info.id; // Program Change Parameter ID
}
}
}
}
And I get the exact same value when obtaining it from:
const unsigned int ParameterCount = (const unsigned int)App_editController->getParameterCount();
Steinberg::Vst::ParameterInfo info = {};
for (unsigned int i = 0; i < ParameterCount; ++i)
{
tresult t = App_editController->getParameterInfo(i, info);
if (!t)
{
const int isProgramChange = (int)((info.flags & info.kIsProgramChange) != 0);
if (isProgramChange) { ProgramChangeParameterId = info.id; }
}
}
Then its correctly processed in the preprocess method.
and then send to the plugin.
This all works for some plugins, but for others it does not, although for those plugins the presets can be changed from within other DAW’s over the DAW’s preset menu.
Thank you.
On start of the video a plugin, where preset selection works in my own VST3; At second 11 in the video the 2nd plugin, where the selection does not work. Only the internal preset menu of the plugin works there. Both plugin’s preset selection works without problems in another DAW.
Thank you for your answer.
I changed (!t) into (t == kResultTrue) in my code.
Then I tried out programchange.vst3,
in the file PlugController::setParamNormalized I found: componentHandler->restartComponent (kParamValuesChanged)
which is simply ignored by my own VST3 host.
Cause in this post its said, that “kParamValuesChanged) will only trigger the host to invalidate its caches for the parameter titles and values. It will not send parameter changes to the processor in its process function and it will not deactivate and activate the processor.”
So do I actually need to implement anything there?
and it calls processor->process(processData)
which succeeds with kResultOk
In all plugins i tested this all worked, but in some plugins the preset was not changed (although other DAW’s correctly change it) and in
programchange.vst3 to me its a bit unclear, how I should investigate further from now.
Since I (additionally) added App_editController->setParamNormalized ( ProgramChangeParameterId, valueNormalized);
now ComponentHandler::restartComponent is called. [If I only call setParamNormalized without the paramTransferrer calls, then the first plugin in the video of last post does not anymore change its preset]
App_editController was initialialized this way: App_editController = _plugProvider->getController();
So obviously I need to call PlugController::setParamNormalized additionally to adding the program change parameter to the transferrer list?
However, since calling additionally App_editController->setParamNormalized ( ProgramChangeParameterId, valueNormalized);
some other plugins now work correctly.
I noticed, that most of the plugins, for which the preset selection does not work properly, seam all to be SINGLE COMPONENT and also their audio output is not present on some. Is it required that those single component plugins run always on one thread? Currently they are running on 2 threads: one UI thread and a “processing” thread, which runs the “process” method; The preset handling is done in the “processing” thread. Could that be the reason? Should it better be done on the UI thread?
I moved the call to App_editController->setParamNormalized () into the UI thread; And while it works for most plugins, its still failing on the second one mentioned in the video in a previous post of this thread.
It seems, that I have found the root cause. Somehow the automation parameter id is not correctly processed in my host for that plugin. If I enter that parameter id in the code, now the preset-change works.
The code, which caused the problem is in my first post within this thread: ProgramChangeParameterId = programlist_info.id;
during reading from the unitInfo for that plugin gives a different result, than the code when enumerating through the parameters if (isProgramChange) { ProgramChangeParameterId = info.id; }
I used uinfo.programListId as automation parameter id (as seen in the first post in thisthread) cause I found it here uinfo.programListId = kProgramChangeParamID; in this post
And also in the mentioned sample mdaBaseProcessor.cpp its used this way: uinfo.programListId = kPresetParam;
Did i misunderstand something? So is there a difference between MIDI program change and Automation Parameter Program Change?
Some plugins call their presets “MIDI Programs”.
So please tell me, what is the correct way ?
I also contacted the developer of that plugin to clarify this.
The audio output problems of the plugin were caused by some MIDI OUT settings and bus activation issues in my host. No issues anymore when running the 2 threads (“processing” and “UI thread”) for a plugin.
I always now use the Automation Parameter ID obtained from getParameterInfo; This works on all plugins I tested so far.
Solved!
