Let me pull some other people onto this thread – @muellmusik , @VIRTUALDOG – legit question being raised here.
Our more or less official position about persistent group references has been that objects should keep a reference to a group, not to a specific ID – then cmd-dot can allocate a new ID for groups, and this would propagate down to any patterns or other types of players using the group object.
But, as noted above, typical usage of ServerTree is to create new objects for infrastructure nodes:
(
ServerTree.add({
~srcGroup = Group.new;
}, Server.default);
)
But this means that any downstream object that refers to ~srcGroup can’t rely on a persistent object reference (so, every downstream object should be deleted and recreated on cmd-dot… not sure that’s what we want).
Currently, AFAICS, if you want a persistent reference, it has to be something like this:
(
ServerTree.add({
var id;
if(~srcGroup.isNil) {
~srcGroup = Group.basicNew(s, -1);
};
~srcGroup.nodeID = s.nodeAllocator.alloc;
s.sendBundle(nil, ~srcGroup.newMsg);
}, Server.default);
)
… which… c’mon, we’re not seriously going to expect users to come up with this formulation on their own.
lgvr123 came up with a clever solution: to set ~srcGroup to a Ref(), and then ServerTree assigns a new group into the Ref. But this is inconsistently supported – \group, aRefToAGroup in a Pbind-style pattern will dereference and return the group (OK), but Synth/Group targets don’t dereference (error).
I tend to agree that this is a rough edge in the interface – we say a persistent Node reference is the way to go, but it isn’t straightforward to do that.
I’m not sure which is better, though – to support Refs more thoroughly, or to create an easier way to create, and update IDs for, persistent Node objects. I tend to think the second is better.
Thoughts…?
hjh