PattrStorage dropping data
I’m working on a standalone app that saves some userdata into a pattrstorage object. Upon load, it is supposed to autoload this data. Weird thing is, it sometimes will not load any settings when it gets reloaded. Most often, it’s after a complete reboot of the computer.
I’m wondering if I need to put a delay in the loadbang? Could the closebang be sending bad data since the app is closing? Or, it it a problem with my patching? Could it have to do with it being a bpatcher inside of another patch?
Here’s the patch, I’ve removed as much of the excess logic and stuff as I could, while still keeping the need-to-know intact.
----------begin_max5_patcher---------- 5986.3oc68r1jiabbe9zuhoniKKkZEOL.XvCmTI5jNIEknSxQ6J6jRmpqFRL jD9.AX..2813x+2SOSOf.fD.DfOvdqpH6iKwCNnmd52S2M9aexKlLK4ChrIj +H4WHu3E+sO4EuPcJ4Idg93WLYM+Cyi3YpaaRXbjHexM3U1vymuJLd46REyy wQgZXaO03Fhik7SSVwmjeU+aBCTiSxr+5m63VLPwaWqFX0yvn7jIayKNKUeV 7T4OtQfOvIS1MzySVuVDq.jIeSXj..uUjaE4a2P9Rd7xIx65u+Ieh7ia54zM V7..oEfYt3C3nmSl0ANvgpl1LGW0rWgOLMZFGvXECzhj37rv+W0zhZN0nITC cXnlYxY8tmp7ADyWqt3jWkFxiNILx10yDoE.MLyQLxqhDo4jeRrQvyIeNISj SxWIH3cSRVPVkrMMi7mCC37TxCgQQjG3g.dTrHIU.2eb.fDIbBfwIb0fsVjk wWJlJWBIYqRfSQxSHoB.gD.idRlf7vpj0j0gKWkSfwYo7olPVD9ABLz7E4vi VBEgwg4vzEFWd5ZBIIkrIUbOPpP3wwIOJevo.jC2TRLY1iRnOGglnj3kxAIb M.GES564o6vi3L9c2A2vNjxrjz.Q57jnjTbgvPRAT9AsBo.LWBWucc0kw7zv Z+VaCWOaqaZ7aUGpU6+Ca8g1.Mqsmhl02yW9GaiCnYALFrHkyk3npPaEZYWq cjEyVVARnHP36X6Z3z.3HILWvmKpNrsvMTabkCoDObSieq5SnQlnUR149gvp yuY1.JoBpzzC+8lp+X6d.p7.9TISzMWG1UMSzARvjLn+CzNDhYYnja44n9is RbN0qYgXtFCQHl4oJe+BI.qYQ5AvvkrTIq4OA25C.ObOvNT+JK0sIi2w+7QO lshdFaBmGWOKIh7O1x+cbbFvbpvYHgUajTTmmQjT47YGnPrJgDnP7VsBwMEm BTWoNQglOwZdHngZ97jsw4SOEUIyiBm+99KSC.Zske0f0RbC9rShOb3r7Lr7 Mkey6nJVJV0sUbJ9zCXTvGS00KbhvmMjG7w0NQ2Yo0rs440uslz.kBKDAB0u 2aGUWKDi6CrdLOOSk1nC+1Q0KUmH1Zm1pSFgTUMOSol2Q8I08vUi7zswy44h pFhuJ4dvdrFe7TKWSkJcmFlcsomS8uwRbUtz7xtTzwrPThAsTccaRkbXOijJ EI5RClMySs3asS0UGNoXM4B3MhRx3udBSDEs7NmN4yyCuWXVyzRGlguWCx3F h3SEkR.sx8oGbCJ00g0CKnU2uioi52pHJHR6CpKfVDTGzaBTpf5sbqOuo8ad W2LYSeCpuhM8vucTwQZnldTntNYf8NgsylEIJYUpgsM6G19.RoBJhchTpehp KS4oxGkTzflTZQ14a0XUO.mCLqoIQuCG58k+v2lmnfBRi2WSQOPQ33gbjTKZ mLlzSI5A04G.mxX9JGmjByYU+1wWcazbzdIiuPKqPQInw7ZT+Kp6VsZj8JFL fSXwhvnPkpseg9q5IRkKK8x+c4k+TZ40V.NzidaqHkMk+W4UyWAfyprnv.QA 5g55Y5ypbKeH+cyRBdTOcuCrf6VTKKILi7koI7f47LUzCdsfGPdUX5zI0+4y SJF9I+yh0axe7eYuaXyCEj4ZaxPpoZ2S576S6bPx1Bjq3MHC5RZJQEhl8tqs EqJMNNaWKh29tfTPtygnR7hgwa1levRv8IQuONY193Y0UULdCk8SaxV6bM9F Js31nz2tUm45O4xEbsSXxTDmx8kUbK+dgzQAI0SWRH70QVPqoALv1xwvxyri Yr6jgGqkdfbLtnFrzFd46AlpAfWbsT3EeyNoALeNfQZIVEyiRxDJ5u1QFtX. 8rsTnAFZMhaKNa62X.b7adha7zGD51r1+gzP36qiHucxa3yASARxVQ92d8e7 k+blHM6ke+VP17Kecxborq7rWhBFe4qRAj287HPR91EKdIcpC4M7O.5XDE2x T9lMu7q.PW8yx1tYSRZ9KUZxmBOt2No.RhBiEJO3kfCqiUGj201CWWX5MLns kG5.Vd93L7ZajAXONfj04tGUfVzDsdcSzZN.rB8iZrRAcaOPMneEt9ciZrd1 iZBDQ7GILCCiIG0mKlqxqcFqajh+0iKZLExQ6ABwWQe.rQRq3aY6WMMLd1KV o6Mhs.avrm56664BtJaR6hFwzfd8XbtFzHsYxze5U2c2Oc6c+3O8pu8qIeyO +Ce0ce2O9C21ApxyyspBIzDp1QS815I+mNimTNnzjG664+XAtCVozADuqv73 iBfs8w.EZXzMhZmfXdT3x3iik1eCNskgC4lF+1IFH4Eo.dnegDqeAvETcstX mDRAedkW8F4GkZ0zmPdU9RdXb8ao9olGEBTzODFGj7PkSJ3oWWYJUoPZNVNU ilDQcKjuPFeGcLL.Gf+hLvEt0f+8DK7Rpex6tOLqLDz0LQz9nJ7YddX7fP1y 1nyXmfbqKPbfNM4+Ew.DPVAuCfeXN+NIhJDbyG4AqFKnMbIEatH8chX9rnpa MwKzTKUk4CXI3eVL4Fh3VI3NpgQlIHq0weY2XnWRqtm.dV2PbjifgkbSM7cN mfWbVlDyb7kJw6kIwlFtOer66ngzwF2dJJqGgzg9DGRmyyqGFN2bc5yRr2yd S6Ai1J9ecZ7lgx5ULNFtVciU7OarBqSphaNxeGGLWTBO3Hw8w1uJWic2DSTi mWl61lKQWpv8zRfbr5P7rqh20xPinUDqVNsgueFEHmiJetPrko+wkOaRM+nT .8hhzDNPrfuMJmXziILFmALlCsyZ8LJDLswV0une10dYhBuszoOnNkuZKdDT 6ICw2nAXw5GMLUsgokdF8QePq0gSw1yoGAs1jx9MSPqQuZOpI5XjAzD4sJWv 44u8aIXRfN43pEsrvfkzMJw8YOJIaSJv3tf.HF.DH+9reeVOvNNHdw5HTLdO eXjNV4Ao2ldKLnFcWdPldWuxCp9VseAC75q1lmPji9K66tVai7HTJF9Ml8TS SCKG2Nb10w4Y7lWmscVVdX91bAQdti3arCpqwrHbqcVLUtdW4DserBe+chrb xchT.ZAM7eEbW73frF0Wa1QL8QbFEqoGJ5KnTXyPRaZa6qKsVKIpLXGGqTDA 04vj43Z3kytr2+M73s7nnGIQ7swyWoxTe.JEoh.R17zvMkon+h8rJsHkLMAq S8TeiIyzR5QSfTGzwcpeaYjaeVs14f4dFK6rKwOO7aCbiDpJpUQIdBy91Vzc Lprnyl5X3X3U9s12Xh5AaXF.WuuOIK+oTqG.OpHHL+.RluVRdPlq4UIq.ZEx ecKvGGE9dA4wjsjGR1FEPBiUTS+3s+W63vmRH2sR7HVVjhOHlKEN9vJAdm2B 1zGOWPdkp5ECyH4ogKWJIEmR9ljT3GvWuIRbi5YLW8LJFCdLAbB.bIPQxdir xGUTwDYoNEvy4RngixgktN..x2KjpFmEwieurVJCRHwI4RJ0oMsQI6xmwBLO rNTDec5wkpypE0jgRqab9kNq8wHHQmbr0IWnVXDqq8HqRVIOtpLPZoNCMHpC 0WqO3jjvvbehzGfqDJX1mckzFzlIKhH.PHzNiNTg3ar1Z51kG6y2iGq9Ft5Q xCnzB4T2krrT1XPfH9XxBz3MLS2c5L+Lr8Ng7TrtdPPC.Uo8iZ6anTFX6Zyn W9M477iNTUAs2tRDEcqHNPj9l52US9WhtUpCLqkeWkzjk+ynRZpUgeIJMkQI O.51RUsC.odRU8VlqLeimS3yyQa5zZGwaPtIzEE7eFYAXsmTxyTxWJfQqXTp UEGfIOfE.RkixKAKRgIayHpDgOCeRkO3sYhroj2F+136VAiEdR3K7nrDPw6L 0I.XNLNKLPH6SBbo5V3L5qbCXGPH7axVk7PlbJ.e.+exb.MjB9FrZ6L8rKJR dGRa.jPFeFYlH+AAXCQMHjvSEb.j9tbDFvwMKYMfDBWJ81HLdQxTIDKgY07n LoGj2mrvJx.6BfO.PkrlCJ6f+QBy+CYnMEXiWfKsEBdhxUDwrjDz7ixQP1.F z2pLelkULgBuklrLkudJ4ur5QD8Gl8u1nmOzFqC+52RWxcJK2OqhzozbfkTp 6SiyQ5nnXpyvazMOl2EWc3whlC5UlqSOBlCkYd8hlyajEn5kL.m.Mml+63yd LxDNtcldBrF2MHJcJymQ8b6OkwoGdhJIci9m769A4Op1jkL4eR9wu6+T9Ins AOyEsJW9NP9RWIhHZiZoMTCtKjvdh3IKygtF.7qPJMV16c1FDlP9Nk3cYmFP YrJp1.k4uHMYsR35xPoPWrftjpI.0SM2VapVbWCK+HcMMwFIit9EOo0PS2Ii Wef4rSSxt6CLXr9oflFSpogrA3zqlAS64X4WtMLJ+yAMtuIbdZxlUIwhc4I4 tq8c3Rm9z2J6kAKPyi9Ty4q9rluB0QdowweAdPFfw.yRR1npdxN23cjlhZXf MQB+tj0ZaNXQsmPjfqUlwWWiaqvd+1txGCOvySGKFX2eI6mo0I4iuySiO9ne 8HCSCcJjKCZNnhxvJcqEv.77v6CyeDDg9sR6Y00q8tF0BWsLfBTkaROQuK6D xqKrEluXgTzKdmah3ONiO+8Ri5UNZjrMctnwnnUTtrsDQ4NazGwBQPTcAUdT limxG2C+1QhAsOV0jd9NkUMHafVEaZ2RLn6pQlYbLozfLJdNPKoK23hSWPHV iNrmAq1ZmthC+VehVsdG6rqFhvNCMnZNbQyeoLxaxxS+yctW750TeXM0A9OY +Zo6zBj4etIStGFREiolE6GfK00w1sqnrLN0RbEF8t5hk1TzmFPUSANCDN4C yFYdkOT4oTymFaRKpNEbGkbtVVkpapBMHXq9UFR2X4flfntsfzz2tXMAwBNE Wqcq5L2cq5sVXglNCuZntdFvVwXl.w7v07HPSzbQsqEtLNAl1xN6RmtaiBrt R43bWNy7ZzEk87lAUrVy8ExmdqPP9OhSdHl70ooIox3bQjYNG4a2JCoV3B31 jAWh75vkvIjQ4hrhmF7.OU7Ys66itqWLPmenpv.n8E7Dc9gZ8aHueP0hzAzE La2wmenpmNeEP.qnUp41yOhFHz3M0tSPseanGQE2G..+jfGI6JM6NGO.lzOD lVdluOTFgkw0Ip5Tqc3VtIVMYcGsJKueS5B0qOFRplGTZd3FZey8hG1+ozEJ jqyy9Jove81n7PUaR5vFAcQ1JbmpWJkDIa9keu3dQDYlZGUPI4JGpTc4YUeZ Bt1xv3LoLcr+WJSHhvLY7+mISEJY2pkmioSAeVx8B0.7CIgfBfuIJIQ5E12s .65zIIjUgKWcirEPul+npAaR3jE7nLgtCPGrMEauya3o4gy2BmL5Qx+y1PYi lNId4T4fU5y2Ro+cJW4Je146ld5NXMNi1OCMTPgJsNTMnr8m2MmSEU5BU0rb 5cyRxySVWkLPeg7jM0HNZHX0XRl56okGO0h5364pRsNsEN6007dmZezpNr3J 9gM14ioUnlaB73fP3CgWghEWoiAJmE77bLcwz3ugbFpJ20tfYKxANFf1rdej qs9fmsoEyzG6xb9pLKpolXWS91DmK2YqFmH65gcNCq6QqwxQhE48fw1oRyj1 R62I8XogRo30bfq68wBj+057krVuA30rPWv5L7lZmpTW6PtXb8bXmhnVqml8 fS2IUA0p1dVNdrFA+KT6EtsTN6tDP3Jl2Y5rJS2EgCB.ftxlQiBlTxgloZ4v R4jxFqurnnyEDk.8MQhheIHu6gv7U3d3tlS3xZXcCfZmR9ukIYlLuxj6drn3 YqhBM412bKHH9fbRC6O+nb3XMHBR5MotLFiZZY+E4eHeJOOeZrH+F0CSJ0Tk IapeUoTS0deqRWMctRHGH3YjhPPq4nlpc4cBtg1dCMVVY3X1fg1RMztQrwoD Rfqmg+18hZuHjWxJy1Fb+1B3cOsjgCij29oJ3Ule4m0Rj1w0n1SLE8XgvJxm JI7k0vg7Zeg5hSAlfhr+8yJBmas90Mxoo3upPvJ44JdIVzFg41pRHuLTlZoo 59e2foKcdFRWhoxnl5zj97ghrRGhujh7fdDeAwYqTQadnglURkdG5Ek9xC2+ M+t8gzv8iR5nONnGZyjoR4Mc8dTvupQSt1Gzmo6CaNs+8+R5EzpIlSE90F.8 qK5MuqDOwTmDXZ85mV8WPqW12ip0nNlF9TpRvuxjTuFmDWGAZ6KPR08gOrKM TsSDWV+wWHCxnLro2Ychqb1OmT74frP5b3ugT4+iSEe6SmnZk1GRmzq1p8Em .xD+qEFiT4avtgQ.wdFR.oqxNsATVe7YLeaxxqR4zjzbTX.khJKsomlLAumD o450FlyTOelkuUiv+0E8JEfKgmNvv10D6xNs85h5+ThgqD8F10Z2w67Eln5E bvts4T1c6p7JSLSLOQVJgxupipdmAatRTyyS18JNrRfuyvLAMaMGbTMPJGkG lRlkJ3uOaW4BHC.dlLU84jW+uKeAKpieyLg78gXXNfhIYxH4qJyfn2OU+Pkt uDtlrA9LIPUiCj2N4u.x6kBsAg4KEuEjZDphZpr9Il8nZZ7nPV3Bv.qJZCLJ Va2ronNNVIiFz7jzXQ5TBksCmnKLCca64FxLYoMnBptDcAhxqdm7f6CyjHWU cOH2T.XxLGF5kHbn1Hb0NB.OrfT9xkxC1tAON4gXUoKT6t.whEUrfbOkk0EL esJT.gwM5lV02JEOieOQxv8z9rdOQ5P++eOQVtC45cr6o80D4FdrnyRGUYXD tjqM4bflGUVpLYq3xV6JbgO2rk8ogUTadN6pMOUx4YKSmrgXDT+RZeS8KTC7 MAlZOTqkjdpmnp3i16ckrBSIOecTKlpm5Ush2SOkueTl.RL.SY2gs9kxWepU toxhmz3b5WqqCC1j.TNYEYnhrUE4q6Nf916NpkrRruyP46TkiNCUuHC5bJtG z5SU.nsim7Otv5SwQmK350Cv0xeXPqqB7nV5rU2t7nyDZku14NNz5NLn8Lgo dQR6PGaRZls2khjtWyPYSHXjlgTCbtoIyTGMFSwixFbImhdVp+ZWdzXLEMcG O5TCeTVV4QixLzdzlgdNt3pmQ4giwTjZ4NhyQbUzzY2QixTjxFQdQS0esnVk GNNSxwiV0W+hRAmipiFkonw3RpVNEUGMNSQmwaJp61J9lGdjSsUXmwaEd73T 8sbpvnpNZTlhinsc1XmU0bpE00f5pO0YNKs6iS.1swoRaAhwtVutWGW8nyEZ c6CzRGUm.j0Z64ab09XPqBycQTHk0vg9t520izcGctyE50vkPb82jU0rV0Qm KzZzmHJ3cRNvZhoNT0iNSn0rObZt9mVvAnXDIqbz4Bs8hSy7DopMXUHbwCOW 30tORqMcFUQCp1V7wkMPGHTwbUFdqyAFFlyFVW.s58CdUuYEOI3sZDrTGc1v qauvudi7ptSefJC2QFpX8BpXCCpr8UR2YX0TqWaY36nqQAdoiLVzt2Tbz9CU NXPnsbzlqWdzYCuV8BKNXkjJNZSWKLXbkGc1vaurlhZMxq58J7Rzwli1nWqs CzjBlg9cNE9ht.qad0QmK7pfD5QwhrgBuJhPKaz1GTdj5nKB7ZcT30dfvqkB BM0lro2zyZGYgsytB4.VtWHbu8QmKCzfNF5OhIEsmSKGfxtPvq4Qg2AJ8mg0 ltrkVvtovtD0QmM71OK8nmlb1RK8JN5rg29Y4Da3V5o1HeyBYGL8QmM7Z0GY GC05Eer+EdErdwnWQOx2eb0XXX7w2lntORnskViQFpr50Bn4HCUlWiTLnZRE bQSwf8gjKDaaAiZQ7uJO5rgWiqB9029ZgeuFV.t6sNpQMK.u.nWVuHeYiq08 pV8wEXmUaNXW9N0BYasi7PTawNn5eAvvVt8ZtLT+8PHz2rZb67MOe671OhbM CurwUMYuh7.cbCkXuhojy3hmb5izG2wUusqwEYqmuz1c0GL0PE6oELaR0pSb Kb95b0p33dMzpPMza.jq1laic8a9xit3AcneVfvXiadC1GALNmCLAG72+j+O .ffsHUB -----------end_max5_patcher-----------
I’m having the same problem, and I’m doing this a similar way. I suspect that when I change and re-save a subpatch, some data gets reset to whatever I had in the pattr aware objects. If I fail to reload the saved setting, they get clobbered when I close the main patch.
I am also saving a bunch of MTRs and they get overwritten by blank ones sometimes too. Other than creating backups of the folder where my settings go, I haven’t found a way to avoid this yet. I hope that once I’m done making changes, this will settle down.
I’ve done some experimentation, and it appears that the stored .xml file keeps it’s data after reboot. The data listed is all correct from the last load.
However, the app seems to ignore this data when it re-loads, even though it is executing the re-load section of the patch. This does not happen if I simply quit out of the app and then reload it without rebooting the computer.
Good grief – so it’s not just me! I’ve been tearing my hair out today trying to figure out why settings that I can see in the XML file aren’t being recalled properly. It’s umenus in bpatchers that 8′m having this issue with – and it’s not every instance of a particular bpatcher, but it is the same particular instances every time.
There are 4 sample players, where the samples are dynamically loaded depending on an overall scene that is selected at higher level of the programme. When a scene loads, the relevant audio files are loaded from disc, and their names put into a umenu. The required umenu slot is stored in pattrstorage. Each player is an instance of the same patcher, yet the umenus in each don’t respond the same way to having a preset recalled. Players 3 & 4 will be recalled correctly, but maybe 1 or 2 won’t.
What’s really strange is that I’m reasonably sure that this wasn’t happening a week or so back, but may be something that’s crept in as the overall patch has gotten bigger and more complex. But there shouldn’t be any issues with pattrstorage with a large patch should there?
I don’t think patcher or data size has much to do with it. The patcher I’m working with is relatively small in comparison to many projects. The data being stored is text, numbers, and a few umenu and other ui things. I think there’s like 13 total tiny entries, and only a single slot of data.
Maybe use the message "purge" on the pattrstorage to clean the erroneous data?
Is the effect of purge different from clear? (I’ll have a look tomorrow anyway).
I solved my issue after another few hours digging around and trying things out. It turned out there was an old [t b] left over in part of the patch that was retriggering a umenu unnecessarily. I’m not sure why it would only affect one or two of the umenus, but i took it out, and so far settings seem to be being recalled correctly. I also went through a lot of the sub patchers and gave specific patcher-related names to UI objects, just in case there were any potential name conflicts (does that actually make anydifference?)
And one thing I’m having to pay _much more attention to when a new scene is recalled, is the ordering of messages, and making sure that loading of buffers and menus happens at the right time.. _Lots of trigger objects .
So maybe that’s relevant in your patch. Take a careful look at the order in which things happen. Maybe the settingsmin pattrstorage are being recalled, but then immediately set to something else by another message (that’s what was happening in my patch).
The other thing that might affect things is the priority of the different settings stored in pattrstorage. There’s info about that in the help patch.
umenu object at a bug, maybe it has a responsibility, you can find the updated umenu object on the incremental updates page.
@Moze – My problem isn’t with erroneous data though. My data is being stored correctly, but not being recalled after a computer reboot.
I did some experimenting today and I might’ve found the problem. I’ll report back when I’ve had time to test it properly.
after similar issues with pattrstorage and recalling presets, I found that setting priorities in the clientwindow solved the problem in my case. The fact is that patterized object are recalled following the order of the clientwindow list, and not right-to-left and top-to-bottom usual max logic, which can sometimes give unexpected results.
I didn’t look at your patch, and it’s just my 2 cents, but maybe you should try that.
I would say the inverse, preset restores in unknown order (you might get lucky, or the order doesn’t matter in some cases), patttrstorage lets you define the order ;-)
errr…Yes, this is exactly what I was saying in my post, maybe I was unclear, (and I wasn’t talking about the preset object but the way pattrstorage handles presets (or "storage slots" to be precise)
I found the problem Last night, I think. I’ve tested it once, and it worked. I’m going to do some more testing before I’m sure though.
I attached a print to the pattrstorage, and I noticed that when the loadbang occured, it would call up the filename followed by a 0. I recall that the 0 in presets is used only as a cache for interchanging. I’m guessing that rebooting the computer emptied this cache, and so it wouldn’t load anything.
The weird thing is, it also triggers a preset object on a delay, so after the pattrstorage loads its file, and so in theory, that would load up the data. Apparently not.
Now, I’ve instead routed it so that the preset recall and store messages are being sent to the pattrstorage itself, and after the XML is loaded, the pattrstorage is told to load slot 1….it seems to work. When I’m done testing this thing, I’ll post a modified patch to show what I did.
I must have done something wrong, because what I thought was a solution makes the compiled program crash.
As I noted in my previous post, the pattrstorage reports thru print that it is loading "[filepath]/prefs.xml 0" — I assume this means it is loading slot 0. Is there a way to tell it to load slot 1 in this same operation?
"[filepath]/prefs.xml 0" actually means the file was not loaded successfully into pattrstorage.
Hm. Okay, ignore almost everything I’ve written so far. I’ve had a few errors from other sources, which I found after using @outputmode 2. I switched how I was using my autopattr (I used to use physical connections, now I just let it pick up all named objects) and it was picking up a corrupted object. That was interfering with a lot of things. I also made a series of very elementary mistakes while working on fixing this, which made it much harder.
Second, I thought I had a solution, and it turns out I didn’t. And as ^^Spectro^^ just pointed out, my assumptions on some things were terribly wrong.
The origin of my specific problem has to do with the loading of the program after reboot. The settings in the pattrstorage are loaded by a loadbang. I had the actual recall of the presets on a delay of 2 seconds, to give the software time to load (it isn’t particularly large, either). After rebooting, the first time you launch a program, it takes longer to load. I set the loadbang on a 30 second delay this time, and it worked fine!
It seems as if the loadbang was executing before the patcher had the ability to do all of it’s functions. Is there any other way to go around this? I would like to reduce the timer, but I am hesitant, since my users may have varying system speeds, and it may take longer for them to launch, in which case, it would lose the proper loading, which actually defeats the whole purpose of the program.
One method which is very often safe, is to use a deferlow object after the loadbang. Another method, which is sometimes required when the first method does not work, is to query info from the object in question, until it replies. Then you know it’s there and ready to go. Using the read confirmation from the pattrstorage for instance is a safe method to trigger events after being certain that a preset file has loaded fine.
Thank you. This fixed it right up!