[Solved] Crash with VST effect GUI

[Impostor]

When having a GUI from a vst effect open in the current project, MusE crashes when loading a new project.

The only vst effects I have are U-he's Uhbik (demo versions) and Protoverb, and they all lead to a crash.

Edit: the arctican vst effect plugins also lead to a crash. Also the HY-filter4free.so.

[Impostor]

Also, removing a vst effect while the GUI is open leads to a crash.

[Impostor]

This seems to be solved in the "fix vst params" branch.

Edit: Well, most of the time anyway :)

[Tim E. Real]

From my extensive notes:

"FIX: Crashes with open native VST UIs when exiting app, because we delete on close.
Removed close() call in _{VstNativeEditor}(), and changed "delete editor" to "editor->close()"
in VstNativeSynthIF::deactivate3().
Testing OK so far!
TODO: Try testing loading another song to be sure our cleanups work OK."

I'll try to update the branch soon.
Among the many things going on there, I'm fixing rack plugin drag n' drops (both move and copy),
and have implemented full undo/redo for all rack operations (add, remove, drag etc.).

Another teaser regarding song files:
" ** FIXED: Do not store or recognize initial parameters if custom data is present. From code:
// Do not store controls or parameters if the plugin has custom configuration (vst chunks or lv2 etc).
// The assumption is that control or parameter values would be included in the custom data.
// This is in fact alluded to in the vst spec. It says chunks can store the whole state, but if chunks
// are not used then an alternative is to store the parameter values. So it does not directly state
// that these values ARE to be stored in the chunks, but it can be inferred although it is possible
// some idiot plugins might not do it. Well too bad, we're going with this.
// One of the things this should fix is complaints that some plugins immediately show an indicator
// that they have been 'modified'. It's because we were sending all these parameters along with
// (after) the custom data.
// TODO: Watch out for DSSI though, its concept of custom data might not include controls if I recall. (DSSI-VST ???)
Someone in forum complained that some VSTs were showing 'modified' or 'dirty' because all the controls were being set!
I think I observed it.
This is another important reason to not set controls if there is custom data."

And another teaser:
"FIXED: Editing track name does not change in native UI window.
Fixed for generic UIs, DSSI (close them), LV2 and native VST."

Well, I could go on...

Thanks. Enjoy your day.
T.

[Impostor]

Don't know if bug reports regarding the current branch are at all useful, since it's a work in progress, but I encounter the following behaviour:

-Start new project.
Add vst effect (e.g. Uhbik-A).
Open GUI, save project. Close GUI, save again.
Reload project or restart MusE (set to open most recent project): project is opened with an open Uhbik GUI even though the latest save was done while the GUI was closed.

-Then I tried the same with another vst effect (HY-Filter4 free):
Open GUI, save project. Close GUI, save again. Reload project: MusE crashes*).
But MusE does not crash if I save the project with an open GUI, and then reload the project.

*)

Code: Select all

 The program 'muse4' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 834 error_code 3 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

[Tim E. Real]

OK Thanks, will keep an eye on that.