delaying/deferlowing pattrstorage data restoration?

here's a solution:

obviously tailor it to your needs - it'd be more helpful if you uploaded a bit of your patcher so i could have a better idea of how you want to use it, and obviously other users might come up with much more elegant solutions.

Thanks for your reply - but I want to avoid using a fixed time (e.g. 1000 ms) to delay the second message, as some plugins take longer than that to load...

VST plug-ins and pictures-to-lcd can hardly be tracked.

but couldnt you, for example, send a request to the vst~ object every
50 ms or so, for example asking for parameter 7 (or playing a note
when it is an instrument), and when you get a response, it has finished
loading.

some things work, btw. i regulary use "plug name, open" and havent
seen plugs which refuse this.

Thanks Roman - yes, I think I've come to the same conclusion; I will have to store the program name temporarily, and then defer sending the request to vst~ to load it until I'm sure that the plugin has been loaded into it. I have some code that I use for this purpose that I derived from some very clever code that Andrew Pask sent me, that I will modify for use for this new purpose. No need for sending requests every 50 ms, etc... Basically, the code below will bang out the left of outlet of the select object when the plugin is done loading into the vst~ object:

could you explain with 2 words or post as patcher for lame max4 users like me (patch in 5 format will be fine)

btw, the funny thing is, even when you perform "plug, open", and a plugin
is loaded via open dialog by the user, the "open" still does not get lost.

so it is not an issue of the vst~ object that messages to the plug-in get
lost, it is one of the plug-ins. :)

I think the patch from Andrew is useful if you are interested in possible error messages. But otherwise a simple trigger object should do the trick.
Or am I missing something here?

@Roman - ah, now I see what you're getting at. In some limited testing just now, it *does* seem like a [plug Foobar.vst, 17] message to vst~ does in fact load the plugin, and then select program 17. Cool! Now have to go see if I can figure out how to get pattrstorage/presets working with this... BTW, an image of my patch above is posted below in case you're interested.

@broc - yes, that's the advantage of Andrew's suggestion - it allows you to pick up on when the vst~ object reports an error. This was especially important to me when developing code that scanned through a whole folder of plugins, to test their instrument vs. effect status (to be loaded into different umenus in my app).

Thanks guys!