Optimization of VST3 shell plug-ins instantiation #530
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jrlanglois
reviewed
May 20, 2019
modules/juce_audio_processors/format_types/juce_VST3PluginFormat.cpp
Outdated
Show resolved
Hide resolved
jrlanglois
reviewed
May 20, 2019
| PClassInfo info; | ||
| factory->getClassInfo(i, &info); | ||
|
|
||
| if (std::strcmp(info.category, kVstAudioEffectClass) != 0) |
There was a problem hiding this comment.
I vaguely recall that many audio plugins don't support this method... I suggest testing with a variety of open-source plugs to be sure.
There was a problem hiding this comment.
Have a look at DescriptionFactory to get a better sense of it.
There was a problem hiding this comment.
I picked this piece of code from DescriptionFactory. Basically this findName() method I added is the same as DescriptionFactory::findDescriptionsAndPerform() but I removed anything that is not needed. So the criteria are the same as before except we don't instantiate and destroy the component.
What I want to check in this loop is:
- the name of the component (does it match the the provided one nested in the passed description)
- is it an audio processor (we ignore any user interface component)
…ng prefix) Instantiating a VST3 shell plug-in can be overkill. For example, if using Waves complete suite of plug-ins (more than 400 plug-ins), the instantiation of the first enumerated plug-in (e.g. Waves API-2500) is almost instant, while the instantiation of the bottom listed plug-ins (e.g. Waves Q10) can take more than a minute. This code update avoids creating an instance of each component handled by a vst3 factory when opening a VST3 module, and instead just checks if the name of the provided description can be found in the enumerated classes of a vst3 factory. It allows a huge speed-up of plug-in instantiation for big VST3 shells such as Waves.
changed findName() into findMatch() and added component uid check in addition to name
|
Thank you. Added in 9c50bbd. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instantiating a VST3 shell plug-in can be overkill. For example, if using Waves complete suite of plug-ins (more than 400 plug-ins), the instantiation of the first enumerated plug-in (e.g. Waves API-2500) is almost instant, while the instantiation of the bottom listed plug-ins (e.g. Waves Q10) can take more than a minute.
This code update avoids creating an instance of each component handled by a vst3 factory when opening a VST3 module, and instead just checks if the name of the provided description can be found in the enumerated classes of a vst3 factory. It allows a huge speed-up of plug-in instantiation for big VST3 shells such as Waves.