Dan Nigrin

I have a pattrstorage that holds two values, one is the name of a VST plugin, the other is the name of a desired program within that VST plugin. This pattrstorage is linked to a preset object. When clicking various presets in the preset object, to restore the values properly, the VST plugin needs to loaded first into the vst~, then the desired program can be selected within it.

How do I make pattrstorage restore the VST plugin first, wait long enough for the plugin be loaded, and then restore the correct VST program?

What I've already done is to reduce the priority of the VST plugin within the pattrstorage object, so it gets restored first. I've then also tried to send the output of the pattr'd object that gets the plugin program name restored to it, to a deferlow object, and then on to the vst~ object. That didn't seem to work either...

I have a pattrstorage that holds two values, one is the name of a VST plugin, the other is the name of a desired program within that VST plugin.  This pattrstorage is linked to a preset object.  When clicking various presets in the preset object, to restore the values properly, the VST plugin needs to loaded first into the vst~, then the desired program can be selected within it.

What I've already done is to reduce the priority of the VST plugin within the pattrstorage object, so it gets restored first.  I've then also tried to send the output of the pattr'd object that gets the plugin program name restored to it, to a deferlow object, and then on to the vst~ object.  That didn't seem to work either...


delayingdeferlowing-pattrstorage-data-restoration

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

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

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:

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)

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

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.

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).

@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).

Ok, so still not successful in doing exactly what I want to. I've stripped down my patch to show better the dilemma - see below, instructions included in the patch.

An important aspect of this is the @changemode 1 attribute of the pattrstorage; this is important because I don't want to reload my vst~ all the time, if only changing the program, since it will lead to drop out of sound in my application, as the vst~ is reloaded...

Ok, so still not successful in doing exactly what I want to.  I've stripped down my patch to show better the dilemma - see below, instructions included in the patch.

Oh, and a picture of the patch for Roman. ;-)

Oh, and a picture of the patch for Roman.  ;-)

How about just storing the preset name or number in a message box until you know the plug is loaded?

Since I have @changemode set to 1, if I'm not changing the plugin between presets, then there is no loading event that I could detect to be complete prior to loading the stored program name. I suppose I could turn changemode off, and just use a change object to filter unnecessary re-loads of the plugin, but then all the other stuff that I'm storing in the presets (not shown in this patch) will get reloaded too, and I'd rather not do that if possible.

Since I have @changemode set to 1, if I'm not changing the plugin between presets, then there is no loading event that I could detect to be complete prior to loading the stored program name.  I suppose I could turn changemode off, and just use a change object to filter unnecessary re-loads of the plugin, but then all the other stuff that I'm storing in the presets (not shown in this patch) will get reloaded too, and I'd rather not do that if possible.


I am also very interested in this problem because i had a patch with a similar problem, but it was maybe even trickier : in fact when i recalled a preset, it would trigger a scripting message creating a new bpatcher, and then i needed to send stored datas into those newly created abstractions... the only solution i found was to have one pattrstorage in each bpatcher, and a loadbang in the bpatcher telling when it was done created, wich would trigger a preset recall inside the bpatchers. well... it was heavy and i needed to create a folder containing one json file for each pattrstorage inside each bpatcher.....

well, all that only to say that if there's a solution, it would be great.

maybe by sending a "getedited" to pattrstorage ?

Hi everyone,
I am also very interested in this problem because i had a patch with a similar problem, but it was maybe even trickier : in fact when i recalled a preset, it would trigger a scripting message creating a new bpatcher, and then i needed to send stored datas into those newly created abstractions... the only solution i found was to have one pattrstorage in each bpatcher, and a loadbang in the bpatcher telling when it was done created, wich would trigger a preset recall inside the bpatchers. well... it was heavy and i needed to create a folder containing one json file for each pattrstorage inside each bpatcher.....
well, all that only to say that if there's a solution, it would be great.

maybe by sending a "getedited" to pattrstorage ?


I've also gotten interested in replacing my custom storage mechanism with pattr now that I have a better understanding for how it works and I also need to know when a vst~ has finished loading.

I don't understand the example (from Andrew?) is supposed to work. From looking at it, it seems that (in order) it starts capturing error messages, sends the plug message to the vst, stops capturing error messages and leaves you with either "good" or "error".

However, it was my understanding that the problem with vst~ is that a plugin would be loaded asynchronously, i.e. max doesn't wait for a vst to load the plugin before continuing its normal event execution. Otherwise (ignoring possible errors for a moment), it would be trivial to know when the vst had finished loading as it would only be at that point that the next event would be generated from Max.

Your impression was always the one that I thought as well - but Andrew's code cleared things up for me. In that trigger object that you're referring to, the final leftmost bang doesn't happen until the plugin is successfully loaded (or not, triggering the "error" message).

Your impression was always the one that I thought as well - but Andrew's code cleared things up for me.  In that trigger object that you're referring to, the final leftmost bang doesn't happen until the plugin is successfully loaded (or not, triggering the "error" message).


Then that begs the different question as to why we (and perhaps others) had the wrong impression?

delaying/deferlowing pattrstorage data restoration?