delaying/deferlowing pattrstorage data restoration?

    Feb 06 2011 | 3:01 pm
    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...

    • Feb 06 2011 | 10:07 pm
      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.
    • Feb 07 2011 | 2:23 pm
      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...
    • Feb 07 2011 | 3:23 pm
      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.
    • Feb 07 2011 | 3:24 pm
      some things work, btw. i regulary use "plug name, open" and havent seen plugs which refuse this.
    • Feb 07 2011 | 5:52 pm
      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:
    • Feb 08 2011 | 7:18 am
      could you explain with 2 words or post as patcher for lame max4 users like me (patch in 5 format will be fine)
    • Feb 08 2011 | 7:20 am
      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. :)
    • Feb 08 2011 | 12:27 pm
      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?
    • Feb 08 2011 | 1:20 pm
      @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!
    • Feb 08 2011 | 6:13 pm
      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...
      Thanks for any help!
    • Feb 08 2011 | 6:14 pm
      Oh, and a picture of the patch for Roman. ;-)
    • Feb 08 2011 | 7:01 pm
      How about just storing the preset name or number in a message box until you know the plug is loaded?
    • Feb 08 2011 | 7:31 pm
      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.
    • Feb 09 2011 | 11:56 pm
      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 ?
    • Dec 01 2012 | 4:06 am
      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.
      Am I wrong on this?
    • Dec 02 2012 | 3:48 pm
      Yes, I believe you're wrong. :-)
      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).
    • Dec 02 2012 | 5:04 pm
      Then that begs the different question as to why we (and perhaps others) had the wrong impression?