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

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

18 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 07 Sep '05

07 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

OTF not working...
by Furlan Primus 04 Sep '05

04 Sep '05

Time-stamp: <2005-09-03 19:09:47 flp> Hi, While testing the examples, following the directions in otf_01.ck I opened a second tab / terminal and entered "chuck + otf_02.ck" which returned "operation sucsessful" I switched to the first terminal and got: [flp@magicbox 0002]$ chuck --loop [chuck](VM): sporking incoming shred: 1 (otf_01.ck)... *** Fatal error : sizeof (off_t) != sizeof (sf_count_t) *** This means that libsndfile was not configured correctly. ========================= What am I doing wrong? ChucK was compiled sucessfully AFAIK. TIA ciao, furlan -- Home: http://flprim.us/index.html "The cure for boredom is curiosity. There is no cure for curiosity." -- Dorothy Parker

2 2

ADSR envelope
by Manfred Brockhaus 02 Sep '05

02 Sep '05

I'd like to know the following which I didn't find in the documentation. - default values of A,D,S and R - default rates of A,D and R Also, I've noticed that user defined value assignments if any must be written in the order A-D-S-R to work properly. Is this true? -mb

1 0

Re: [chuck-users] OSC receiver
by Manfred Brockhaus 01 Sep '05

01 Sep '05

On Aug 31, 2005, at 10:49 AM, Philip Davidson wrote: > process removal uses the shred number, rather than the name > -see the VM documentation for retreiving this using machine.status Thanks, I got it. Works perfectly. Just found a minor issue related to OSC. When receiving an OSC event containing a string parameter (eg. "abc") I get an additional message add string |abc| ( 4 ) Looks like some debugging code... -mb

2 1

Re: [chuck-users] OSC receiver
by Manfred Brockhaus 31 Aug '05

31 Aug '05

On Aug 31, 2005, at 8:31 AM, Philip Davidson wrote: > This is a slightly different issue - you appear to be launching two > separate chuck VM's - for instance > chuck program1.ck in a terminal window, > and then 'chuck program2.ck ' in another terminal. > > the chuck VM binds to port 8888 by default in order to listen for > incoming VM messages on the same machine, or over the network. > If two VM's are launched, the second won't be able to make the > connection, and thus prints the error message. > > by using the > %chuck --loop > option, chuck will background itself and wait for incoming message, and > you can then use > %chuck +program.ck > to add a new program to the VM Thanks for the explanation. Makes sense. However, removing the program doesn't seem to work for me. When using %chuck - program.ck I get the message [chuck](VM): cannot remove: no shred with id 0... -mb

2 1

OSC receiver
by Manfred Brockhaus 30 Aug '05

30 Aug '05

Hi, congratulations on the new release! I'm on OS X and in particular interested to use MIDI and OSC events. So far MIDI in/out seems to work fine here. OSC send works too, but with the example 'opensound_demo_recv.ck' I get an error message: class 'OSC_Recv' has no member 'event'. -mb

2 1

[solution] compile and link problem under FC3...
by Furlan Primus 28 Aug '05

28 Aug '05

Hi, Earlier today I had trouble compiling and linking the 'Dracula' version of ChucK. After some emails to Ge Wang a solution was found. The problem was that when compiling for linux-alsa it was looking for a file called sndfile.h and that file was NOT on my system as I have a precompiled version of libsndfile. The solution was to follow the directions in the makefile.alsa file: #----------------------------------------------------------------------------- # by default, ChucK on linux needs libsndfile... # comment the next 3 lines to use a pre-configured libsndfile #----------------------------------------------------------------------------- # FLAGS+= -D__CK_SNDFILE_NATIVE__ # LIBS+= -lsndfile # SF_OBJ= Once that was commented out (as above) the compilation & linking went without any further delay. Maybe this will assist someone else who experiences a similar problem. ciao, furlan -- Home: http://flprim.us/index.html Ambition is a poor excuse for not having sense enough to be lazy. -- Milan Kundera

2 1

Re: chuck Digest, Vol 18, Issue 3
by Jeffrey Treviño 28 Aug '05

28 Aug '05

