Hi Jo,
In my "-deleted-" thread, I'd observed that adding a VST for the second time in MuLab caused it to crash. The VST in question is JamtabaVST2. I've now checked and the release version similarly fails to be added if removed from a project and then added again. In fact, using MuLab's "delete" on the VST within the project does not actually stop it running. It doesn't stop until the project is closed.
When trying the same in Reaper (my only other VST hosting software), removing the plugin from the rack had the same effect as closing the MuLab project. (Basically calling the VST plugin destructor, which caused it to tidy up.)
Personally, I think it's a failure in JamataVST2 not to handle this more neatly (if it wants to keep running, it should re-instantiate neatly rather than returning an - unlogged! - error to the host). However, I was wondering if there's any reason why the plugin destructor isn't called in MuLab.
Cheers,
-- Peter
[Dev question] Removal of VST from Rack
-
- KVRAF
- 7412 posts since 8 Feb, 2003 from London, UK
-
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
Note that deleting a VST from a rack is an undoable action, so the VST is not yet immediately destructed.
-
- KVRAF
- Topic Starter
- 7412 posts since 8 Feb, 2003 from London, UK
I'd have thought there were two "things" here -- MuLab's view of the VST and the VST itself. For undo, you need to know MuLab's view of the VST (i.e. what would get saved to the project file). Given that, the VST should be able to sort itself out. I'm not sure I understand why you can't throw away the actual VST instance itself and create a new one when needed, passing in its saved stated (as when loading the project file).
The Jamtaba author tells me he's tried the same action in further hosts (Sonar, Studio One, Cubase) in addition to Reaper and it works in those by calling the VST destructor when the VST is removed from the project, hence his expectation that this is the normal approach.
Note that it is an error for Jamtaba to be exist twice in one project, so it tries to keep track of that with a static state variable - once set, it will fail to start again.
The Jamtaba author tells me he's tried the same action in further hosts (Sonar, Studio One, Cubase) in addition to Reaper and it works in those by calling the VST destructor when the VST is removed from the project, hence his expectation that this is the normal approach.
Note that it is an error for Jamtaba to be exist twice in one project, so it tries to keep track of that with a static state variable - once set, it will fail to start again.
-
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
-
- KVRAF
- Topic Starter
- 7412 posts since 8 Feb, 2003 from London, UK
There's also the overhead of holding potentially huge amounts of data in memory unnecessarily. If I load a 4Gb instrument into Kontakt, then decide not to use it, I don't really want that 4Gb of RAM continuing to be taken up. Sure, if I undo, I have to wait whilst the saved state causes Kontakt to reload the library - it displays a progress screen, so I know what's happening (that happens in Reaper when I hit undo).
However, most VSTs I've used (not very many), instantiate in "no time" (user perspective - probably 10s of ms, a long time in CPU terms).
Anyway, I've got a work around for my testing -- just reload "New" rather than deleting the plugin.
However, most VSTs I've used (not very many), instantiate in "no time" (user perspective - probably 10s of ms, a long time in CPU terms).
Anyway, I've got a work around for my testing -- just reload "New" rather than deleting the plugin.
-
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
The undo history is limited so the VST (and its eventual multi GB memory) will be really deleted after some time. If that's not fast enough you can also save and revert the project.