In general, I think that we should not rely on server queries to get the state of nodes and groups, but rather track it in the client. John Murphy on this board identified one case where there really is no way except for querying – namely, recovering from an interpreter crash where nodes are still running on the server. I agree with him that server queries are needed here – and the current case (that s_get doesn’t return anything about control bus mapping) is a gap in query-ability which might need to be addressed.
With that said – if a node control is mapped to a bus, it’s because the user mapped it – therefore it’s the user’s responsibility to be aware of this.
Here, the SC class library has a design flaw in that we rely a lot on a lightweight class Synth for node messaging, but we need a class that handles messaging and tracks state. Synth itself maintains no state by default – you don’t even know if it’s still running or not, unless you .register-ed (not the default behavior). It doesn’t keep argument values or bus mappings, or its position in the node tree.
Because it doesn’t keep any of these things, users then think “I should ask the server,” and then run into cases like this where you can’t get all the information from the server. At that point, the assumption is that it’s the server’s fault – but I disagree here. It’s rather (or, also) that Synth is not a sufficient abstraction for people’s real needs … but we keep using it.
NodeProxy does keep track of any controls that have been set (.nodeMap). This is probably too heavy for every use, but it shows how it can be done without server queries. When you set or map a NodeProxy control, an entry gets saved into the nodeMap and you can use this to access the current state.
So another approach would be a lighter-weight class that lives in between Synth and NodeProxy – more thorough state tracking, but it wouldn’t need NodeProxy’s multiple slots and auto-reshape features.
hjh