vanja/yabridge
1
0
Fork 0
mirror of https://github.com/robbert-vdh/yabridge.git synced 2026-05-14 20:40:03 +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/common/bitsery/ext/boost-path.h
-2
View File
@@ -27,8 +27,6 @@
namespace bitsery {
namespace ext {
// TODO: There's probably a better way to do all of this
/**
* An adapter for serializing and deserializing filesystem paths since they're
* not mutable.
src/common/logging/vst3.cpp
+23
View File
@@ -17,6 +17,7 @@
#include "vst3.h"
#include <sstream>
#include "src/common/serialization/vst3.h"
// TODO: Reconsider the output format
// TODO: Maybe think of an alterantive that's a little less boilerplaty
@@ -33,6 +34,16 @@ void Vst3Logger::log_request(bool is_host_vst, const WantsConfiguration&) {
}
}
void Vst3Logger::log_request(bool is_host_vst, const WantsPluginFactory&) {
if (BOOST_UNLIKELY(logger.verbosity >= Logger::Verbosity::most_events)) {
std::ostringstream message;
message << get_log_prefix(is_host_vst)
<< " >> Requesting <IPluginFactory*>";
log(message.str());
}
}
void Vst3Logger::log_response(bool is_host_vst, const Configuration&) {
if (BOOST_UNLIKELY(logger.verbosity >= Logger::Verbosity::most_events)) {
std::ostringstream message;
@@ -41,3 +52,15 @@ void Vst3Logger::log_response(bool is_host_vst, const Configuration&) {
log(message.str());
}
}
void Vst3Logger::log_response(bool is_host_vst,
const YaPluginFactory& factory) {
if (BOOST_UNLIKELY(logger.verbosity >= Logger::Verbosity::most_events)) {
std::ostringstream message;
message << get_log_prefix(is_host_vst) << " <IPluginFactory*> with "
<< const_cast<YaPluginFactory&>(factory).countClasses()
<< " registered classes";
log(message.str());
}
}
src/common/logging/vst3.h
+2
View File
@@ -44,8 +44,10 @@ class Vst3Logger {
// (what we'll call a control message).
void log_request(bool is_host_vst, const WantsConfiguration&);
void log_request(bool is_host_vst, const WantsPluginFactory&);
void log_response(bool is_host_vst, const Configuration&);
void log_response(bool is_host_vst, const YaPluginFactory&);
Logger& logger;
src/common/serialization/vst3.h
+10 -2
View File
@@ -45,16 +45,24 @@ struct WantsConfiguration {
using Response = Configuration;
};
/**
* Marker struct to indicate the other side (the Wine plugin host) should send a
* copy of the hosted Windows VST3 plugin's `IPluginFactory{,2,3}` interface.
*/
struct WantsPluginFactory {
using Response = YaPluginFactory;
};
/**
* When we send a control message from the plugin to the Wine VST host, this
* encodes the information we request or the operation we want to perform. A
* request of type `ControlRequest(T)` should send back a `T::Reponse`.
*/
using ControlRequest = std::variant<>;
using ControlRequest = std::variant<WantsPluginFactory>;
template <typename S>
void serialize(S& s, ControlRequest& payload) {
s.ext(payload, bitsery::ext::StdVariant{});
s.ext(payload, bitsery::ext::StdVariant{[](S&, WantsPluginFactory&) {}});
}
/**
src/common/serialization/vst3/plugin-factory.cpp
-2
View File
@@ -53,8 +53,6 @@ YaPluginFactory::YaPluginFactory(
// `IPluginFactory::countClasses`
num_classes = factory->countClasses();
// `IPluginFactory::getClassInfo`
// TODO: At this point we don't know what this class is and thus we can't
// filter unsupported classes, right?
class_infos_1.resize(num_classes);
for (int i = 0; i < num_classes; i++) {
Steinberg::PClassInfo info;
src/common/serialization/vst3/plugin-factory.h
+23 -22
View File
@@ -86,6 +86,29 @@ class YaPluginFactory : public Steinberg::IPluginFactory3 {
virtual tresult PLUGIN_API
setHostContext(Steinberg::FUnknown* context) override = 0;
template <typename S>
void serialize(S& s) {
s.ext(known_iids, bitsery::ext::StdSet{32},
[](S& s, Steinberg::FUID& iid) {
s.ext(iid, bitsery::ext::FUID{});
});
s.ext(factory_info, bitsery::ext::StdOptional{});
s.value4b(num_classes);
s.container(class_infos_1, 2048,
[](S& s, std::optional<Steinberg::PClassInfo>& info) {
s.ext(info, bitsery::ext::StdOptional{});
});
s.container(class_infos_2, 2048,
[](S& s, std::optional<Steinberg::PClassInfo2>& info) {
s.ext(info, bitsery::ext::StdOptional{});
});
s.container(class_infos_unicode, 2048,
[](S& s, std::optional<Steinberg::PClassInfoW>& info) {
s.ext(info, bitsery::ext::StdOptional{});
});
}
private:
/**
* The IIDs that the interface we serialized supports.
*/
@@ -115,28 +138,6 @@ class YaPluginFactory : public Steinberg::IPluginFactory3 {
* above.
*/
std::vector<std::optional<Steinberg::PClassInfoW>> class_infos_unicode;
template <typename S>
void serialize(S& s) {
s.ext(known_iids, bitsery::ext::StdSet{32},
[](S& s, Steinberg::FUID& iid) {
s.ext(iid, bitsery::ext::FUID{});
});
s.ext(factory_info, bitsery::ext::StdOptional{});
s.value4b(num_classes);
s.container(class_infos_1, 2048,
[](S& s, std::optional<Steinberg::PClassInfo>& info) {
s.ext(info, bitsery::ext::StdOptional{});
});
s.container(class_infos_2, 2048,
[](S& s, std::optional<Steinberg::PClassInfo2>& info) {
s.ext(info, bitsery::ext::StdOptional{});
});
s.container(class_infos_unicode, 2048,
[](S& s, std::optional<Steinberg::PClassInfoW>& info) {
s.ext(info, bitsery::ext::StdOptional{});
});
}
};
#pragma GCC diagnostic pop
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;
}