Give a group a name

Questions
1

hi guys,

Is it possible to give a name to a Group in such a way this name will appear in nodeTree graphical representation?

I see the default group shows its name in the nodeTree and I would like to have the same thing also for custom created groups; I think it will be much more easy to examine the graph especially if you have lots of synths organized in many (nested or not) groups.

Thank you
n

2 Likes
2

Alas the answer is almost certainly no, there’s no lookup for any names for groups. The string printed for group 1 is hardcoded in plotTreeView:

						pen.stringInRect(
							" Group" + node.key.asString +
							(node.key == 1).if("- default group", ""),
							rect
						);

The keys are just what the server sends in response to the query. Since there doesn’t seem to be a way to make the server annotate the nodes with strings… one would have to implement some kind of lookaside on the client. I suppose the Group class could be extended to have such mapping (and TreeView to use it), but SC being a do-ocracy, don’t hold your breath…

There’s one workaround I see looking at g_queryTree. The server does store and report names for synthdefs used in nodes, so for non-empty groups, you could basically make some bogus do-nothing synth just give the immediately enclosing group a name.

1 Like
3

Now now. One point I’d tried to make with you before is that, in OOP, it’s often recommended to extend a class’s behavior by wrapping it in something else, rather than by modifying the class. “… one would have to implement some kind of lookaside on the client” can be done without touching a single line of Group (though there would be to be an alternate server tree GUI using the new complex).

For example, I have a BusDict class which gives names to Bus objects. This class is an interface between Bus objects and collections of names. Bus remains exactly as it is. This is one of my early classes and I have to admit that the interface isn’t very good, but it does associate names to objects as a composite, without glomming extra functionality onto the base classes (and I could update the interface of my class without breaking any usages of the core classes).

I didn’t read all of the Gang of Four Design Patterns book, but I did read enough of it to get the idea that it’s a lot more powerful, flexible and stable to build complex behaviors out of simpler objects (and that you get yourself in trouble by making lower level objects more complex as a reflexive answer to every problem).

hjh

1 Like
4

… but it would be useful if the server would allow group names - for trouble-shooting when working via messaging for example. Just saying…

1 Like
5

I could see it being useful for the server /g_dumpTree command.

It’s better to leave the /g_new and /p_new server commands alone – because any change to existing commands’ format means that every non-sclang client must update at the same time, which is practically impossible to ensure.

So, if someone were to do this, I’d suggest perhaps to add a command like [/n_annotate, nodeID, "user string"] to attach an arbitrary string to any type of node (groups or synths), to be printed by /g_dumpTree. Maybe also ["/n_getAnnotation", nodeID] to send back the corresponding /n_annotate command.

(Including synths because, if you’re going to go to this much trouble, then why should synth annotation be limited to its defname?)

But I think the only real gain here is just to have them printed by the server when dumping the node tree. If you’re asking a node for its annotation within the language, it would actually be more convenient if the annotation were stored in a language-side data structure (and this would support the node-tree GUI more, rather than less, efficiently).

hjh

2 Likes