ardour/livetrax
13
0
Fork 0
Code

make comment about discovering plugins in the main thread more accurate

Browse Source
This commit is contained in:
Paul Davis 2019-10-25 12:20:10 -06:00
parent c6b8fc78c8
commit a53448846b
1 changed files with 11 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
gtk2_ardour/plugin_scan_dialog.cc
View File

@ -84,12 +84,17 @@ PluginScanDialog::start ()
* read this and think about it carefully if you are confused.
*
* Plugin discovery must take place in the main thread of the
* process. This is not true for all plugin APIs but it is true for VST
* and AU. This means that the PluginManager::refresh() call MUST be
* made from the main thread (typically the GUI thread, but certainly
* the thread running main()). Failure to do this will cause crashes,
* undefined behavior and other undesirable stuff (because plugin APIs
* failed to specify this aspect of the host behavior).
* process. This is not true for all plugin APIs but it is true for
* VST. For AU, although plugins themselves do not care, Apple decided
* that Cocoa must be "invoked" from the main thread, so if the plugin
* decides to show any kind of "registration" GUI, then again,
* discovery must be done in the main thread.
*
* This means that the PluginManager::refresh() call MUST be made from
* the main thread (typically the GUI thread, but certainly the thread
* running main()). Failure to do this will cause crashes, undefined
* behavior and other undesirable stuff (because plugin APIs failed to
* specify this aspect of the host behavior).
*
* The ::refresh call is likely to be slow, particularly in the case of
* VST(2) plugins where we are forced to load the shared object do