Fix new vst crash on editor close introduced in r1277. I didn't fully study this but I think we should just turn off midi learning as one of the first orders of business since it makes so many calls. Fixed some typos too.

Author: tom7

dfx-library/dfxplugin-vst.cpp

@@ -356,7 +356,7 @@ void DfxPlugin::getParameterName(VstInt32 index, char* name)
 }
 
 //-----------------------------------------------------------------------------
-// numerical display of each parameter's gradiations
+// numerical display of each parameter's gradations
 void DfxPlugin::getParameterDisplay(VstInt32 index, char* text)
 {
 	if (!text)

dfx-library/dfxplugin.cpp

@@ -272,7 +272,7 @@ void DfxPlugin::do_PreDestructor()
 #if TARGET_PLUGIN_HAS_GUI
 	// The destructor of AudioEffect will delete editor if it's non-null, but
 	// it looks like DfxGuiEditor wants to be able to still access the effect
-	// during its own destructor. Maybe it's just wong that it's doing that,
+	// during its own destructor. Maybe it's just wrong that it's doing that,
 	// but if not, then we should destroy the editor now before the effect
 	// instance becomes invalid.
 	if (auto* e = editor)

dfxgui/dfxguieditor.cpp

@@ -178,6 +178,12 @@ void DfxGuiEditor::close()
 {
 	mJustOpened = false;
 
+#if TARGET_PLUGIN_USES_MIDI
+	// This uses the effect instance and forwards messages all around, so get this done
+	// before we invalidate anything...
+	setmidilearning(false);
+#endif
+	
 	CloseEditor();
 
 	frame->unregisterMouseObserver(this);
@@ -194,11 +200,7 @@ void DfxGuiEditor::close()
 	{
 		frame_temp->forget();
 	}
-
-#if TARGET_PLUGIN_USES_MIDI
-	setmidilearning(false);
-#endif
-
+	
 	TARGET_API_EDITOR_BASE_CLASS::close();
 }
 

notes/notes2020.txt

@@ -598,3 +598,26 @@ problems still:
        second click opens another plugin window. I can actually get as many as I want this way. Doesn't
        seem like a practical issue without the modals, but maybe we should prevent it from happening?)
 
+
+== crash on plugin close ==
+
+Bisected. This was introduced in r1277 (thankfully it is not the windows update or something like that...!)
+
+Possible causes?
+ - some possibly substantive changes in DfxPlugin::getProgramName
+ - maxparamstrlen + 1 changes in getParameterDisplay could be related to fixed buffer I just noted?
+   (probably not called on close though?)
+ - there are some std::find calls etc. that I didn't verify but they didn't seem related   
+ - removed bogus call to setmidilearning(false) in ~DfxGuiEditor(). This is certainly proximal, but how
+   would *removing* this call cause problems?
+     ... aha, it was moved to the close() call, so this could be it. seems confirmed by tracing.
+     I guess this must be from some call to close() other than in the destructor, or because we need
+     to run the base class close() first.
+     And actually this is a *different* problem than before. This is not getting called during the plugin
+     destructor (after all we're just closing the editor window), it's just a normal call to close(). But
+     it looks like something earlier in close() is invalidating something (mControlsList perhaps?) that
+     setmidilearning (which kicks off a cascade of calls, including some overridable ones) is implicitly
+     relying on. Seems appropriate to just turn off midi learning as one of the first steps of closing.
+     Moving the call up fixes the issue so that's good enough for me.
+
+