Congratulations on the release! I look forward to learning all the new stuff you've made. A quick question that I need to answer for a potential Chuck project: is there a Chuck function that returns today's date in some form? I remember a built-in function in C that did this–is there a Chuck equivalent? Again, excellent work and congrats on the release. As soon as the Audicle gets set, I can sit out front with a projector and amaze unwitting passersby. --Jeff On Aug 25, 2005, at 9:00 AM, chuck-request(a)lists.cs.princeton.edu wrote: > Send chuck mailing list submissions to > chuck(a)lists.cs.princeton.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.princeton.edu/mailman/listinfo/chuck > or, via email, send a message with subject or body 'help' to > chuck-request(a)lists.cs.princeton.edu > > You can reach the person managing the list at > chuck-owner(a)lists.cs.princeton.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of chuck digest..." > Today's Topics: > > 1. version 1.2.0.0 (dracula) released (Ge Wang) > 2. spork ~ chuck-users ( new mailing_list + more ) (Ge Wang) > > From: Ge Wang <gewang(a)CS.Princeton.EDU> > Date: August 25, 2005 6:07:57 AM PDT > To: ChucK Audio Programming Language Mailing List > <chuck(a)lists.cs.princeton.edu> > Subject: [chuck] version 1.2.0.0 (dracula) released > > > Dear All, > > chuck-1.2.0.0 is released. (Sorry.) This is the "v2" major release. > Additions include arrays, objects and classes, events, and more. A > full list of new and updated features can be found at the end of this > email. > > http://chuck.cs.princeton.edu/ > > We have also put together a draft of a language specification > (finally). It is not complete yet and will be improved as (real) time > is advanced: > > http://chuck.cs.princeton.edu/doc/language/ > > We have been testing this release along the way. However, since this > is the initial release, there is probably a healthy amount of > egregious bugs! Please let us know if you run into anything fishy > (email one of us directly, post to chuck-dev or the newly created > chuck-users list). Same goes for the documentation. Actually, any > type of feedback would be greatly appreciated. > > Many thanks to the great people who have contributed ideas, code, and > time to this release! Thanks to everyone for being so patient with > this release. > > Development shall continue as we fix the bugs, add new features (and > more bugs). > > Please let us know if you run into any problems. HappY ChucKing! > > Best, > ChucK Team > (Perry, Ananya, Phil, Adam, Ajay, Ge ...) > > --- > 1.2.0.0 > > SYNTAX and OPERATORS: > - (added) +=>, operator : 2 +=> i; (also) -=>, *=>, /=>, %=> > - (added) @=> for explicit assignment > this is the only way to make object reference assignments > - (added) implicit int to float casting > - (changed) cast now look like: 1.1 $ (int) => int i; > - (added) function call by chucking : > // call > (1,4) => math.rand2f => result; > // same as > math.rand2f(1,4) => result; > > LANGUAGE: > - (fixed) type system for existing types > - (added) forward lookup of classes and functions (mutual recursion) > - (added) stack overflow detection for massive recursion > > DOCUMENTATION: > - (added) language specification: > http://chuck.cs.princeton.edu/doc/language > > COMMAND-LINE: > - (added) --probe prints all audio and MIDI devices > - (added) --log or --verbose logs compiler and virtual machine > - (added) --logN or --verboseN multi level logging > 1 - least verbose > 10 - most verbose > > OBJECTS: > - (added) 'class' definitions : class X { int i; } > - (added) 'extends' keyword : class Y extends Event { int i; } > - (added) virtual/polymorphic inheritance > - (added) added pre-constructors - code at class level > gets run when object is instantiated > - (added) function overloading : > class X { fun void foo() { } fun void foo( int y ) { } } > - (added) base classes (can be extended): > Object, Event, UGen > see below > - (added) base classes (cannot be extended): > array, string > see below > - (added) member data > - (added) static data > - (added) member functions > - (added) static functions > > EVENTS: > - (added) base Event class : Event e; > can be used directly > can be extended to custom events > (see one_event_many_shreds.ck) > - (added) waiting on event, chuck to now : > e => now; // wait on e > - (added) e.signal() wakes up 1 shred, if any > - (added) e.broadcast() wakes up all shreds waiting on e > - (added) class MidiEvent (see gomidi2.ck) > alternative to polling. > - (added) class OSCEvent > > ARRAYS: > - (added) arrays : int a[10]; float b[20]; Event e[2]; > - (added) multidimensional arrays : int a[2][2][2]; > - (added) associative arrays : int a[10]; 0 => a["foo"]; > all arrays are both int-indexed and associative > - (added) array initialization : [ 1, 2, 3 ] @=> int a[]; > - (added) .cap() for array capacity > - (added) .find() test if item is associative array > - (added) .erase() erase item in associative array > > UGENS: > - (added) class UGen > can be extended > - (changed) all ugen parameters are now also functions: > // set freq > 440 => s.freq => val; > // same as... > s.freq( 440 ) => val; > - (changed) left-most parameters must now be called as functions > // no longer valid > f.freq => float val; > // valid > f.freq() => float val; > // still ok > 440 => s.freq => float val; > > SHREDS: > - (added) class Shred > - (added) .yield() .id() > > STRINGS: > - (added) class string > > AUDIO: > - (added) stereo > all stereo unit generators have .left, .right, .pan functions > - (changed) stereo ugen: dac (2 in, 2 out) > - (changed) stereo ugen: adc (0 in, 2 out) > - (added) stereo ugen: pan2 take mono or stereo input and pans > - (added) stereo ugen: mix2 mix stereo input into mono > > > > > > From: Ge Wang <gewang(a)CS.Princeton.EDU> > Date: August 25, 2005 6:12:07 AM PDT > To: ChucK Audio Programming Language Mailing List > <chuck(a)lists.cs.princeton.edu> > Subject: [chuck] spork ~ chuck-users ( new mailing_list + more ) > > > Dear All, > > Along with the new release, we have made a new mailing list > (chuck-users), intended for specific questions and discussions about > using chuck. This list (chuck) will (soon) become a moderated, > low-traffic mailing list intended for updates, announcements, > tutorials, and low-bandwidth discussions. > > Hopefully the folks that are interested in chuck can remain on (chuck) > without being potentially spammed too much, and those that have > specific questions can fire away on (chuck-users) with a clean > conscience! > > Additionally, we have been graciously given permission to abuse an > entity called 'soup kitchen'. It is the state-of-the-art in > anti-social networking. It contains many nice features (all > conversations are by default world-readable, optional email > notification of new replies to topics, and is rather elegant) that may > be to useful as a semi-realtime semi-anonymous forum. The author, > Visnu Pitiyanuvath, will work with us to further enhance the site to > make it more useful and fun. > > Links to all the lists and soup kitchen can be found here: > > http://chuck.cs.princeton.edu/community.html > > Join, if you like. Have fun! > > Best, > ChucK Team > > > > > _______________________________________________ > chuck mailing list > chuck(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck

