mirror of
https://github.com/robbert-vdh/yabridge.git
synced 2026-05-07 03:50:11 +02:00
Use 'concurrent' instead of 'asynchronous'
While asynchronous is technically also correct, this makes it a bit clearer what's going on.
This commit is contained in:
+11
-11
@@ -11,17 +11,17 @@ Versioning](https://semver.org/spec/v2.0.0.html).
|
||||
### Added
|
||||
|
||||
- The way communication works in yabridge has been completely redesigned to be
|
||||
asynchronous and to use additional threads as necessary. This was needed to
|
||||
allow yabridge to handle nested and mutually recursive function calls as well
|
||||
as several other edge cases. What this boils down to is that yabridge became
|
||||
even faster, more responsive, and can now handle a few edge case scenarios
|
||||
that would previously require workarounds. This means that yabridge no longer
|
||||
requires the `hack_reaper_update_display` workaround for _REAPER_ and
|
||||
_Renoise_, that the loading issues in Bitwig Studio 3.3 beta 1 have also been
|
||||
resolved, and that certain plugins like Kontakt no longer interrupt playback
|
||||
in Bitwig while their editor is opening. I have been testing this extensively
|
||||
to make sure that the change does not introduce any regressions, but please
|
||||
let me know if this does break anything for you.
|
||||
fully concurrent and to use additional threads as necessary. This was needed
|
||||
to allow yabridge to handle nested and mutually recursive function calls as
|
||||
well as several other edge cases. What this boils down to is that yabridge
|
||||
became even faster, more responsive, and can now handle a few edge case
|
||||
scenarios that would previously require workarounds. This means that yabridge
|
||||
no longer requires the `hack_reaper_update_display` workaround for _REAPER_
|
||||
and _Renoise_, that the loading issues in Bitwig Studio 3.3 beta 1 have also
|
||||
been resolved, and that certain plugins like Kontakt no longer interrupt
|
||||
playback in Bitwig while their editor is opening. I have been testing this
|
||||
extensively to make sure that the change does not introduce any regressions,
|
||||
but please let me know if this does break anything for you.
|
||||
|
||||
TODO: Expand on this
|
||||
TODO: Remove known issue about opening Kontakt and certain other plugins
|
||||
|
||||
@@ -557,12 +557,12 @@ class EventHandler {
|
||||
/**
|
||||
* This acceptor will be used once synchronously on the listening side
|
||||
* during `Sockets::connect()`. When `EventHandler::receive()` is then
|
||||
* called, we'll recreate the acceptor asynchronously listen for new
|
||||
* incoming socket connections on `endpoint` using this same acceptor. This
|
||||
* is important, because on the case of `vst_host_callback` the acceptor is
|
||||
* first accepts an initial socket on the plugin side (like all sockets),
|
||||
* but all additional incoming connections of course have to be listened for
|
||||
* on the plugin side.
|
||||
* called, we'll recreate the acceptor to asynchronously listen for new
|
||||
* incoming socket connections on `endpoint` using. This is important,
|
||||
* because on the case of `vst_host_callback` the acceptor is first accepts
|
||||
* an initial socket on the plugin side (like all sockets), but all
|
||||
* additional incoming connections of course have to be listened for on the
|
||||
* plugin side.
|
||||
*/
|
||||
std::optional<boost::asio::local::stream_protocol::acceptor> acceptor;
|
||||
|
||||
|
||||
Reference in New Issue
Block a user