September 2008 - chuck-users - lists.cs.princeton.edu

paper trail
by Kassen 09 Sep '08

09 Sep '08

Fellow ChucKists, Does anybody know what my options are in printing (to paper, the old-fashioned way) from the Mini under (Ubuntu) Linux? Ideally I'd like to periodically or on command print edit buffers to paper as text as part of a performance. Is this possible at all? Yours, Kas.

4 5

Re: [chuck-users] Reconnecting Ugens (was; determining type)
by Tiemen Meerman 07 Sep '08

07 Sep '08

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

2 1

Re: [chuck-users] Reconnecting Ugens (was; determining type)
by Kassen 07 Sep '08

07 Sep '08

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.

1 0

Re: [chuck-users] determining the type of an Object in code
by Tiemen Meerman 07 Sep '08

07 Sep '08

Hmmm, after testing I found that sadly the following will run (without errors) but won't "fly"; =============== SawOsc s => UGen patchpoint => dac; second => now; new LPF @=> patchpoint; second => now; ======================== It seems that asignment to a UGen doesn't affect the Ugen-graph? 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. I was thinking of a class that achieves what you are aiming for: UGenRepatch - usage would look like: UGenRepatch repatch; repatch.ugen(LPF lpf); repatch.addIn(SawOsc osc); repatch.addOut(dac); To setup the basic graph. After this you could repatch by saying: repatch.ugen(HPF hpf); Internally it would then unchuck the old LPF and place the HPF in the middle. Obviously you could also write functions to remove/replace Ins or Outs from the central UGen. This method adds yet another wrapper around the UGens, but might be worth it for the flexibility it provides. -Tiemen

1 0

Audicle updating and shredID tracking
by Kassen 04 Sep '08

04 Sep '08

Dear list, Because I quite like some of the new features (especially the array appending) and quite like the Mini I tried ripping out the "chuck" bit of the Mini source, putting in the new version and compiling (Ubuntu, latest long term support version, up to date, I could look up details if needed). As far as I could see this works perfectly (so far...), no need at all to be burdened by any knowledge of C. Still, my current series of experiments could benefit a great deal from linking editor windows to shred ID's so I tried the same with the Audicle and got some errors that made it quite clear I'd need to know C/C++ in some detail to deal with them. So, first of all; the adventurous might like to try their hand at this and have a updated Mini (the "about" dialogue even reports the correct ChucK version, nice). Secondly, should the Audicle take such abuse? I feel this would be quite nice but there might be hard questions? Would it be a idea to use something like colour coding of window-headers (or some similar graphical element) to link editor buffers to running shreds in the Mini? I think that would be very nice as a help in livecoding. Like most people I can keep track of about 7 or so things at a time and the link between editor buffers and shred ID's that was steablished 15 minutes ago tends to be one of the things that gets lost.... Yours, Kas.

1 0

Chuck Concurrency Best Practices
by mike clemow 02 Sep '08

02 Sep '08

Hi everyone, So, I've been struggling to find a method to leverage the concurrency model in Chuck and I keep running up against the same issue: my guts tell me to do things that I can't do because of fact that child processes are alive only as long as the parent and the fact that objects are only passed by reference. Let me unpack this for you. I'm building a granular synthesis class library for Chuck. Most everything is being cast as one of two types of objects: 1) Forkable - a process that takes parameters and can be run or sporked 2) Forker - an object that knows how run a process and will fork it out for you. In order to get over the fact that functions are not (yet) datatypes in Chuck which can be passed to other functions, I'm basically following the example that Kassen, Mike, et al. were discussing in this forum topic: http://electro-music.com/forum/viewtopic.php?highlight=functor&t=23546 My problems always seem to rise from the fact that every Forker (whose job it is to fork a process) also has to be aware of how long that process is going to take or else run the risk of dying before it's child has completed. This leads to infinite passing of responsibility for time and every Forker seems to also need to be a Forkable and have it's own Forker, et cetera ad inifinitum. At higher and higher levels of abstraction, finding the duration of a process BEFORE it runs and figuring out how to handle it, is requiring more and more analysis and feels... for lack of a better word, "wrong" to me. This is compounded by the fact that the objects I'm passing into these functions (methods of other objects) can only be passed by reference and it's increasingly difficult to set-and-forget these processes, since they constantly reference other global objects. The passing by reference is fine, but I find myself wishing I had the choice to make a copy. Now, it's entirely probable that I just haven't caught on yet and am going about this process in a completely backward way. Does anyone here run into similar issues and (even better) have good methods of avoiding them? One idea I have considered is to make a Forker a looping process that receives Events as input, rather than an object with methods. As this would require a(nother) complete re-write, I'm stalling. ;-) So, how do you manage your concurrent processes in Chuck? Cheers, Michael PS: Love dynamic Arrays! Can't wait for those SC/Smalltalk-like array methods! -- http://semiotech.org/wp-prod/ http://semiotech.org/michael

6 11