2 1

load_dll from chuck code?
by Robin Davies 28 Aug '05

28 Aug '05

I'm very excited to see Chuck 1.2.2.0, and I'm eager to start tweaking. I'd particularly like to get started on writing external C++ UGens for Chuck. I own source for some particularly useful functions that I'd love to get tied into Chuck (intention to donate as an external project), but I can't seem to find the procedure for loading an external dll either from Chuck code, or from the command-line, or otherwise. All the code seems to be there to load an external DLL, but it doesn't seem to be hooked up to anything yet. Am I missing something? Are there any immediate plans to expose this, or should I get busy hacking away? UGens that I'm interested in implementing: - hosting VST plugins in chuck (a huge priority for me, have source code, will integrate, if nobody else is doing this) - maybe Chuck as a VST plugin (not a huge priority for me) - Some more basic instrument building blocks for ugens, band-limited waveforms, particulary. - High-quality sample interpolators. Is anyone else out there doing 3rd-party development for Chuck yet? I'd be interested in sharing plans and priorities. Regards, Robin Davies

2 1

OSC utilies/programs for Win32?
by Robin Davies 27 Aug '05

27 Aug '05

Does anyone know of a source of OpenSoundControl utilities for Win32? Something to test-drive chuck's support for OSC would be great. Something to do basic sequencing would be greater. Something to drive chuck from buildable GUI would be greater still. Regards, Robin Davies

2 1