Licensing has changed to version 2.2.2! Please read the new license agreement VST 3 Licensing Issues. (if you have already signed the version 2.0 of the license agreement you do not have to sign it again).
cmake:
Refactoring: rename function/macro by adding target when target is used: i.e. smtg_run_vst_validator => smtg_target_run_vst_validator
Breaking Change: change smtg_add_vst3_resource to smtg_target_add_plugin_resources allowing to add multiple resources in a call
Breaking Change: change smtg_add_vst3_snapshot to smtg_target_add_plugin_snapshots allowing to add multiple resources in a call
make Universal Binary on Mac default ON when Xcode12
Add support of new VST3 Location on Windows: new option SMTG_PLUGIN_TARGET_USER_PROGRAM_FILES_COMMON
I see this change " New VST3 plug-in location user local on Windows"? A few releases back, there was a change on Windows as well to use a bundle format instead of a DLL.
I am just curious what you think the expectations are for these kind of changes: on one side, they are unlikely going to be supported by all DAWs that support VST3 in the immediate future. On the other side, developers who have written VST3 plugins using the DLL format or have released versions of their plugins with an installer that install in the “old” location are also very unlikely to upgrade to 3.7.4 just so that they can provide a new bundle format and/or installer. This means that DAWs now have to support the old DLL format, the new bundle format, the old location, the new location, etc…
So what is your thinking there? Are you considering these kind of scenarios when you make these kind of changes? And what is your anticipation for the migration?
for bundle on Windows we have checked with the main VST3 DAWs the compatibility => it was Ok. If you know some hosts having problems with bundle/folder VST3 on Windows, please inform us and them.
for the new location (user common program) on Windows, we will communicate to the major VST3 hosts to implement it. This location is mainly for developing condition with no Admin right access, but nevertheless it could be useful for computer with multiple users. (Already supported by Cubase 11 and higher)
Thank you for clarifying. I guess one thing to never forget is that these kind of changes are part of the “API” between the DAW and the plugin. And if a DAW wants to support VST3, they have to implement the old way (DLL/old location) and the new way (bundle/new location) for the foreseeable future…
And what happens when there is a conflict; the same plugin is available in the old and the new location?
Examples: Developer releases a new version that installs in the new location but there is an old version installed in the old location.
Dev wants to be on the safe side and installs the plugin in both, the old and the new, location?
If there’a a conflict then the plug-in with the higher version is used. But normally the new location should only be used for development. Manufactures should install the plug-in for all users of a machine.
Breaking Change: change smtg_add_vst3_resource to smtg_target_add_plugin_resources allowing to add multiple resources in a call * Breaking Change: change smtg_add_vst3_snapshot to smtg_target_add_plugin_snapshots allowing to add multiple resources in a call
Please give us a proper docomentation what we have to change, why we have to change and what the change affects. I had serious problems with cmake and the VST3 SDK and spent months to make things work.
“Audio Unit: Update AU SDK as external (version 1.1)”
Is it finally possible to build AudioUnits again? You did not answer to my recent posts with techical issues about it. Were you finally able to fix the broken AU Adapter that fails compiling on ARM Macs because it was using technology that’s deprecated since half a decade?
cmake: I had LOTS of trouble and wasted LOTS of development time to make things in the VST SDK work with cmake (VST SDK 3.6.9 & 3.7.1). I strongly dislike this design decision.
Does the VSTGUI rely on OpenGL, which is deprecated and might be stop working with upcoming MacOS releases? What will happen with existing plugins in practise?
The majority of developers do not like it if end-users can easily mess around in the resources of their products. It will lead to many unnecessry support requests where customers complain about ‘crashes’. The whole thing opens a can full of worms. It can also make trouble with installers and hosts.
I strongly dislike the new ‘bundle’ way on PC instead of a simple and compact single dll. Imho a very bad design decision
Sorry for my negative feedback, but I am very disappointed by the VST3 SDK. I lost half a year of work just to find out that the VST3 SDK does not work properly. That’s why I recently moved to JUCE.
I am also disappointed how Steinberg treats us developers and the open source community.
In the recent years I’ve seen many fellow devs and customers to turn from fans into enemies.
Your management should seriously rethink.
The majority of SDKs/Libraries/OpenSource are using cmake as project generator. cmake is widely supported and maintened. The decision was a very good decision indeed.
VSTGUI OpenGL:
VSTGUI does not rely on OpenGL, but allows to embed such UI element.
VST3 Bundle on Windows:
I do not understand your problem, as developer it makes us easier to have the same approach over all platform. You have everything the plugin needs inside a folder (bundle). If you don’t want to use it, it is your choice, the old way is still available.
Unlike in JUCE the cmake builing failed in many places (SDK 3.7.1).
Please answer also 1) and 2). I can’t afford to waste further months of development time with the VST3 SDK unless I know that things have been fixed. It also affects other developers.
Breaking Change: change smtg_add_vst3_resource to smtg_target_add_plugin_resources allowing to add multiple resources in a call * Breaking Change: change smtg_add_vst3_snapshot to smtg_target_add_plugin_snapshots allowing to add multiple resources in a call
Please give us a proper docomentation what we have to change, why we have to change and what the change affects. I had serious problems with cmake and the VST3 SDK and spent months to make things work.
“Audio Unit: Update AU SDK as external (version 1.1)”
Is it finally possible to build AudioUnits again? You did not answer to my recent posts with techical issues about it. Were you finally able to fix the broken AU Adapter that fails compiling on ARM Macs because it was using technology that’s deprecated since half a decade?
Breaking Change: change smtg_add_vst3_resource to smtg_target_add_plugin_resources allowing to add multiple resources in a call