delaying/deferlowing pattrstorage data restoration?
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…
here’s a solution:
----------begin_max5_patcher---------- 1111.3oc0YFsjZCBEF953SASt15DfDzz65yQmc1AUVk1DvIA6tsc56dARhFM wDZzMa5typi.AO7w47eNv96Yd9qkuwx8AeF7Ufm2um44YaxzfW4m87SousIg laGl+FYZJSn7mWzmh8lx1NPsmAx361q9zdpXK3.MilxTrLfTn6imCRY44zcL fd9AzjWo+LGrQOzcrbvK7rb0bf44LSSB6kFyxUOgTv.4rMR8XRn59WTYPIbg t4iBqUQJa7.UsYOWr64L1FUwpk.WDLGfhCMuAiBLusJdQ.3oxmgu0ttjq+1m hvUy9KRgJm+KloKHR+LEMKNlxEILkEQvyMJOppZMn1LHzqI6j+kLNMw2zwel My7xbG2EDrW0FViMAEX84e8u8hGtboY8tLxtpIKhzjHn1ZuvtU+7.qX79q0T 2etiu2FBCiueDRFCDlHoaKVMcPuUFtEZccHVOGGnWqTgb+TA9PoRYPZCrf5f G3.rMHJz5NAWU85sAR6v3eJJC8ABCnCv.AuOX.mZvPI2sK4DK9AM6zTp6oK2 CDlXg.DWEozW7B2nd2BTvm7PZMt3PFKWmZhp3RwE6HE9kH6dQP4Kml+qX1iS IImk.B.PGHSHxpmPbTIolda6XJbHpJ2jdVhAIANPO76Y3WcWNcWvuhdpAyeQ dLqKfSr48fKsAmXjIw2.BNwQCI37V.FWTBxJhKtmiJfwMAr5UoCNzm36vD+v jGHeQwQeT7sSIytDFfjBaFe+RlH++gRIFSwup0XzxED8OqV9HU.Ct+5pFWsL XKgZ6yXrtB1JUlWAs.Lhni3FZ4Fn3GYDWYfeD7iVQ6r6nRlw.cVDaQBNH15U FtbffD9HktvDapADdhwwNq+Mrd0dCmiQSs5euTnqd.bhL4WMHkFMpLCtLW4Q 8QzAyJTDicPErclgeWOMYYO4zev19r96Sa9OaVj70GUE2gj2IzYVlYT82FWk J2xpcAHk8XtSmmYB55jK6bSBWGHTiMglCZqU1hVYpq.Ust87KYasgFsBqOOd rdbAX8i.iWBdxNX6N8CJw1A9Ac.PPPP+o1P5CdToLSvCcSE8+xohs4q.8TAN rHoEhDau5ovgJO.m1xC0jA9NHGj6fyB1lsLNXf9IjItax0U7zfTRAygpEqWr yPOdw+QoVRohloVnGURa5EP8taAZgEWqMLxlQIF5fq07Z+0Zf28mhIr2TL5p gL0YbcJE6glJ7FNmFvd4SUM1Ts2NP6+Tfq9ubXwko8K2Wx0xWapnQ0UzBNSr sZSiKrEpUePwWLn87saYh525eJe6Ao9LZkFQgk1vKwYaJ1AaBRFeaB1iMYt. uw1lP8YSnw2lv8s2EM91T3DbuKZhs2gcItaj4Db5YS3HGrIxE5Eu6lDY5YRt 3MYtK+wbmKzEahL91TuYVFWESjSYfGW0Iykd1KmPwiuM0GmF2stqxYbC2ofQ 0lfHGUmFOSJZ54fCISuTcvnomM4Dlf2QtN8G9yr+B4hazsC -----------end_max5_patcher-----------
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
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:
----------begin_max5_patcher---------- 717.3ocyWtsbaBCDF9Z7SwNp8R2LHjAiaupu.8EHSlLXPAqNfjKRXmCS5ydk VvINI1XWCwIWXNrRB1+O9kz5GF4QlqtkqIv2gKAOuGF44ggbA7Zu2iTlbaZQ hF6FIUUVxkFx3l1L7aMXbgbYsAVvq3fPCKKpyAYRIGtSUCqSjFvnfBUR1lAV Hj7TUsDGcPavaTRiVbO2Ei5egeaXYcoPVvMXFPeNnp1rI5lttLwjtPHyuthm ZZzUPj6IAQQtiTJdJX1E9vUsiQjgJPM+2eKfrUl3xerkeVIRJHtFdbzH2gw8 DVqzFPHEFfWUopHumpm42HX1jsfP7tU+D14Q9lEVKxkZdAjqTYWAySj4ZvpG nfeiAZDFrdAWhFIgDxTRNZerhCz0oob8M0EE2sS2D68jmzIwHOCvST1L2oIz 8.zoCKPk701G6a34FR1eiTPGSilFhB2uQwwcYjhocn61VZdql6Vxad9DmKfL FHD3pgCM2W.U77+GvDbhfgFiysXgcAlYgm.XFbnTYeE7gZsmtHyLJBiPzxDN sSxD8YfLCDSnGlILjFrftXB02+TfxIAjRtVmjyeCQvcx+Js+yf5fIQn+nce5 ILDIQ6CIzyFR1iGw.yAePCzAZM2vNLKMybn9HSlx51rDziEcEtsoalP0dIJt AfaqRpdJWLK3Waq8YW0C8296vldPGVLRv3NKBJ5TVhVKxktl29J2uBg17J7R d5kpSVsY7e4WtlZvfcT1Bcpkh+Tys40Xa0H.4Gu7SA9LvpddUw6n1cwe42Gs ptJcyK6o4Qvy.HiqMBYhQnja0KGK1pSKDYYb41EHUJxVprhqMK1ic43SJqE1 Nup6jBWU7rmUGBUy9HPE6SIpBNXVQ+.xpIGyGP5wmTrffKBcajyZJ6qYw4Wd WLtWOy2G6YL9uD5kTdkKa2JI97hWWkaG2zC5Y7St+wjTQ8.T1adbz+fjUKfN -----------end_max5_patcher-----------
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?
----------begin_max5_patcher---------- 472.3ocwU0zTBCCD8b6uhLQOVYZCeTPOoWcF+C333DZhknsIHIEAYze6lj1B EAJkQ.OPB8ks69duca6BWG3PwLpDBtF7HvwYgqiiEx.3TbsCLEOKJAKsgAiD ooTtB5kelhNSYwmPwj4kniwpnQLd7ySnQp7ri7Qs78.s6Ovr0w2rFzukO3oh 6gmkx3ITksLAEfuH3JI6SpEybOKiUjoJCtDkQrLQL70qF.qj.NN0l.3sSX3D vchDBzb5WttlEuFp7TpThioan760k.+lBUi3CB6azKpscqaaq36sKwiNDwW5 T4Pp4io4kDBWl7J9R3IvWRnjZk9f79dn0A7KWquu2PMxzChaSlcOl82wIYwf KCpSiCxms8yms68u0d6bBZub5G5Tugqn.CAxFLxGZG1aiZ08n87NZWdxPLOF 5sCuAc97loR02MXboicKveOuK7flWB2k2HYwbbhwcV8OyuDlTY1MOJU.sU6K Xe1WwwR7zxRdwClrkaF5BIvjLN68LpNqd5WZCf2nqTEW2VVMg3+9KRVOzfud qPJxlDUVrhwevJSjPkJFGqXBdkXBVKlQLBgxq9QjTFYrPaFETXMB5cvLJrAL BcVYDpALp6YmQA6gQc9CLRewWt+.iPsC5. -----------end_max5_patcher-----------
@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…
Thanks for any help!
----------begin_max5_patcher---------- 1461.3ocyYEsiiZCE84LeEVzGalHLPRftUUa+AlNR6nVUUUMxAbRbKXSwlYl zU69sWesABaBYBjIISeHgfwXe84dt26wNe9lQNKDuPkNne.8GnQi97MiFYZB ZXT08ibxHuDmRjlt4voOKV7WNisORQeQYZNUPRVP3qpe.uLSTpRoJyagqZMm nhWy3qdrfFqryJNLZh6XT.NDtL0C9F9M5OqdG6vn1jSsufiYZZd7RAWwIYlG 57yELRZsIvRLsos1aCBbZ0cI6eMcG6pmrFykwarVnsubyMvWi6IrjQkRxJ5d 3RdASTvTaP2mVthwknawmLDEX.mPCPgm8ZPz.gGuoCAd7NA3IVjkQ4p8fG+I n6DOijJQAEIEYTTdAUpmHToTCBnD1xkzB8ahxqvOBOQ2GwpBRlDIooZThlfH KDOQmfP+1ZJGAbQ3kWPh+aDiiHUC5XzFQI5YVZJhKTrXJRslnPrk5q0SLZMQ hTBT7ZMKiZefYlq5qDEWV.FT5Fy7PSFa5TsMY6lbsnLMAsfV0G38t6WdPafO XlIaW0MJ3MiSicXmtDAUBlo1fdhBVz1ASagOSSS2NZKRolQifTrLXkq.FzjI Spw6TFmFKJ4FPeVm7O2Cy+7lBLNeOr4xLKKLpE+qejrtiA8NewfGH0z2iFdH WfqYMim6YW5SldrrRL.bGFf38dE04MA86hxBzu9oGZhqn53pxbjgnqoRk5Wr 7Cnmg3IAmBrq5fsw.SkYiTLAtaCHMwBaPj7bJovNV5vZM0CFbXD6jPFLTBo+ LiywxKwQAvEfVNP7GeoIjGB+wSPeRQJzPnN2F5VDTQyjXiSdhshnLw6a10Cs TjlPK5DA8FJBhmgqqh.D64FVdvPQPbz6THsBs.I6Nn16UxiEEYWzy5aPsUQy fqmhmeokarnToD7AmVyyF4L0Dw34V+ce0Z0dINy4B6iE45TRZ7Urxv7Gt21t Vsb64gGWWI3nOAsk3Kt1xC.PZAK.DABWVxd4T4BXWCzLOnG.z.AFuKMvXkrU OKKJWnEB0LOcWUI3v.RnAOBrxbhLAG9uJdTO81h+i2sgNCavcG1r0pTEPMUX qDaWgRm2Lq4IRQiCqdP2iP0Z1azg+QqR3LQBEgQeTpUiZ9samEh7O081Lyx+ bcsaF7bRCcGDMrpQXcl7n980V5i.tvzobs6TdTCfq6lEsZsflF5qEiDAqE+. Pcx7ZycjSbJSKGnsLSXWcZZ1zPiVys8LmnkSQUzhGobhlU2pbd0CYblBbDlm Xdfgeb9XIkgQybc8i7C2inPJUBCYwYnwXdQ9FGbnwcOM53kfMkeq+LLOezo3 30zdPS6tN5psuaMJ2sNp6qT917fykqXuz7fnZdxv2IybCh6iMHdn+YOMe360 QqDmp2jwvK6Yyr640dmcmyCSIX9kdacG7rlVkAVmb3XhslW0kYtm8CXJ3huU 2CD7jPWRKREOObHYpUwXc9pydXi+6jpwmjpu1MZL+nGGhmsXcUU5WGNjrUbX g29WvmTlrsjoSHs9vNrxV0yqrru6NXRs3f8fqK4r+ojpmhw5hrHmO3XSiOP. +aNfi1URapQTuVTTaACmejlkq17Sc6Op0RAfZU8kFf5UNxp.qRJud3iNcevE WZ+gAypBwuQrzgbebyf7J6Nxdl63foWRzrYSAFgUh7xThh1NA0AP4DZtZ8Nm fV2vtwdLR024O6wrzg1+VegTTVDWuvp+KB1p6QOyREiSTLAuUm.o1s5zZVRB k29jnxXI4BMN0Pm6jYzWaB9WcNpMsigeosI3PcOpMckMo9fRdWUSBN8niylB tt1TeXS3qLN0GeG9pZRg8gMMLKJHznB2OvH+b5L+8uC6GXOXffl6diqCHFb5 QVGgW2zY++K0ArWlys2FNEdsOzKvnkzOxa+6N+da+drNBttw18xjlecS2zG2 s+00jzyF9XI.eGPI7ELNUeyWt4+.uqVWK -----------end_max5_patcher-----------
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.
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.
Am I wrong on this?
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).
Then that begs the different question as to why we (and perhaps others) had the wrong impression?
Forums > MaxMSP