Tiemen;

That sounds like the correct behaviour, as you only change the memory address 'patchpoint' is pointing to. The actual graph will know nothing of this event.

Ok. Learned another thing. I suppose I took the word "assignment" too literally. Thanks!

This method adds yet another wrapper around the UGens, but might be worth it for the flexibility it provides.

Yes, could be interesting and worthwhile for specific applications like perhaps a configurable multi FX. I am starting to think that this kind of wrapping, for what sounds like it could also be seen as a very general and atomic operation, is a bit much; to get the extra feature of reconfiguring the UGen graph we'd have to sacrifice the ChucK operator as it applies to UGen's.

What if we'd wish-list two new member functions for UGen's, similar to the new "UGen.isConnectedTo( Ugen )"? I'm imagining "isConnectedTo()" and ".connectsTo()", both of which would return a array of type Ugen (that could obviously be of length 0).

This would enable us to write something like;
=========================================
fun void replace (UGen target, UGen replacement)
    {
    while(target.isConnectedTo().cap() )
        {
        target.isConnectedTo()[0] => replacement;
        target.isConnectedTo()[0] =< target;
        }
    while (target.connectsTo().cap()
        {
        replacement    => target.connectsTo()[0];
        target        =< target.connectsTo()[0];
        }
    }
========================

To me this sounds more general then the new "UGen.isConnectedTo( Ugen )" function from the latest version which could be re-written in terms of my modest proposal while the reverse isn't true.

Am I making sense here? It's not that I don't see the use of wrapping Ugens to gain some domain specific functionality and it's great that we can, but reconfiguring the UGen graph sounds to me like a very general type of functionality that may be desirable as a part of the language. There are, of course, namespace issues here. Using these and starting from the DAC we could map the complete (active) UGen Graph while this should be limited to the UGens that are reachable from the current namespace. I'm not sure how feasible this is right now; clearly all of the knowledge we need is there in the system but that need not mean it's easily reachable, seeing as how the UGen graph is relatively independent from the code.

Apologies for jumping from topic to topic like that; little sleep meant a bit of a heightened associativity for me. :Ź)

Yours,
Kas.