make comment about discovering plugins in the main thread more accurate

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