diff options
-rw-r--r-- | gtk2_ardour/plugin_scan_dialog.cc | 17 |
1 files changed, 11 insertions, 6 deletions
diff --git a/gtk2_ardour/plugin_scan_dialog.cc b/gtk2_ardour/plugin_scan_dialog.cc index 67d720045f..942eba115a 100644 --- a/gtk2_ardour/plugin_scan_dialog.cc +++ b/gtk2_ardour/plugin_scan_dialog.cc @@ -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 |