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.