vanja/yabridge
1
0
Fork 0
mirror of https://github.com/robbert-vdh/yabridge.git synced 2026-05-16 13:40:05 +02:00
Code Issues Packages Projects Releases Wiki Activity

Request and deserialize plugin factory from plugin

Browse Source
This commit is contained in:
Robbert van der Helm
2020-12-06 14:07:21 +01:00
parent 887a856e58
commit 79c6f02d91
9 changed files with 127 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/plugin/bridges/vst3.cpp
+43
View File
@@ -16,6 +16,42 @@
#include "vst3.h"
#include "src/common/serialization/vst3.h"
#include "vst3-impls.h"
// There are still some design decisions that need some more thought
// TODO: Check whether `IPlugView::isPlatformTypeSupported` needs special
// handling.
// TODO: The documentation mentions that private communication through VST3's
// message system should be handled on a separate timer thread. Do we
// need special handling for this on the Wine side (e.g. during the event
// handling loop)? Probably not, since the actual host should manage all
// messaging.
// TODO: The docs very explicitly mention that
// the`IComponentHandler::{begin,perform,end}Edit()` functions have to be
// called from the UI thread. Should we have special handling for this or
// does everything just magically work out?
// TODO: Something that's not relevant here but that will require some thinking
// is that VST3 requires all plugins to be installed in ~/.vst3. I can
// think of two options and I"m not sure what's the best one:
//
// 1. We can add the required files for the Linux VST3 plugin to the
// location of the Windows VST3 plugin (by adding some files to the
// bundle or creating a bundle next to it) and then symlink that bundle
// to ~/.vst3.
// 2. We can create the bundle in ~/.vst3 and symlink the Windows plugin
// and all of its resources into bundle as if they were also installed
// there.
//
// The second one sounds much better, but it will still need some more
// consideration. Aside from that VST3 plugins also have a centralized
// preset location, even though barely anyone uses it, yabridgectl will
// also have to make a symlink of that. Also, yabridgectl will need to do
// some extra work there to detect removed plugins.
// TODO: Also symlink presets, and allow pruning broken symlinks there as well
// TODO: And how do we choose between 32-bit and 64-bit versions of a VST3
// plugin if they exist? Config files?
Vst3PluginBridge::Vst3PluginBridge()
: PluginBridge(
PluginType::vst3,
@@ -34,6 +70,13 @@ Vst3PluginBridge::Vst3PluginBridge()
// host
connect_sockets_guarded();
// Set up the plugin factory, since this is the first thing the host will
// request after loading the module
plugin_factory = std::make_unique<YaPluginFactoryPluginImpl>(*this);
sockets.host_vst_control.receive_into(
WantsPluginFactory{}, *plugin_factory,
std::pair<Vst3Logger&, bool>(logger, true));
// Now that communication is set up the Wine host can send callbacks to this
// bridge class, and we can send control messages to the Wine host. This
// messaging mechanism is how we relay the VST3 communication protocol. As a
src/plugin/bridges/vst3.h
+14
View File
@@ -18,6 +18,7 @@
#include <thread>
#include "../..//common/serialization/vst3/plugin-factory.h"
#include "../../common/communication/vst3.h"
#include "../../common/logging/vst3.h"
#include "common.h"
@@ -63,4 +64,17 @@ class Vst3PluginBridge : PluginBridge<Vst3Sockets<std::jthread>> {
* `PluginBridge::generic_logger`.
*/
Vst3Logger logger;
public:
/**
* Our plugin factory. This will be set up directly after initialization.
* All information about the plugin and its supported classes are copied
* directly from the Windows VST3 plugin's factory on the Wine side, and
* we'll provide an implementation that can send control messages to the
* Wine plugin host.
*
* A pointer to this implementation will be returned to the host in
* GetPluginFactory().
*/
std::unique_ptr<YaPluginFactory> plugin_factory;
};
src/plugin/vst3-plugin.cpp
+12 -99
View File
@@ -17,9 +17,6 @@
#include <public.sdk/source/main/pluginfactory.h>
#include "bridges/vst3.h"
// TODO: Remove include, instantiating and returning the `YaPluginFactory`
// should be done in `Vst3PluginBridge`
#include "src/plugin/bridges/vst3-impls.h"
#include <public.sdk/source/main/linuxmain.cpp>
@@ -76,101 +73,17 @@ SMTG_EXPORT_SYMBOL Steinberg::IPluginFactory* PLUGIN_API GetPluginFactory() {
// The host should have called `InitModule()` first
assert(bridge);
// TODO: Instead of using gPluginFactory we'll use a field in
// `Vst3PluginBridge`
// TODO: First thing we should do is query the factory on the Wine side and
// preset a copy of it to the host. The important bits there are that
// we use the same interface version as the one presented the plugin.
// TODO: We have two options for the implementation:
// 1. We can query the interface version, and then have three
// different implementations for the interface version.
// 2. We can implement version 3, but copy the iid from the plugin so
// it always uses the correct version.
return bridge->plugin_factory.get();
// TODO: Remove, this is just for type checking
if (false) {
boost::asio::local::stream_protocol::socket* socket;
YaPluginFactoryPluginImpl object(*bridge);
write_object(*socket, object);
}
if (!gPluginFactory) {
// TODO: Here we want to:
// 1) Load the plugin on the Wine host
// 2) Create a factory using the plugins PFactoryInfo
// 3) Get all PClassInfo{,2,W} objects from the plugin, register
// those classes.
//
// We should wrap this in our `Vst3PluginBridge`
// TODO: We should also create a list of which extensions we have
// already implemented and which are left
// TODO: And when we get a query for some interface that we do not (yet)
// support, we should print some easy to spot warning message
// TODO: Check whether `IPlugView::isPlatformTypeSupported` needs
// special handling.
// TODO: Should we always use plugin groups or for VST3 plugins? Since
// they seem to be very keen on sharing resources and leaving
// modules loaded.
// TODO: The documentation mentions that private communication through
// VST3's message system should be handled on a separate timer
// thread. Do we need special handling for this on the Wine side
// (e.g. during the event handling loop)? Probably not, since the
// actual host should manage all messaging.
// TODO: The docs very explicitly mention that
// the`IComponentHandler::{begin,perform,end}Edit()` functions
// have to be called from the UI thread. Should we have special
// handling for this or does everything just magically work out?
// TODO: Something that's not relevant here but that will require some
// thinking is that VST3 requires all plugins to be installed in
// ~/.vst3. I can think of two options and I"m not sure what's the
// best one:
//
// 1. We can add the required files for the Linux VST3 plugin to
// the location of the Windows VST3 plugin (by adding some
// files to the bundle or creating a bundle next to it) and
// then symlink that bundle to ~/.vst3.
// 2. We can create the bundle in ~/.vst3 and symlink the Windows
// plugin and all of its resources into bundle as if they were
// also installed there.
//
// The second one sounds much better, but it will still need some
// more consideration. Aside from that VST3 plugins also have a
// centralized preset location, even though barely anyone uses it,
// yabridgectl will also have to make a symlink of that. Also,
// yabridgectl will need to do some extra work there to detect
// removed plugins.
// TODO: Also symlink presets, and allow pruning broken symlinks there
// as well
// TODO: And how do we choose between 32-bit and 64-bit versions of a
// VST3 plugin if they exist? Config files?
// static Steinberg::PFactoryInfo factoryInfo(vendor, url, email,
// flags); gPluginFactory = new Steinberg::CPluginFactory(factoryInfo);
//
// {
// Steinberg::TUID lcid = cid;
// static Steinberg::PClassInfo componentClass(lcid, cardinality,
// category, name);
// gPluginFactory->registerClass(&componentClass, createMethod);
// }
// {
// Steinberg::TUID lcid = cid;
// static Steinberg::PClassInfo2 componentClass(
// lcid, cardinality, category, name, classFlags, subCategories,
// 0, version, sdkVersion);
// gPluginFactory->registerClass(&componentClass, createMethod);
// }
// {
// TUID lcid = cid;
// static Steinberg::PClassInfoW componentClass(
// lcid, cardinality, category, name, classFlags, subCategories,
// 0, version, sdkVersion);
// gPluginFactory->registerClass(&componentClass, createMethod);
// }
} else {
gPluginFactory->addRef();
}
return gPluginFactory;
// TODO: In the normal implementation of this function they manually call
// part of the reference counting mechanism. Is this something we also
// have to? And how does the `delete self` in the `removeRef()` play
// with our `std::unique_ptr` (aka, should we also use IPtr here)? The
// normal implementation looks like this:
// if (!gPluginFactory) {
// // Instantiate the factory
// } else {
// gPluginFactory->addRef();
// }
// return gPluginFactory;
}