Document the plugin factory approach

This commit is contained in:
Robbert van der Helm
2020-12-08 14:21:54 +01:00
parent ed743e6f22
commit f4a5aa91fb
3 changed files with 39 additions and 28 deletions
+1 -26
View File
@@ -25,32 +25,7 @@ tresult PLUGIN_API
YaPluginFactoryPluginImpl::createInstance(Steinberg::FIDString cid,
Steinberg::FIDString _iid,
void** obj) {
// TODO: This should:
// 1. Check which interface `_iid` belongs to. Let's call this
// interface `T`. If we do not (yet) support it, then we should log
// it and return `Steinberg::kNotImplemented`.
// 2. Send a control message to the Wine plugin host to instantiate a
// new object of type `T` with `cid` and `_iid` as parameters.
// 3. On the Wine side this calls `createIntance()` on the module's
// factory with thsoe same `cid` and `_iid` arguments.
// 4. It this was successful, we'll assign this object a unique number
// (by just doing a fetch-and-add on an atomic size_t) so we can
// refer to it and add it to an `std::map<size_t, IP tr<T>`, where
// `T` is the _original_ object (we don't have to and shouldn't
// wrap it).
// 5. We'll copy over any payload data into a `YaT` **which includes
// that unique identifier we generated** and send it back to the
// plugin.
// 6. On the plugin's side we'll create a new `YaTPluginImpl` inside
// of a VST smart pointer and deserialize the `YaT` we got sent
// into that. We then write that smart pointer into `obj`. We don't
// have to keep track of these objects on the plugin side and the
// reference counting pointers will cause everything to clean up
// after itself.
// 7. Since those `YaTPluginImpl` objects we'll return from
// `createInstance()` will have a reference to `Vst3PluginBridge`,
// they can also send control messages themselves.
// TODO: Implement as specified in `src/common/serialization/vst3/README.md`
if (Steinberg::FIDStringsEqual(_iid, Steinberg::Vst::IComponent::iid)) {
// TODO: Instantiate an IComponent as described above
return Steinberg::kNotImplemented;