make comment about discovering plugins in the main thread more accurate

diff --git a/gtk2_ardour/plugin_scan_dialog.cc b/gtk2_ardour/plugin_scan_dialog.cc
index 67d720045f79b6be0eebb0ed1b322e934ffdb9a7..942eba115a3c9eb40dd55a7744dd70f5f1b8a317 100644 (file)
--- 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