It would be dynamic the sc way, the server would be running and creating an ugen will be part of creating a synthdef. The difference would be in the entry point/api. I can see (dis)advantages in both approaches.
The controller approach as shown is much more direct for live coding Faust, and that is a good use case, but that implies that the synthdef graph cannot change, the dynamic entry point is the ugen, hence the input/output problem. The other way, the graph changes with the ugen which is more common in sc, the dynamic entry point is the synthdef. Regarding the control, the first approach has to set the data after a synth is created and to have two ways to set the synth parameters, /n_set for node controls and /u_cmd for ugen code. The second approach has to set the data before and the node control is as usual.
// first, better for live coding faust with f.eval
SynthDef(\test, { args otherParam; Out.ar(0, FaustGen.ar(1, otherParam)!2 * 0.5) }).add; // async
z = Synth(\test); // sync
f = FaustGenController.new(z,1);
f.eval(faustCodeOrFile); // async
z.set(\otherParam, 123); // sync
// second, I thought more idiomatic
s.sendMsg(\cmd, \load_faust, faustCodeOrFile); // async
SynthDef(\test, { args otherParam; Out.ar(0, FaustGen.ar('faustCodeName', otherParam)!2 * 0.5) }).add; // async
z = Synth(\test); // sync
z.set(\otherParam, 123); // sync
Synchronous commands are important for precise timing and each approach has a different order, that is something to consider too. I think booth approaches are complementary for different use cases. Side note, before Spacechild1 I can’t remember anything that uses /u_cmd (neither /cmd in plugins to be fair), it looks like a powerful forgotten feature to me.
