Add control sockets to Vst3Sockets

This commit is contained in:
Robbert van der Helm
2020-12-04 13:32:58 +01:00
parent 170cd53c27
commit ab7449a0e0
2 changed files with 39 additions and 10 deletions
+5 -3
View File
@@ -412,10 +412,14 @@ class SocketHandler {
*
* @tparam Thread The thread implementation to use. On the Linux side this
* should be `std::jthread` and on the Wine side this should be `Win32Thread`.
*
* TODO: Once we have figured out a way to encapsulate the usage patterns in
* `Vst3Sockets` we should make the constructor, `send()` and
* `receive_multi()` protected again to avoid weirdness
*/
template <typename Thread>
class AdHocSocketHandler {
protected:
public:
/**
* Sets up a single primary socket. The sockets won't be active until
* `connect()` gets called.
@@ -441,7 +445,6 @@ class AdHocSocketHandler {
}
}
public:
/**
* Depending on the value of the `listen` argument passed to the
* constructor, either accept connections made to the sockets on the Linux
@@ -474,7 +477,6 @@ class AdHocSocketHandler {
socket.close();
}
protected:
/**
* Serialize and send an event over a socket. This is used for both the host
* -> plugin 'dispatch' events and the plugin -> host 'audioMaster' host
+34 -7
View File
@@ -55,20 +55,47 @@ class Vst3Sockets : public Sockets {
Vst3Sockets(boost::asio::io_context& io_context,
const boost::filesystem::path& endpoint_base_dir,
bool listen)
: Sockets(endpoint_base_dir) {}
: Sockets(endpoint_base_dir),
host_vst_control(io_context,
(base_dir / "host_vst_control.sock").string(),
listen),
vst_host_callback(io_context,
(base_dir / "vst_host_callback.sock").string(),
listen) {}
~Vst3Sockets() { close(); }
void connect() override {}
void connect() override {
host_vst_control.connect();
vst_host_callback.connect();
}
void close() override {
// Manually close all sockets so we break out of any blocking operations
// that may still be active
host_vst_control.close();
vst_host_callback.close();
}
// TODO: I still don't know if recursive callbacks are a thing in VST3. If
// not, then we should probably have two `AdHocSocketHandler`s per
// plugin instance (one for each direction, as with `dispatcher()` and
// `audioMaster()` in VST2). Using fewer probably also works, but we
// wouldn't want to have to spawn new sockets during audio processing.
// TODO: Since audio processing may be done completely in parallel we might
// want to have a dedicated socket per processor/controller pair. For
// this we would need to figure out how to associate a plugin instance
// with a socket.
/**
* For sending messages from the host to the plugin. After we have a better
* idea of what our communication model looks like we'll probably want to
* provide an abstraction similar to `EventHandler`.
*
* This will be listened on by the Wine plugin host when it calls
* `receive_multi()`.
*/
AdHocSocketHandler<Thread> host_vst_control;
/**
* For sending callbacks from the plugin back to the host. After we have a
* better idea of what our communication model looks like we'll probably
* want to provide an abstraction similar to `EventHandler`.
*/
AdHocSocketHandler<Thread> vst_host_callback;
};