Add CLAP whenever mentioning yabridge libs

This commit is contained in:
Robbert van der Helm
2022-08-23 15:36:05 +02:00
parent beed7963ec
commit 98bb4a019b
11 changed files with 22 additions and 22 deletions
+1 -1
View File
@@ -28,7 +28,7 @@
#include "utils.h"
// These chainloader libraries are tiny, mostly dependencyless libraries that
// `dlopen()` the actual `libyabridge-{vst2,vst3}.so` files and forward the
// `dlopen()` the actual `libyabridge-{clap,vst2,vst3}.so` files and forward the
// entry point function calls from this library to those. Or technically, these
// libraries use dedicated entry point functions because multiple chainloader
// libraries may all dynamically link to the exact same plugin library, so we
+1 -1
View File
@@ -28,7 +28,7 @@
#include "utils.h"
// These chainloader libraries are tiny, mostly dependencyless libraries that
// `dlopen()` the actual `libyabridge-{vst2,vst3}.so` files and forward the
// `dlopen()` the actual `libyabridge-{clap,vst2,vst3}.so` files and forward the
// entry point function calls from this library to those. Or technically, these
// libraries use dedicated entry point functions because multiple chainloader
// libraries may all dynamically link to the exact same plugin library, so we
+1 -1
View File
@@ -31,7 +31,7 @@
* they can share resources. Configuration file loading works as follows:
*
* 1. `load_config_for(path)` from `src/plugin/utils.h` gets called with a path
* to the copy of or symlink to `libyabridge-{vst2,vst3}.so` that the plugin
* to the copy of or symlink to `libyabridge-{clap,vst2,vst3}.so` that the plugin
* host has tried to load.
* 2. We start looking for a file named `yabridge.toml` in the same directory as
* that `.so` file, iteratively continuing to search one directory higher
+1 -1
View File
@@ -23,7 +23,7 @@
/**
* Return a path to this `.so` file. This can be used to find out from where
* this copy of `libyabridge-{vst2,vst3}.so` or `libyabridge-chainloader-*.so`
* this copy of `libyabridge-{clap,vst2,vst3}.so` or `libyabridge-chainloader-*.so`
* was loaded so we can search for a matching Windows plugin library. When the
* chainloaders are used, this path should be passed to the chainloaded plugin
* library using the provided exported functions since they can't detect the
+4 -4
View File
@@ -45,7 +45,7 @@ struct PluginInfo {
public:
/**
* Locate the Windows plugin based on the location of this copy of
* `libyabridge-{vst2,vst3}.so` file and the type of the plugin we're going
* `libyabridge-{clap,vst2,vst3}.so` file and the type of the plugin we're going
* to load. For VST2 plugins this is a file with the same name but with a
* `.dll` file extension instead of `.so`. In case this file does not exist
* and the `.so` file is a symlink, we'll also repeat this check for the
@@ -184,9 +184,9 @@ std::string create_logger_prefix(
* Finds the Wine VST host (either `yabridge-host.exe` or `yabridge-host-32.exe`
* depending on the plugin). For this we will search in two places:
*
* 1. Alongside libyabridge-{vst2,vst3}.so if the file got symlinked. This is
* 1. Alongside libyabridge-{clap,vst2,vst3}.so if the file got symlinked. This is
* useful when developing, as you can simply symlink the
* `libyabridge-{vst2,vst3}.so` file in the build directory without having
* `libyabridge-{clap,vst2,vst3}.so` file in the build directory without having
* to install anything to /usr.
* 2. In the regular search path, augmented with `~/.local/share/yabridge` to
* ease the setup process.
@@ -228,7 +228,7 @@ ghc::filesystem::path generate_group_endpoint(
/**
* Load the configuration that belongs to a copy of or symlink to
* `libyabridge-{vst2,vst3}.so`. If no configuration file could be found then
* `libyabridge-{clap,vst2,vst3}.so`. If no configuration file could be found then
* this will return an empty configuration object with default settings. See the
* docstrong on the `Configuration` class for more details on how to choose the
* config file to load.
+1 -1
View File
@@ -41,7 +41,7 @@ static const std::string host_name = "yabridge host version " +
* plugin, or spawn a group host server.
*
* For the individual plugin situation this process will load the specified
* plugin plugin, and then connect back to the `libyabridge-{vst2,vst3}.so`
* plugin plugin, and then connect back to the `libyabridge-{clap,vst2,vst3}.so`
* instance that spawned this over the socket.
*
* For the group host case this process will act as a daemon yabridge plugin