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 * @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`. * 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> template <typename Thread>
class AdHocSocketHandler { class AdHocSocketHandler {
protected: public:
/** /**
* Sets up a single primary socket. The sockets won't be active until * Sets up a single primary socket. The sockets won't be active until
* `connect()` gets called. * `connect()` gets called.
@@ -441,7 +445,6 @@ class AdHocSocketHandler {
} }
} }
public:
/** /**
* Depending on the value of the `listen` argument passed to the * Depending on the value of the `listen` argument passed to the
* constructor, either accept connections made to the sockets on the Linux * constructor, either accept connections made to the sockets on the Linux
@@ -474,7 +477,6 @@ class AdHocSocketHandler {
socket.close(); socket.close();
} }
protected:
/** /**
* Serialize and send an event over a socket. This is used for both the host * Serialize and send an event over a socket. This is used for both the host
* -> plugin 'dispatch' events and the plugin -> host 'audioMaster' 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, Vst3Sockets(boost::asio::io_context& io_context,
const boost::filesystem::path& endpoint_base_dir, const boost::filesystem::path& endpoint_base_dir,
bool listen) 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(); } ~Vst3Sockets() { close(); }
void connect() override {} void connect() override {
host_vst_control.connect();
vst_host_callback.connect();
}
void close() override { void close() override {
// Manually close all sockets so we break out of any blocking operations // Manually close all sockets so we break out of any blocking operations
// that may still be active // 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 // TODO: Since audio processing may be done completely in parallel we might
// not, then we should probably have two `AdHocSocketHandler`s per // want to have a dedicated socket per processor/controller pair. For
// plugin instance (one for each direction, as with `dispatcher()` and // this we would need to figure out how to associate a plugin instance
// `audioMaster()` in VST2). Using fewer probably also works, but we // with a socket.
// wouldn't want to have to spawn new sockets during audio processing.
/**
* 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;
}; };