[chuck-users] Reconnecting Ugens (was; determining type)

[Kassen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080907/11f25780/attachment.html>