Postponed destructor call by host

[hq9000]

Hi there,

I'm developing a VST plug and just discovered that under Sonar host the desctructor of the VST object is not called at the moment I remove the effect from the track. Insted, it is called at some (undefined) point in the future.

1. is it a known fact about Sonar (and maybe other hosts?)
2. in this case, can I as a plug developer somehow know when the user deletes the instance (I thought it's the moment of object's destruction, but apparantly it may be not)

Thanks!

[MadBrain]

Sonar might be keeping it in case the user undoes the deleting, or putting off the deleting until there is less CPU usage (presumably when there is no more sound playing or while doing another long non-realtime operation). I haven't heard of a VST callback or signal to tell you that your machine is eventually going to be deleted.

[hq9000]

...or putting off the deleting until there is less CPU usage (presumably when there is no more sound playing or while doing another long non-realtime operation).

This is most probable. I dont see any sign of reusing of not-yet-deleted objects in the case of undoing.

[MackTuesday]

For my own future knowledge, how does this host behavior affect the operation of your plugin? Is it harmful somehow?

[nollock]

2. in this case, can I as a plug developer somehow know when the user deletes the instance (I thought it's the moment of object's destruction, but apparantly it may be not)

Why would you want to know this?

[hq9000]

Why would you want to know this?

Instances of the plug have to communicate and once one of them get destroyed it affects in certain way the others... That's the reason... I hope that such behaviour is not common for hosts. Reaper, for instance, calls destructors immediatelly.

Like each isantance's display shows how many instances are present at the moment.

It isn't harmfull. Simply other instances would think that their neighbor is still alive, while it already isn't. Not harmfull but a little annoying for the user. I'm thinking about the ways to ease this.

[Minouris]

Just a suggestion- I don't have Sonar to test it with- but try putting the code to 'close down' your plugin (stop processes, free resources, etc) into the (overridden) AudioEffectX::close() method of your plugin instead of the destructor.

Likewise with the code to initialize it- if you override AudioEffectX::open() instead of your constructor (whilst using the constructor only for setting plugin capabilities and metadata instead of loading resources) then your plugin will be much kinder to hosts that call the constructor to build lists of available plugins as well.

But anyway... If you have your processing dependent on an 'isClosed' flag (similar to the one for bypassing), controlled from the open() and close() methods then that SHOULD *touch wood* fix your problem- you'll still have an instance of your class in memory, but it won't interfere with anything

[matt42]

Just a suggestion- I don't have Sonar to test it with- but try putting the code to 'close down' your plugin (stop processes, free resources, etc) into the (overridden) AudioEffectX::close() method of your plugin instead of the destructor.

You may need to be careful. I heard some hosts don't call close(). Although I haven't confirmed this, so don't know if this is true or not. Anyone know for sure?

[Minouris]

Just a suggestion- I don't have Sonar to test it with- but try putting the code to 'close down' your plugin (stop processes, free resources, etc) into the (overridden) AudioEffectX::close() method of your plugin instead of the destructor.

You may need to be careful. I heard some hosts don't call close(). Although I haven't confirmed this, so don't know if this is true or not. Anyone know for sure?

That's a bummer... You can work around it, though- have your destructor check to see if the 'isOpen' flag returns true, and if so, call close() from the destructor. That should cover most, if not all, bases.