Stephen Powell

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.

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. 

buffer-groove-autoload-naming-error

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

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


Wow, 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!

i 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~ ...

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

Buffer~ / Groove~ autoload naming error.