vanja/yabridge
1
0
Fork 0
mirror of https://github.com/robbert-vdh/yabridge.git synced 2026-05-07 03:50:11 +02:00
Code Issues Packages Projects Releases Wiki Activity

Prefix top level VST3 message types

Browse Source 
CLAP will use a similar structure. Alternatively we could use
namespaces, but while that would solve clashes for the linker with the
way namespaces in C++ work it would still be ambiguous which one is
being referred to just looking at the code.
This commit is contained in:
Robbert van der Helm
2022-08-24 13:42:47 +02:00
parent 5b4dbdd890
commit 6df0741195
4 changed files with 26 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/common/communication/common.h
+6 -6
View File
@@ -905,8 +905,8 @@ class AdHocSocketHandler {
/**
* An instance of `AdHocSocketHandler` that encapsulates the simple
* communication model we use for sending requests and receiving responses. A
* request of type `T`, where `T` is in the `{Control,Callback}Request` variatns
* for the plugin format, should be answered with an object of type
* request of type `T`, where `T` is in the `*{Control,Callback}Request`
* variants for the plugin format, should be answered with an object of type
* `T::Response`.
*
* See the docstrings on `Vst2EventHandler` and `AdHocSocketHandler` for more
@@ -918,7 +918,7 @@ class AdHocSocketHandler {
* @tparam LoggerImpl The logger instead to use. This should have
* `log_request(bool, T)` methods for every T in `Request`, as well as
* corresponding `log_response(bool, T::Response)` methods.
* @tparam Request Either `ControlRequest` or `CallbackRequest`.
* @tparam Request Either `Vst3ControlRequest` or `Vst3CallbackRequest`.
*/
template <typename Thread, typename LoggerImpl, typename Request>
class TypedMessageHandler : public AdHocSocketHandler<Thread> {
@@ -1114,8 +1114,8 @@ class TypedMessageHandler : public AdHocSocketHandler<Thread> {
auto [logger, is_host_plugin] = *logging;
return logger.log_request(is_host_plugin, object);
},
// In the case of `AudioProcessorRequest`, we need to
// actually fetch the variant field since our object
// In the case of `Vst3AudioProcessorRequest`, we need
// to actually fetch the variant field since our object
// also contains a persistent object to store process
// data into so we can prevent allocations during audio
// processing
@@ -1153,7 +1153,7 @@ class TypedMessageHandler : public AdHocSocketHandler<Thread> {
/**
* Get the actual variant for a request. We need a function for this to be able
* to handle composite types, like `AudioProcessorRequest` that use
* to handle composite types, like `Vst3AudioProcessorRequest` that use
* `MesasgeReference` to be able to store persistent objects in the message
* variant. This function should be specialized for those kinds of types.
*/
src/common/communication/vst3.h
+6 -6
View File
@@ -128,10 +128,10 @@ class Vst3Sockets final : public Sockets {
* that the native plugin already tries to connect to the socket before
* Wine plugin host is even listening on it.
* @param cb An overloaded function that can take every type `T` in the
* `AudioProcessorRequest` variant and then returns `T::Response`.
* `Vst3AudioProcessorRequest` variant and then returns `T::Response`.
*
* @tparam F A function type in the form of `T::Response(T)` for every `T`
* in `AudioProcessorRequest::Payload`.
* in `Vst3AudioProcessorRequest::Payload`.
*/
template <typename F>
void add_audio_processor_and_listen(
@@ -189,7 +189,7 @@ class Vst3Sockets final : public Sockets {
* and thread for handling those. These calls also always reuse buffers to
* minimize allocations.
*
* @tparam T Some object in the `AudioProcessorRequest` variant.
* @tparam T Some object in the `Vst3AudioProcessorRequest` variant.
*/
template <typename T>
typename T::Response send_audio_processor_message(
@@ -239,7 +239,7 @@ class Vst3Sockets final : public Sockets {
* This will be listened on by the Wine plugin host when it calls
* `receive_multi()`.
*/
TypedMessageHandler<Thread, Vst3Logger, ControlRequest>
TypedMessageHandler<Thread, Vst3Logger, Vst3ControlRequest>
host_plugin_control_;
/**
@@ -247,7 +247,7 @@ class Vst3Sockets final : public Sockets {
* better idea of what our communication model looks like we'll probably
* want to provide an abstraction similar to `Vst2EventHandler`.
*/
TypedMessageHandler<Thread, Vst3Logger, CallbackRequest>
TypedMessageHandler<Thread, Vst3Logger, Vst3CallbackRequest>
plugin_host_callback_;
private:
@@ -284,7 +284,7 @@ class Vst3Sockets final : public Sockets {
*/
std::unordered_map<
size_t,
TypedMessageHandler<Thread, Vst3Logger, AudioProcessorRequest>>
TypedMessageHandler<Thread, Vst3Logger, Vst3AudioProcessorRequest>>
audio_processor_sockets_;
std::mutex audio_processor_sockets_mutex_;
};
src/common/serialization/vst3.h
+13 -13
View File
@@ -51,9 +51,9 @@
/**
* When we send a control message from the plugin to the Wine plugin 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::Response`.
* request of type `Vst3ControlRequest(T)` should send back a `T::Response`.
*/
using ControlRequest =
using Vst3ControlRequest =
std::variant<Vst3PluginFactoryProxy::Construct,
Vst3PlugViewProxy::Destruct,
Vst3PluginProxy::Construct,
@@ -136,8 +136,8 @@ using ControlRequest =
YaXmlRepresentationController::GetXmlRepresentationStream>;
template <typename S>
void serialize(S& s, ControlRequest& payload) {
// All of the objects in `ControlRequest` should have their own
void serialize(S& s, Vst3ControlRequest& payload) {
// All of the objects in `Vst3ControlRequest` should have their own
// serialization function
s.ext(payload, bitsery::ext::InPlaceVariant{});
}
@@ -156,15 +156,15 @@ void serialize(S& s, ControlRequest& payload) {
* without needing to create copies. See `MessageReference<T>` and
* `bitsery::ext::MessageReference<T>` for more information.
*/
struct AudioProcessorRequest {
AudioProcessorRequest() {}
struct Vst3AudioProcessorRequest {
Vst3AudioProcessorRequest() {}
/**
* Initialize the variant with an object. In `Vst3Sockets::send_message()`
* the object gets implicitly converted to the this variant.
*/
template <typename T>
AudioProcessorRequest(T request) : payload(std::move(request)) {}
Vst3AudioProcessorRequest(T request) : payload(std::move(request)) {}
using Payload =
std::variant<YaAudioProcessor::SetBusArrangements,
@@ -229,17 +229,17 @@ struct AudioProcessorRequest {
*
* @overload
*/
inline AudioProcessorRequest::Payload& get_request_variant(
AudioProcessorRequest& request) noexcept {
inline Vst3AudioProcessorRequest::Payload& get_request_variant(
Vst3AudioProcessorRequest& request) noexcept {
return request.payload;
}
/**
* When we do a callback from the Wine plugin host to the plugin, this encodes
* the information we want or the operation we want to perform. A request of
* type `CallbackRequest(T)` should send back a `T::Response`.
* type `Vst3CallbackRequest(T)` should send back a `T::Response`.
*/
using CallbackRequest =
using Vst3CallbackRequest =
std::variant<Vst3ContextMenuProxy::Destruct,
WantsConfiguration,
YaComponentHandler::BeginEdit,
@@ -272,8 +272,8 @@ using CallbackRequest =
YaUnitHandler2::NotifyUnitByBusChange>;
template <typename S>
void serialize(S& s, CallbackRequest& payload) {
// All of the objects in `CallbackRequest` should have their own
void serialize(S& s, Vst3CallbackRequest& payload) {
// All of the objects in `Vst3CallbackRequest` should have their own
// serialization function.
s.ext(payload, bitsery::ext::InPlaceVariant{});
}
src/wine-host/bridges/vst3.cpp
+1 -1
View File
@@ -1628,7 +1628,7 @@ size_t Vst3Bridge::register_object_instance(
// NOTE: To prevent allocations we keep this actual
// `YaAudioProcessor::Process` object around as
// part of a static thread local
// `AudioProcessorRequest` object, and we only
// `Vst3AudioProcessorRequest` object, and we only
// store a reference to it in our variant (this is
// done during the deserialization in
// `bitsery::ext::MessageReference`)