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

mailing list problem
by Manfred Brockhaus 01 Oct '05

01 Oct '05

I have noticed that sending a reply on this mailing list doesn't work as usual. It seems that by default the reply message is not sent to the list but to the original poster. Can somebody else confirm this problem? -mb

3 9

Starting a blank ChucK program - How???
by Paco Salas 19 Sep '05

19 Sep '05

Hi, I´m trying to follow the ChucK Tutorial but there´s something I miss and it is related to starting a blank ChucK program. How is it made? Should I try vi (the text editor)? I´ve tried all the examples and they run ok, but how can .ck files be created? Thank you, Paco Salas

2 2

MacOsX install (newby)
by Hans Leeuw 17 Sep '05

17 Sep '05

Hi, I try to get chuck working. I can get it to execute files I made and also the examples. But it only works as commandline instruktions I do in Terminal. Is this all there is to Chuck? I don't believe so. I have the impression that I do something wrong with installing. Can anybody shred some light in the darkness? Best, Hans.

1 0

RE: [chuck-users] Problem with chuck language specification
by Robin Davies 16 Sep '05

16 Sep '05

You can call size() on a map. Works fine. I can't speak for all implementations, but Microft STL has a in internal _size member, so this is a low-cost operation. - Robin > -----Original Message----- > From: chuck-users-bounces(a)lists.cs.princeton.edu [mailto:chuck-users- > bounces(a)lists.cs.princeton.edu] On Behalf Of Ge Wang > Sent: Friday, September 16, 2005 1:25 AM > To: ChucK Users Mailing List > Subject: Re: [chuck-users] Problem with chuck language specification > > Hi Robin and all, > > > Problem: Chuck language definition uses cap(), when it should use > > size(). > > This is a good point to bring up. For now, we use cap() instead of > size(), because cap() means capacity whereas size() may have more than > one interpretation. However, size() is on the way. We plan to support > push_back() and pop_back() operations on arrays (as you saw in the > source), which would increment/decrement 'size' and manage the capacity > automatically. For this case, size() would make sense (and would be > more consistent with STL). > > If this naming turns out to be undesirable, we may modify it for a > future version. > > Another problem: we are trying find a good solution for to get the size > of the associative array, and maybe a way to iterate through the map. > Ideally, this would be concise, clear, and does not conflict with > operations dealing with the vector portion of the array. Thoughts > anyone? > > Best > Ge! > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

1 0

Cast of function argument
by Manfred Brockhaus 16 Sep '05

16 Sep '05

Implicit cast doesn't work if the function is 'sporked'. fun void foo(float x){<<<x>>>;} spork ~ foo(1); 1::second => now; prints 0 instead of 1. -mb

2 1

Problem with chuck language specification
by Robin Davies 16 Sep '05

16 Sep '05

Problem: Chuck language definition uses cap(), when it should use size(). An example from the Chuck language specficiation: http://chuck.cs.princeton.edu/doc/language/array.html // print it for( 0 => int i; i < bar.cap(); i++ ) <<< bar[0] >>>; } >From chuck_lang.cpp // array.cap() CK_DLL_MFUN( array_capacity ) { Chuck_Array * array = (Chuck_Array *)SELF; RETURN->v_int = array->capacity(); } >From STL docs: std::vector<xx>::capacity() The member function returns the storage currently allocated to hold the controlled sequence, a value at least as large as size One of these is wrong (probably not the STL docs. ;--) ). Either bar.size(), or array->size() would do it. std::vector<>::capacity() is not the same thing as std::vector<>::size(). It's common practice (if not a standards requirement) for STL implementations to grow arrays by doubling capacity() as the size() increases, instead of growing capactity() by one each time, becuase this provides O(1) performance for push_back instead of O(2) performance. Which brings me to my next feature request.... <grin> I don't suppose the Array push_back/pop-back/&c methods could be re-instituted? It's nice to have dynamic arrays; but, in the current implementation, there's no way to grow the integer-indexed portion of arrays. A use case: I'm writing VoiceManager, a voice-manager class, that implements polyphonic playing on classes that implement IInstrument. One of the parameters to VoiceManager is how many instances of the instrument to create. The problem: how to declar an array to hold the instruments? IInstrument instruments[]; Doesn't create an array. [] @=> IInstrument instruments[]; is gramattically illegal. IInstrument instruments[0]; isn't growable. The ideal solution: IInstrument instruments[]; .... instruments.push_back(instr); Tantalizing, because array_push_back is present in the sources, but doesn't seem to be implemented in the language. Priority of the feature request: nice to have, but not absolutely required. static members would be my first choice. I used IInstrument instruments[256]; to work around the problem. Best Regards, Robin Davies.

2 1

How to compare strings?
by Manfred Brockhaus 16 Sep '05

16 Sep '05

I'm trying to check strings for equality but the following doesn't work "abc" => string s; if(s=="abc"){<<<"yes">>>;} -mb

3 4

Bus error when defining two vars of the same type and on the same line in a class
by eduard 16 Sep '05

16 Sep '05

