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

Object reference weirdness
by mike clemow 25 Sep '08

25 Sep '08

I have an array of objects that I've created and I'm abstracting arrays of these objects as a class of its own right. While testing my code I've run into some weird snags. I would get bus errors when calling a print() function, which is supposed to just print to the screen the values of the object's members. I've been trying to track this down and then ran into a situation where I am instantiating a brand new object and changing it's member values (without adding it to the array). Whenever I change it's values, a certain object in my array changes with it--it's reference is identical to the new one I just created. This is like a warp in spacetime somewhere. My object is some quantum object that has a twin and is being changed instantaneously but at a distance. Schrodinger's cat is rolling over in its grave. (kidding). What is happening here? Is this a garbage collection issue? I will send my code (and instructions on running it) to anyone who wants to take a look, but I'm afraid of subjecting the entire list to my spaghetti... ;-) -mike -- http://semiotech.org http://semiotech.org/michael

2 3

STK shakers wrench rattling?
by Kassen 23 Sep '08

23 Sep '08

Hi, list! I'm having a bit of a problem with the wrench and guiro presets of Shakers; they won't rattle nicely. That is; they do for the first .noteOn() after the preset was set but after that the following noteOn's merely make them click. I tried all parameters in lots of permutations, I also tried to understand the source (which has lots of exceptions for these two) but it's beyond me and some of the comments look scary ;¬). I'm suspecting this isn't proper behaviour; sometimes messing with the .energy() parameter will get them to make some sort of noise but no nice rattles. Could somebody please comment on this? Yours, Kas.

2 9

int *=> dur (syntax inconsistency?)
by Kassen 21 Sep '08

21 Sep '08

Dear list, Consider; =================================== //definition second => dur foo; //this is fine 2.0 *=> foo; //this is not fine 2 *=> foo; ==================== The last line gives a error about not being able to resolve *=> on types int and dur. I wonder if this is correct behaviour; I can imagine many cases where a integer multiple of some duration is needed to avoid "trainwrecking" (a DJ term for two concurent tracks running at slightly different speeds). While we can obviously express integers as floats as well there may be cases where the int data-type can make guaranteeing we are dealing with a natural number easier, for example Std.rand2( ). while correct I don't think either alternative looks especially nice; Std.rand2(1,4) * 1.0 *=> foo; Std.rand2(1,4) $ float *=> foo; This does work in the comparable case of; //correct but not as ChucKian foo * 3 => foo; or even; 1.2 => float bar; //implicit casting in *=> does work here 3 *=> bar; So; I'd like to sugest a implicit casting of int to float or further overloading *=> in these cases. Yours, Kas.

1 0

Fun ChucK Game for Nerds Like Us
by inventor-66＠comcast.net 20 Sep '08

20 Sep '08

Memorandum To: All ChucKists From: Inventor Re: HSTechSpy ChucK Game Greetings fellow ChucKists. You will be pleased to learn that I have endeavored to create one more way to waste your time on ChucKian adventures. I have developed a new game (last year actually) and recently added a healthy dose of ChucK content to it. In the game you are a Hardware / Software Tech Spy and you receive various Mission Briefings which you may or may not chose to perform. So far the first five missions have been software only and primarily based on the Perl programming language, but now I have added a 6th mission which is hardware based and involves a little ChucKing around. Rather than blog on endlessly as I often do in forum and list posts, I'll just give you the link and invite to explore the page: http://www.freedomodds.com/hstechspy/ If you visit, be sure to scroll down and check out Mission 6: USB Hardware Interface, which is the latest and most interesting ChucK mission. HSTechSpy is fun, it's silly, it's educational, and it's a great way to waste some time so stop on by and give it a read. Forever creating useless ways to spend your time with ChucK, I welcome you to join me on the neverending journey to nowhere. Enjoy. Les (Inventor)

1 0

ChucK Humor (or the lack thereof)
by inventor-66＠comcast.net 19 Sep '08

19 Sep '08

