keepsound

Here the maxpath, try reproducing the issue. If the vst Gui remains open before closing the patch, the host app will crash. Closebang doesn't help. Happens with audio on or off, seems not related with it but only with the Gui, Any idea?

The issue happens on a created standalone app, but in Max by closing the maxpat too. (Every Max is affected, Max 6 or Max 7).

comment

message

loadmess

closebang

toggle

dac~

cycle~

vst~

Here the maxpath, try reproducing the issue. If the vst Gui remains open before closing the patch, the host app will crash. Closebang doesn't help. Happens with audio on or off, seems not related with it but only with the Gui,  Any idea?
The issue happens on a created standalone app, but in Max by closing the maxpat too. (Every Max is affected, Max 6 or Max 7).
Thanx
Italo


Here the maxpath, try reproducing the issue. If the vst Gui remains open before closing the patch, the host app will crash. Closebang doesn'

closing-a-vst-without-closing-before-his-gui-will-crash-the-app-«if-standalone»-or-max-«if-maxpat»

Schermata 2017-11-04 alle 18.05.03.png

I can confirm that there seems to be a problem (on Mac) (latest version of everything) with closing the vst~ object GUI window. 

If you close the window by clicking on the red window button (top right), Max almost always crashes. On the other hand, if I use the [wclose] method I don't have the problem. This seems be slightly less likely to happen with older versions of vsts - eg AudioDamage are gradually updating their plugins; the older ones don't seem to have this problem, but the newer versions definitely do.

I can confirm that there seems to be a problem (on Mac) (latest version of everything) with closing the vst~ object GUI window. 
If you close the window by clicking on the red window button (top right), Max almost always crashes. On the other hand, if I use the [wclose] method I don't have  the problem. This seems  be slightly less likely to happen with older versions of vsts - eg AudioDamage are gradually updating their plugins; the older ones don't seem to have this problem, but the newer versions definitely do.

Seem to me too that the older plugs are less affected by this issue. Will try it with a very old one, but in most cases the old ones are also little plugs, with a little gui. Seems the vst obj has no time to resolve the wclose and then the quitting of himself. But there's no other way to delay the app quitting. I can solve the issue with a workaround, (trigger a wclose and then a delayed 500 ms message to max with the message ;max quit, but this doesn't solve the problem, you can always quit the app using the normal quit comand in the menu, or the red dot, or the shortcut cmd-q.... I hope only in a revision of the vst~ obj.

Thanks to try it.
Seem to me too that the older plugs are less affected by this issue. Will try it with a very old one, but in most cases the old ones are also little plugs, with a little gui. Seems the vst obj has no time to resolve the wclose and then the quitting of himself. But there's no other way to delay the app quitting. I can solve the issue with a workaround,  (trigger a wclose and then a delayed 500 ms message to max with the message ;max quit, but this doesn't solve the problem, you can always quit the app using the normal quit comand in the menu, or the red dot, or the shortcut cmd-q.... I hope only in a revision of the vst~ obj.


closing the vst window is for sure not thread safe. did you try to insert 1000 ms of delay before closing the window? (yeah i know, this wont help much when the user closes the patcher window)

Seems happens only in Max @ 64Bit. With new or old plugs.

Not tried yet, but I will do it. (Maybe tonight). I'll let you know here.

Not tried yet, but I will do it. (Maybe tonight). I'll let you know here.
Best regards.

In Max8 seems that the VST2 (64bit) are ok for now, but this issue happens now to the VST3s...

Closing a VST without closing before his GUI, will crash the app (if standalone) or Max (if maxpat)