Re: [chuck-users] Reconnecting Ugens (was; determining type)
Kassen, (Long time no speak, btw!)
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).
Fully agree! Introspection of this kind is a must in my opinion! The possibilities would be endless and I don't see why the scope should be limited - access to the entire graph from anywhere should be possible and makes for a much simpler implementation. I am uncertain whether the instanceof operator/function was ever implemented, but that would be equally essential. While wish-listing (and slightly related) a cool feature would be a way of tagging UGens with a arbitrary string. This would give us a way of providing a unique AND meaningful identifier to a UGen. Useful while traversing complicated graphs.
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.
I like the ChucK operator, too, but wish it was overloadable by the user - this would allow us a hook to do a lot of things! (I will not even try to list them ;) Have been away from my computer for too long, and wish ChucK ran on BlackBerries! -T
2008/9/7 Tiemen Meerman
Kassen,
(Long time no speak, btw!)
You'll have to excuse me; tried my memory, then searched my Gmail archives and either I have to admit to not recalling you or perhaps you changed your mail address since we talked? Are you Dutch as well or is your name simply very Dutch-like? Please help; I'm good at remembering people, it's just that I suck at faces and names :¬)
Fully agree! Introspection of this kind is a must in my opinion! The possibilities would be endless and I don't see why the scope should be limited - access to the entire graph from anywhere should be possible and makes for a much simpler implementation.
Yes, I think so. Clearly all UGens "know" what connects to them at their input as they have to poll all of those when generating a sample. I'm not sure knoweldge of where those samples are going is available to those UGens right now. As far as I can see this strategy would at least be possilbe and I think it would be very usefull. I wonder how Ge feels.
I am uncertain whether the instanceof operator/function was ever implemented, but that would be equally essential.
While wish-listing (and slightly related) a cool feature would be a way of tagging UGens with a arbitrary string. This would give us a way of providing a unique AND meaningful identifier to a UGen. Useful while traversing complicated graphs.
I think that and similar things would become quite easy once we could extend UGen's and/or overload the ChucK operator. Right now we can extend UGens, it's just that they won't actually work as such. This is fine; class Foo extends Gain { string tags[10]; } You just can't connect to it....
I like the ChucK operator, too, but wish it was overloadable by the user - this would allow us a hook to do a lot of things! (I will not even try to list them ;)
Yeah, agreed.
Have been away from my computer for too long, and wish ChucK ran on BlackBerries!
That would be nice! I wish I had a 1 TeraHz CPU, oh and world peace, I wish I would have the dicipline to vaccum-clean my room instead of fantasising on the ChucK-list as well. Cheers, Kas.
participants (2)
-
Kassen -
Tiemen Meerman