Buffer~ / Groove~ autoload naming error.
May 19 2010 | 12:18 pm
Hello all.
Upon startup of my patch, a little abstraction I have written names records~, buffers~, and grooves~ appropriately for what I want, to all match up correctly. However, as the groove~ objects seem to be getting named first in the autoload procedure, I am getting an error message stating "no buffer~ xxxxx". The different objects need to be in different subpatchers so a simply right to left sorting isn't an option. The appropriate buffer then becomes named and the association is complete but this error is bugging me and the project will be marked so of course even a few error messages are a nono.
Has anyone any solutions please? I considered that a delay may be used after the loadbang of what needs to be loaded last but that just seems like bad programming and a very inefficient workaround.
Thank you.
- May 19 2010 | 3:03 pmInstead of a delay you could use deferlow on the process you want to happen last during loading. Or, you could just re-do the layout of your patch to make workaround not needed. Or you could use trigger and send/receive to make sure that the message order is correct. I would suggest using deferlow and not worrying about it. It's more efficient than loads of send/receive pairs.
- May 20 2010 | 11:32 amWow, it never ceases to amaze me how I can read about an object probably several times whilst browsing helpfiles, never think that I need such an object and then forget about it when it's the perfect solution!Thank you Tim, works perfectly! As the groove~ objects were in different places to the buffer~ objects, I was thinking that a whole new system of dynamically naming receives on startups, coupled with a whole new sub-patcher of correctly ordered sends would be needed!All the best,Steve.
- May 20 2010 | 3:20 pmi am not exactly sure if that will work for certain audio objects, but the easiest way of controlling the loadbang order is ordering them .... which means use [t b b b b] where right to left order will not work.you will experience similar unneccesary error messages with waveform~ ...-110
