This patch I have been working on relies HEAVILY on scripting at startup as the patch basically creates itself in the background after some user input (up to several hundred/thousand abstractions/objects/connections). 

Everything is working as I would expect but once in a while I will get a connection error or an object didn't get created. If I reload the exact same variables again (sometimes I have to do that several times) everything is fine.

I think I have been super anal about order of operations and I use trigger and deferlow everywhere (errors seem to increase if I don't use deferlow).

All that scripting is done with uzi objects. Since it is working most of the time I know it's not order of operations. Could it be that all that scripting is happening so fast that things get "lost"?

Any insight is very much appreciated. I am banging my head against a wall here!!

This patch I have been working on relies HEAVILY on scripting at startup as the patch basically creates itself in the background after some user input (up to several hundred/thousand abstractions/objects/connections). 
Everything is working as I would expect but once in a while I will get a connection error or an object didn't get created. If I reload the exact same variables again (sometimes I have to do that several times) everything is fine.
I think I have been super anal about order of operations and I use trigger and deferlow everywhere (errors seem to increase if I don't use deferlow).

All that scripting is done with uzi objects. Since it is working most of the time I know it's not order of operations. Could it be that all that scripting is happening so fast that things get "lost"? 

Any insight is very much appreciated. I am banging my head against a wall here!!


scripting-efficiency

under normal circumstances anything triggered 

by [uzi] should work fine, unless it is so much 

what could be the problem here is that some of

your messages triggering file read operations, and 

with those you sometimes see that messages get lost

things like "plug absynth, open, 7" or "script new lcd" 

(and direcly after that loadbang-draw into it) is where

under normal circumstances anything triggered 
by [uzi] should work fine, unless it is so much 
data that you get a stack overflow.

what could be the problem here is that some of
your messages triggering file read operations, and 
with those you sometimes see that messages get lost
or stuck.

things like "plug absynth, open, 7" or "script new lcd" 
(and direcly after that loadbang-draw into it) is where
i have seen this.

I am creating buffer~ objects and then immediately use the replace message. Didn't even occur to me that there might be a bottle neck when triggering file reads (this is my first serious scripting project...)

Just to see if it makes any difference I will load the buffers after everything else has loaded.

I am creating buffer~ objects and then immediately use the replace message. Didn't even occur to me that there might be a bottle neck  when triggering file reads (this is my first serious scripting project...)
Just to see if it makes any difference I will load the buffers after everything else has loaded.

replacing the buffer contents at the end seems to speed things up a bit and I seem to create all the objects and abstractions I need. But, connections are not made all the time...

You might also want to try to make things a little bit more static. For instance you could create a certain number of buffer~ and use only the ones that you need. Buffer~ doesn't take CPU, just RAM (depending on their size), so it might not be worth the pain of making things dynamic. But you may also have good reasons to do so...

I see the same problem from time to time, even if no sounds are loaded (and it must not matter). 

I already thought about sending one of my huge patches to support. It must be a bug that somethings getting lost...

The most prominent need of scripting dynamically is, if you need objects with a varying number of outlets or inlets. Or if you use multicores, you would not want to waist extra cycles. Though in both cases I usually delete objects rather than creating them.

Another scripting use, is to get the name of a patcher an script ctlins or outs according to it, or according to parameters. There is no way around scripting new connections.

For this purpose I'd love to see an example for replacing an object like in paste replace. The old script replace works, but its hard now to find the correct synthax, I'd rather use the new way of doing it...

Still there remains a problem where sometimes connections are not executed without notice, but only if the patch is huge...

I see the same problem from time to time, even if no sounds are loaded (and it must not matter). 
I already thought about sending one of my huge patches to support. It must be a bug that somethings getting lost...

The most prominent need of scripting dynamically is, if you need objects with a varying number of outlets or inlets. Or if you use multicores, you would not want to waist extra cycles. Though in both cases I usually delete objects rather than creating them.
Another scripting use, is to get the name of a patcher an script ctlins or outs according to it, or according to parameters. There is no way around scripting new connections. 

scripting efficiency??