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

audicle question
by Ken 04 Nov '05

04 Nov '05

i read the .pdf about the audicle and a quick question i have about the user programmable face, will it be possible to create synth interfaces in opengl, and 3d graphics projection for vj projects within chuck? thanks, ken

2 1

RE: [chuck-users] include
by Robin Davies 01 Nov '05

01 Nov '05

There were remnants and vestiges of an "auto-include" feature in Chuck sources last time I looked. These looked fairly promising. I'm not sure what the original intent was -- it didn't seem to be terribly functional in the last set of sources I looked at, but the general intention seemed like a good idea. As I read it, the intention was to look for a matching source file for undefined classes and load the matching source file on demand. The complication, presumably, is that the class implementations have to be loaded in multiple steps: parse all declarations of auto-included files first, and then bind references in a separate pass, in order to avoid problems with circular references. The code for the multi-step binding seems to be mostly there too -- more there, than the auto-include flag, anyway. The basic idea seemed sound, and is somewhat better than providing a lexical include facility. > -----Original Message----- > From: chuck-users-bounces(a)lists.cs.princeton.edu [mailto:chuck-users- > bounces(a)lists.cs.princeton.edu] On Behalf Of Rasmus Kaj > Sent: Tuesday, November 01, 2005 2:16 PM > To: ChucK Users Mailing List > Subject: Re: [chuck-users] include > > >>>>> "PD" == Philip Davidson <philipd(a)CS.Princeton.EDU> writes: > > PD> yes, but it's in development / testing phases. > > Ah, I should take a look at that, then ... Is it a "simple lexical" > include (like with the c preprocessor), or is it in a higher level, > (what I'd like to call require/provide, like in elisp), so that the > included code only needs to be compiled once? > > Basically, I'd like "require foo" to check (in a hash table) if foo > allready is provided, and in that case just return. If foo isn't > provided, it could search the load path for "foo.ck", and compile that > if found. > > This would be very simple given a global namespace for functions and > classes (so that the classes in foo is available for all shreds when > foo is required in one). Otherwise require would also have to include > the foo namespace into the current namespace. > > -- > Rasmus Kaj --+-- rasmus(a)kaj.se --+-- http://www.stacken.kth.se/~kaj/ > Det är alldeles för mycket sport inom idrotten > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

1 0

include
by Atte André Jensen 01 Nov '05

01 Nov '05

Is there an include or equivalent in chuck (Still thinking about how to modulize code)? -- peace, love & harmony Atte http://www.atte.dk

3 3

emacs.el?
by Ken 01 Nov '05

01 Nov '05

i read somewhere that there is a chuck mode for emacs, but i can't seem o find it. does anyone have that available? thanks, ken

4 6

which language?
by Ken 31 Oct '05

31 Oct '05

i'd like to take a stab at developing for chuck. which language do i need to develop in? is c supported? Thanks, Ken

2 1

building an instrument library
by Atte André Jensen 30 Oct '05

30 Oct '05

Hi I'm just beginning to explore chuck. I set out to find a way to seperate instrument definitions from note-playing-code. I wrapped up my result so far and put them here: http://www.atte.dk/download/modular_instrument_defs.tgz The README.txt explains what to do with it, but let me re-state the problems I have: 1. Removing a shread (by "chuck - SOME_ID") stops the shred in the middle of the current note, resulting in a click. 2. Since a new shread is sporked on each note, the shread ID's quickly grow to inconveniently large proportions. The reason for sporking each note is an attempt to rid the pattern of any knowledge of the time it actually takes to play the note. 3. Sometimes adding the hh.ck pattern (not the instrument) is playing the first note very loud. Of course this is heavily inspired by the otf_* files and reveals my so far very limited understanding of chuck. But eventually I think some way of seperating out instrument design (and other stuff as well; keys, scales, tempo and meter comes to mind) would benefit my productivity in the long run... I'm not at all sure that this is the way to go, so I'd appreciate any feedback. How many of my problems are due to bugs, wrong implementations or conceptual misunderstanding? -- peace, love & harmony Atte http://www.atte.dk

1 0

2 questions
by Atte André Jensen 29 Oct '05

29 Oct '05

Basically: 1) I'd like to define a library of instruments for reuse. Seems like this *could* be achieved by defining one class per .ck file and adding these files (possibly by a script) to a running chuck before use. Has the disadvantage that the first zillion shreds will be taken up by instrument-def files, not too handy if a replace/remove a schred. Is there a best/better way to do this? I found no include, did I overlook something? 2) Supposed I want to do a slightly complex pitch envelope. How is that best achieved? Which example to look at? -- peace, love & harmony Atte http://www.atte.dk

1 0

1.2.0.3 compilation problem
by Michal Seta 29 Oct '05

29 Oct '05

Hello all, First of all, I am glad to see that since 1.2.0.1 the linux version of chuck behaves so much nicer! (for me, anyways) I jumped to the 1.2.0.3 now and can't get it to compile: make -f makefile.jack make[1]: Entering directory `/home/mis/downloads/chuck-1.2.0.3/src' gcc -D__LINUX_JACK__ -O3 -c -D__CK_SNDFILE_NATIVE__ chuck.yy.c chuck.lex: In function `block_comment': chuck.lex:280: error: `yytext_ptr' undeclared (first use in this function) chuck.lex:280: error: (Each undeclared identifier is reported only once chuck.lex:280: error: for each function it appears in.) make[1]: *** [chuck.yy.o] Error 1 make[1]: Leaving directory `/home/mis/downloads/chuck-1.2.0.3/src' make: [linux-jack] Error 2 (ignored) 1.2.0.1 compiled fine, have the requirements changed since then? thanks (should this be going to chuck-dev or something? I'm subbed to this list only). ./MiS

2 3

A polymorphic OSC function?
by Ollie Glass 28 Oct '05

28 Oct '05

Hello Chuckers. Is it possible to receive any OSC event with a single event and function? In my code I create several events like this: recv.event( "/setStep,i,i,i" ) @=> OscEvent oe; recv.event( "/setBpm,f" ) @=> OscEvent obpm; recv.event( "/openWave,i,s" ) @=> OscEvent owave; Then I spork listener threads for each one: fun void bpmListener() { while ( true ) { obpm => now; while ( obpm.nextMsg() != 0 ) { ... spork ~ bpmListener(); fun void openListener() { while ( true ) { owave => now; while ( owave.nextMsg() != 0 ) { ... spork ~ openListener(); etc. So I create an event, function and thread for every OSC message I want to receive. Is there a way to make a polymorphic function that can recieve any OSC event with some if / else statements to switch based on what the message is? Any sample code would be much appreciated. Thanks, Ollie

2 1

Minimal example not working.
by Erik de Castro Lopo 22 Oct '05

22 Oct '05

Hi all, I'm just trying to get a minimal example going. I've currently got this: sinosc s => dac; 440. => s.freq; while(true){ 1::second => now; } When I run it I get: [chuck]: RtApi: no devices found for given stream parameters. [chuck]: cannot initialize audio device (try using --silent/-s) I compiled chuck to run using linux-alsa and I'm running it on an Apple iBook running Debian Linux. ALSA is know to work correctly on this machine. Any help appreciated. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Data is not information, Information is not knowledge, Knowledge is not understanding, Understanding is not wisdom." -- Clifford Stoll

2 4