Hello all, I am getting Bus error when I define two member vars of the same type and on the same line in classes. example code: public class foo_class { float a, b; <-------- line causing the problem. fun void div(float x, float y) { x => a; y => b; <<< "result: ", x/y >>>; } } // end_of_foo_class // instantiation: foo_class foo; // call function: here comes the problem foo.div(); The problem arises when any member function is called. No problems at all when instantiating. However if one replaces the line " float a,b; " by separate declarations of a and b then it works fine, thus: float a; float b; I've not been able to reproduce the error when float a, b; is declared outside of a class. Thus the following works ok: float a, b; fun void div(float x, float y) { x => a; y => b; <<< "result: ", x/y >>>; } while( true ) div( std.rand2f(0.0001, 1), std.rand2f(0.0001,1) ); Eduard

2 1

ADSR release time
by Manfred Brockhaus 15 Sep '05

15 Sep '05

I'm wondering how to handle ADSR release time correctly. In theory the following should work: sinosc s => ADSR e => dac; s.freq(1000); e.attackTime(0.1); e.decayTime(0.2); e.sustainLevel(0.5); e.releaseTime(0.01 => float r); e.keyOn(1); 1::second => now; e.keyOff(1); r::second => now; However, for small values like 0.01 above I get a click at the end. Any ideas? -mb

1 0

Why do child shreds get killed?
by Robin Davies 06 Sep '05

06 Sep '05

Currently, if a shred terminates, all of its child shreds get terminated as well. This raises the following interesting question: why? Honestly, from a user's perspective, I can't think of a compelling use of this feature. Whether there are internal implementation issues that motivate this feature or not is a separate question, I guess; but I can't really think of a good reason to terminate child shreds from an implementation perspective, either. (Unless you're relying on shred termination to garbage collect). On the other hand, I can think of very compelling reasons why shreds should not outlive their parents. I've been bitten by this several times - by shreds silently being terminated because parent shreds have terminated. Here's my compelling use case for allowing shreds to outlive their parents. I spent the weekend playing with chuck. With audio languages (CSound, SAOL, Music-N, &c), one of the constant challenges is how to provide clean and modular integration between expensive control-rate operations, fast audio-rate operations, and external events. Having had exposure to MusicN based languages that provide control-rate processing, I thought I'd try using the control concept in chuck. Here's the theory: write an IInstrument abstract class that provides an abstract Tick() method which gets called at control-rate. Output of the instrument is placed on the Instrument.Out ugen so that instruments can then be routed onto an external output. Implementations of IInstrument then call (for example) StartTick(16::samp), which causes the Tick method to be called every 16 samples on a separate shred. This works very well. The end result: an AnalogSynth class, implementing IInstrument, that provides two two control-rate lfos, two control-rate envelopes, one band-limited oscillator ugen (private build coming to a Chuck near you soon) and a filter ugen. AnalogSynth runs about 12 voices in realtime on my lowly 800Mhz home machine, without any real attention to optimization! So far so good. The purpose of the Tick() processing is,of course, to run the LFOs and ADSrs at reduced rate (every 16 samples), and then perform all of the expensive routing of lfos and ADSrs outputs onto UGens at something less than audio rate. Well. It does work very well, as long as I drive the IInstrument from midi or OSC input. It fails spectacularly if notes are triggered from temporary shreds when writing scores in Chuck. Consider the following: function void PlayNote(IInstrument instr, float midNote, dur length) { instr.NoteOn(midiNote,1.0); length => now; instr.NoteOff(midiNote); } spork ~ PlayNote(analogSynth, Midi.C4, 1.5::beat); This fails, spectacularly. Internally, the Tick shred gets started up, but it shuts down as soon as the PlayNote shred terminates (causing the note to get stuck). In retrospect, I guess the answer is to create a tick shred at the time the instrument is created, and then use events to synchronize the tick shred. But that's just so... so... inconvenient. Or another approach: make PlayNote wait forever, after the note off. But that's just so... so.... ugly. Hmm. Or maybe a WaitForAllChildThreadsToDie() function. The event solution also runs into significant problems with controlling the first tick after startup. Consider: An IInstrument receives a note-on event. It initializes all of it's control rate state variables (reseting ADSRs, for example). Now it needs to start the tick shred up. So it signals an event. The question is this: will the tick shred run in the current cycle or not? If it doesn't then StartTick() should call IInstrument.Tick(). But whether the shred ran in the current thread or not is non-deterministic. It depends on whether the shreduler ran the current thread or the tick thread first for the current value of Now. Even worse. The tick shred can no longer perform "16::samp => now", because the noteon event may have arrived at some non-modulo-8 mutiple of now::samp. So this approach requires complicated and expensive handshaking between the Instrument and its tick thread to get everything lined up and operating deterministically. (<thinking>... this is doable, and probably the way I'll go) Or another use-case for the same: function void PlayTheWholeSong() { Spork ~ PlayBassMotif1(); Spork ~ PlayMelody1(); 12::beat => now; Spork ~ PlayBassMotif1(); Spork ~ PlayMelody2(); // oops. No more bass motif or melody shred. } The feature request; maybe a way to let shreds re-assign their parent shred to the root shred. That would be nice. Or maybe just don't terminate child shreds at all. Robin Davies Lead Software Developer Quest Web Reports Quest Software 613.270.1569 Identity Management for the Windows Enterprise <http://wm.quest.com/reg/marketing/landing/identitymanagement/> : See how Quest helps you leverage your existing investment to solve the identity management challenge!

3 2