Dan Laüt

comment

pvar

number

button

print

I am working on a patcher that creates objects on the fly. For each object half a dozen script messages are sent to thispatcher with respect to format, placement and setting. The first script creates the object itself, of course. Connecting all the messages and the routines that generate them with patch cords produced an impenetrable jungle, so I distributed the object name (prefix+sequential number) by means of a pvar. I connected the first instance of the pvar to the first script - the creation script - and then option-dragged the remainder and connected to their respective routines.

The result was a surprise: the first script was executed last. Whatever I did, using bucket, cycle, deferlow, what have you, and changing the relative placement of the routines, they always executed out of order.

Finally I thought it might have something to do with the creation sequence of the pvar instances. It turns out it does. If there are multiple pvars associated with the same object, they execute in order of first-in-last-out.

Attached a simplified version of the scheme. Thought I'd share this to perhaps save someone else a half day of research.

I am working on a patcher that creates objects on the fly.  For each object half a dozen script messages are sent to thispatcher with respect to format, placement and setting. The first script creates the object itself, of course. Connecting all the messages and the routines that generate them with patch cords produced an impenetrable jungle, so I distributed the object name (prefix+sequential number) by means of a pvar. I connected the first instance of the pvar  to the first script - the creation script - and then option-dragged the remainder and connected to their respective routines. 


 
I am working on a patcher that creates objects on the fly. 

pvar-routing

it is not just the creation order, it is even worse.

and if it would be left to right, you´d still have the problem that the order of the objects might be changed by accident.

for a pile of lists of unknown length, [coll] can be of great help.


it is not just the creation order, it is even worse.

I have been thinking about using coll to send the scripts to thispatcher in order. But I don't see how to include the variables (object name, size, position, etc).

If you're trying to put generic commands for object creation in coll and then substitute appropriate values for each, you could write coll commands like (sorry I'm butchering the actual syntax):

0, script newdefault <objclass> <varname>;

And then pass those to [substitute <varname>] to trade out the varname for those commands to what you want on the fly, probably by passing correlating list of varname + position etc. from another coll.

I'm pretty sure I've done exactly this in the past, but honestly I do all this from JS now because I find it a lot easier to organize the code and variable logic.

0, script newdefault <objclass> <varname>;
1, script move <varname> <position>;

that´s right, with lots of variables coll or zl reg reach might their limits.

i mostly use a [list] per command, fill ithe positions of the variabels with content auch as "777" or "NAME" and control the order by t b b.

pvar routing