699ddfd2ea
Implement YaComponentPluginImpl destructor
...
When the object gets dropped through the reference counting system, the
object should also be dropped in the Wine plugin host.
2020-12-11 22:59:32 +01:00
cdb9dae2df
Rename YaComponent::Arguments to CreateArgs
2020-12-11 22:43:12 +01:00
d1d85711f0
Split up the VST3 class implementations
2020-12-11 22:37:20 +01:00
9439a62d94
Fix formatting
2020-12-11 16:56:46 +01:00
aae98d518c
Fix the with-winedbg option
2020-12-11 00:35:29 +01:00
225056bcff
Allow instantiating IComponents
2020-12-08 23:08:07 +01:00
9b025052d2
Add stubs for an IComponent implementation
2020-12-08 23:02:26 +01:00
92ea15bcb4
Allow interface implementations to send messages
2020-12-08 23:01:50 +01:00
f4a5aa91fb
Document the plugin factory approach
2020-12-08 14:21:54 +01:00
f1fe0fa8a4
Log a warning when encountering unknown interfaces
2020-12-07 22:21:01 +01:00
7b3a6af7d1
Use raw pointers for the plugin factory
...
Since the object cleans up after itself after the smart pointers are
dropped on the host side this would result in a use after free by the
smart pointers.
2020-12-07 18:28:17 +01:00
d79bc3b936
Don't use STL smart pointers with VST3 interfaces
...
This would cause double frees since those objects are supposed to clean
up after themselves.
2020-12-07 18:28:17 +01:00
75e8cf9140
Add notes on things that can potentially go wrong
2020-12-07 18:28:17 +01:00
8e09d50a54
Describe how createInstance() is going to work
2020-12-07 18:28:17 +01:00
9954282065
Add manual reference counting to GetPluginFactory
...
Since even though we're passign raw pointers, it's expected that they
are actually `IPtr<T>`s.
2020-12-07 18:28:17 +01:00
547b11e8ba
Remove interface filtering from the plugin factory
...
This doesn't work that way, and CIDs really are class IDs (good thing
that everything's documented, oh right).
2020-12-07 18:28:17 +01:00
8ea40cd9f9
Rework Vst3MessageHandler::receive_messages
...
This now takes a regular overloaded function and the visiting is done in
`receive_messages()` itself. This way we can use templates to ensure
that the return type is correct. Otherwise auto will cause issues in the
future when we want to return multiple concrete types from a function
that takes a single variant. The alternative would be both receiving a
variant as a parameter and then returning another variant as a result,
but that is much less type safe.
2020-12-07 18:28:16 +01:00
7fb8cf97b1
Request factory after setting up callback handlers
...
Otherwise we'll get a deadlock.
2020-12-07 18:28:16 +01:00
c2503f8aaa
Send the factory from the Wine host to the plugin
2020-12-07 18:28:16 +01:00
79c6f02d91
Request and deserialize plugin factory from plugin
2020-12-07 18:28:16 +01:00
d5374e4540
💥 Rework Vst3MessageHandler
...
- Now allows direct deserialization into existing objects. This will be
necessary for our VST3 implementations since the interface instances
we'll deserialize into will not be trivially constructable because
they have to be able to do callbacks.
- `ControlResponse` and `CallbackResponse` were dropped. These response
enums are not necessary because of the `T::Response` associated type
and returning the types directly makes the direct deserialization
possible.
2020-12-07 18:28:16 +01:00
049eb257c5
Make YaPluginFactory abstract
...
And add separate implementations for the native plugin and the Wine
plugin host. This way we can easily allow the native host to do
callbacks without having to manage a load of lambdas.
2020-12-07 18:28:16 +01:00
930ebbf7d1
Add more todos for VST3 handling
2020-12-07 18:28:16 +01:00
426231a22b
Avoid potential UB in loggers using composition
...
This cast would work fine, but any other fields added to those loggers
would be left uninitialized.
2020-12-07 18:28:16 +01:00
c1e7f53cd0
💥 Major refactor of initialization plumbing
...
To account for the differences in VST2 plugins and VST3 modules we had
to wrap most of our old functions from `src/plugin/utils.h` in a new
`PluginInfo` struct that gathers all of this information while taking
into account the differences between VST2 and VST3 plugins.
With this change things are also a lot more organized. We can just query
the plugin information we need rather than having to store things
separately or having to recalculate things. This also moved the
responsibility of all the weird `WINEPREFIX` behaviour to a single place
instead of having it spread around `utils.pp`, the initialisation
message, and `host-procoess.cpp`.
2020-12-07 18:28:16 +01:00
0819e9fda9
Request/send config for VST3 plugins
...
Using the new Vst3MessageHandler.
2020-12-07 18:28:16 +01:00
2e9b100090
Add handlers for control messages and callbacks
2020-12-07 18:28:16 +01:00
b9e63ea335
Move the host guard handler to PluginBridge
2020-12-07 18:28:16 +01:00
c2d2ac8fbf
Inherit Vst3PluginBridge init from PluginBridge
2020-12-07 18:28:16 +01:00
6b9ae78b27
Factor out all plumbing in Vst2PluginBridge
...
So we can reuse it in Vst3PluginBridge later.
2020-12-07 18:28:16 +01:00
f845763af0
Print the plugin type during initialisation
2020-12-07 18:28:16 +01:00
c57fd67aa8
Don't store the Wine version as a field
...
It's only needed for the initialisation message, and it doesn't throw so
doing this later shouldn't make a difference.
2020-12-07 18:28:16 +01:00
3c72ab31f8
Shut up clang/ccls
2020-12-07 18:28:16 +01:00
ff2807c939
Add all the boilerplate for the Vst3PluginBridge
...
And now that I also have an idea of what the communication model will
look like, this can server as a base for instantiating plugins.
2020-12-07 18:28:16 +01:00
0b462c034e
Allow loading VST3 modules
...
Doesn't actually work yet or do anything, but it compiles and it runs.
2020-12-07 18:28:16 +01:00
a9b7a6a835
List VST3 support in the initialization message
2020-12-07 18:28:16 +01:00
969ad75da5
Add some more VST3 implementation considerations
2020-12-07 18:28:16 +01:00
2060606864
Add a list of things to watch out for with VST3
2020-12-07 18:28:16 +01:00
f9a1bcd7bd
Split VST2 specific functionality into Vst2Logger
2020-12-07 18:28:16 +01:00
2230b5099f
Move logger to common/logging/common.h
2020-12-07 18:28:16 +01:00
278cd2e710
Spawn all hosts directly using HostRequest
...
This way we can set the plugin type inside of the `Vst*PluginBridge`
instance.
2020-12-07 18:28:16 +01:00
e21d3e020f
Rename GroupRequest to HostRequest
...
We'll also use this to encode information in when launching
`yabridge-host.exe` for individually hosted plugins.
2020-12-07 18:28:16 +01:00
1c5a9423d2
Print the plugin type on initialization
2020-12-07 18:28:16 +01:00
f9bb3822de
Pass plugin type when calling the host application
2020-12-07 18:28:16 +01:00
47baef3107
Rename architecture related functions and structs
2020-12-07 18:28:16 +01:00
7fc7a51a46
Move PluginArchitecture to common
...
Along with the accompanying function to parse a PE32 file. We're going
to have to define some common tags for different plugin types.
2020-12-07 18:28:16 +01:00
fa719c286d
Create base class for sockets and derive from that
...
Now the host launching procedure can be agnostic of the socket
implementation.
2020-12-07 18:28:16 +01:00
5b2221b251
Add a (nonfunctional) VST3 entry point
2020-12-07 18:28:16 +01:00
bb85d99657
Rename 'Sockets' to 'Vst2Sockets'
2020-12-07 18:28:16 +01:00
2fbd14908a
Split communication/vst2.h into common and VST2
...
So we can reuse the generic bits for our VST3 implementation.
2020-12-07 18:28:16 +01:00
Robbert van der Helm