How many ChucKists does it take to change a light bulb? Four. One to make a feature request, one to develop a custom light bulb interface that works great but is so complex that nobody else will ever use it, one to imagine a future in which ChucK can change it's own light bulbs, and one to hold the light bulb up while the world revolves around ChucK. How do you annoy a group of ChucKists? Ask them how to do file I/O in ChucK. Mention garbage collection just one more time... Joke about their excessive CPU consumption. Tell them that Csound is more powerful than ChucK. Ask them if ChucK can take advantage of multiple processors. If ChucK were an automobile, what kind of automobile would ChucK be? 1. A Corvette because it's built for performance but it's always in the shop. 2. A 1967 VW beetle because it's cute and everybody loves it. 3. A Corvair because it is "unsafe at any speed". Why did the ChucKist cross the road? 1. Because the other four ChucKists were busy changing a light bulb. 2. Because he was livecoding and wasn't paying attention to where he was going. 3. Because the CPU is always faster on the other side.

1 0

Detecting when child shred has finished
by Paul Reiners 19 Sep '08

19 Sep '08

Is it possible to determine when a child shred has finished executing if you have a reference to the child shred? For example, in this code: // define function go() fun void go() { // insert code } // spork another, store reference to new shred in offspring spork ~ go() => Shred @ offspring; Is it possible to determine when offspring is done executing?

3 2

infinitely stuck
by Kassen 19 Sep '08

19 Sep '08

Dear ChucKists, Another day, another novel and exciting way to get the whole VM stuck; Wurely w => dac; 1.0 / 0 => w.freq; 1 => w.noteOn; second => now; At a frequency of infinity (which admittedly is a bit silly but it happened by accident...) Wurley (and probably the other FM instruments as well, I imagine) gets completely stuck and takes 100% CPU time. This is quite understandable but what's not so nice is that this gets the whole VM stuck as well. Watchdog will offer to stop the shred (in the Mini) but fails... so that forces us to quit the whole thing the hard way. I think LiSa can cause a similar situation if we request a lot of voices very quickly, say one every few ms, and she runs out of voices (I'm not yet certain about the exact conditions there). Generally it seems like watchdog is unable to remidy the situation if it's a UGen and not a shred that gets stuck. I'm not sure how we should deal with this. Perhaps there could be some way to get watchdog to interupt UGens, or perhaps we should sanitise UGen function calls. I'm not sure, for example, whether there is a perceived need for fm electrical pianos to accept frequencies above the nequist... It probably can't be avoided that some things will get suck under some conditions but I would like to have some safeguards against this taking down the whole VM, where possible. Yours, Kas.

2 2

UGen v.s. code in timing; very tricky
by Kassen 19 Sep '08

19 Sep '08

Dear list. Suppose we have a SinOsc named "s", connected to the dac, that has been playing for some arbitrary amount of time at a arbitrary frequency. Suppose we'd like to disconnect this from the dac while minimising the "click". One thing to try would be this; (1 - s.phase() )::s.period() => now; //strong timing to the rescue! s =< dac; Quite ChucKian, I thought, however this still clicks a bit. Some clickery is to be expected as not all frequencies will have a period that can be expressed in a integer number of samp's but this seemed like a bit much. On a whim I tried; (1 - s.phase() )::s.period() + samp => now; s =< dac; This clicks less and when I print the s.last(), the value is on -average- lower in magnitude. I then tried lining up the shred's timing with the UGen graph's; samp - (now % samp) => now; //yes; that's quite anal (1 - s.phase() )::s.period() => now; s =< dac; This doesn't affect matters quite as much as simply adding a samp to the time advanced; waiting a extra sample generally seems (to me) to decrease the magnitude of the s.last() right before we disconnect it. This would lead us to ask; "where does this samp come from?". I'm a bit at loss here, does anybody have any insights? Yours, Kas.

4 7

determining the type of an Object in code
by mike clemow 17 Sep '08

17 Sep '08

Hi list, Is there a way to determine an object's type programmatically? Cheers, Mike -- http://semiotech.org http://semiotech.org/michael

8 27

Double ChucK cleanup (bug)
by Kassen 16 Sep '08

16 Sep '08

Fellow ChucKists, With the return of "double chucking" (making more then one connection between two UGens or a UGen and the dac) something seems to have gone wrong; SinOsc s=> dac; second=> now; s=> dac; second=> now; If this is run in a VM set to loop or a MiniAudicle with it's version of ChucK replaced with the latest greatest only a single connection will be cleaned up as the shred exits, meaning "s" will stay connected to the dac and as "s" is never garbage collected this means a beep. This also means there is no way at all to get rid of this beep (short of stopping the whole VM) as there is no way at all to reach the namespace "s" is/was in. I'm adding this to the WiKi as a bug. Yours, Kas.

3 5