Automatic introspection GUI for Synths and Groups?

Development
1

Looking what introspection info is possible to get with scztt’s TreeSnapshot, I wonder if anyone has consider or done a fully automatic introspection GUI for Synth and Groups, without a need for Ndefs just for this Gui purpose. (I find myself using Ndefs half the time only because NdefGui is so convenient for prototyping by just moving some sliders to see what some makes sense for control ranges, spot what controls need a lag so they don’t cause pops, etc.)

Basically, a fully automatic GUI for raw Synths (assuming access to their SynthDefs) and Groups would recursively construct maps of controls for synths that accumulate in their enclosing groups, to emulate how the server broadcasts controls inside groups.

I can see that this may be a bit involved to update, i.e. what the update trigger should be, but perhaps hooking the OSC messaging is enough for that.

So, has anyone though of or even implemented something like this? Are there any gotchas that I’m not foreseeing above?

I see a potential issue is that SynthDefs in the SynthDescLib aren’t necesarily in sync with what’s running on the server, which Ndef side-steps because it desn’t let you attach to a running Synth, only to one that you instantiate from a client-available SynthDef, e.g. when you do Ndef(\n, \sd), the \sd is taken from the client’s SynthDescLib. But besides that, which isn’t that much of an issue in a single-client setup, are there other caveats I haven’t mentioned above?

Actually, the above is a bit of a problem even in single-client setups unless a timestamping mechanism is added for SynthDefs. Because one can do this:

SynthDef(\x, { arg a; /* ...  */ }).add
~x1 = Synth(\x);

SynthDef(\x, { arg b; /* ...  */ }).add
~x2 = Synth(\x);

/*
NODE TREE Group 0
   1 group
      1001 x
        b: 0
      1000 x
        a: 0
*/

So that’s two different synthdefs running on the server with the same name, one which doesn’t exist in the client’s lib anymore, because it was overwritten.

So for this this auto-introspection to work in such cases some more thought is needed on enforcing some name uniqueness. For example, have some kind of auto-versioning or archiving of old syhthdefs. In a sense Ndef enforces something like that because it captures by reference the SynthDef as it stood when you did Ndef(\x, \sd), so it doesn’t matter if you change its def later in the SynthDescLib.

This isn’t a total showstopper because the help helpfully notes that

.add(libname, completionMsg, keepDef: true)

Calling this method triggers an update message with the key \synthDescAdded for any dependants the library may have. This can be used to trigger additional behaviour every time a def/desc is added. See Object: Dependancy.

So a global history of timestamped synthdefs for each name could be kept on the client. But it certainly adds complications, because the server wouldn’t provide those (timestamps) in response to queries. So, perhaps making a minor change to the server to store the timestamp when a synth was started and also send that back to the client on query messages would be helpful for “perfect introspection” purposes. (Come to think of it, it could also store and report which client started it. That would help in a multi-client setup.) Potentially a client-only approach would be add a new method besides .add to SynthDef, e.g. .addTimestamped, which would simply change the Synth name, possibly including the client and a timestamp… but there are probably issues with that latter approach that cut across the SC library, resulting in other headaches.