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

fm?
by eun.sung＠no-log.org 09 Mar '06

09 Mar '06

hi list i try to play around the fm unit generator and i can't make it work although i can use class depending on the FM class (TubeBell for example). this simple code make my jack server break out : FM f => dac; 400.0 => f.freq; while(true){ 1.0 => f.noteOn; 10::ms => now; } does anyone had already met some trouble with this class?

4 5

wiki operational
by Ge Wang 06 Mar '06

06 Mar '06

Greetings! The new wiki is now _the_ wiki: http://wiki.cs.princeton.edu/index.php/ChucK And the old wiki is well the old wiki: http://wiki-old.cs.princeton.edu/index.php/ChucK Links updated from main page and community. Best, Ge!

2 1

honking STK Ugens 1.2.0.4
by Graham Coleman 06 Mar '06

06 Mar '06

Some of the STK UGens seem to "honk" if you don't send them an initial noteOff message. Here is an illustration: FMVoices inst => PRCRev rev => dac; //inst.noteOff( 0.5 ); 2::second => now; for (0=>int i; ; i++) { if ( i%2 == 0 ) 440 => inst.freq; else 880 => inst.freq; inst.noteOn( 0.5 ); 1::second => now; } I count FMVoices, Mandolin, VoicForm, Moog, BeeThree, HevyMetl, and PercFlut that do this. Also, PercFlut, BlowHole, and TubeBell seem to have some funny ideas of pitch. best, Graham

3 3

for your entertainment: recent ChucK musics
by Graham Coleman 05 Mar '06

05 Mar '06

Enjoy! three ChucK sketches: http://cola-fan.livejournal.com/94685.html ChucKular automata: http://cola-fan.livejournal.com/93315.html I'd appreciate any comments on these. Many thanks to Ge, Perry, and the ChucK team for a great musical instrument. Graham

1 0

Status of 1.2.0.5
by Mike McGonagle 05 Mar '06

05 Mar '06

Hello Ge, I know you are probably swamped, but I was wondering what the time table for releasing the next version would be? Also, you have mentioned that there is a CVS archive of everything. Is that accessible to the public? I don't mean to sound like I am chomping at the bit, but most of the problems that I have sent to you, that you have fixed, are ones that have me stymied in making further progress. Thanks, Mike

2 1

recording with rec.ck: stereo and clipping
by Graham Coleman 05 Mar '06

05 Mar '06

Several problems I've noticed recording from command-line chuck (win32): 1. All the UGens in my chucKestra are connected to pan2 objects, then the dac, but the recording comes out mono (standard rec.ck). Is this due to the way stereo and mono ugens connect together? Is there some way I can get the stereo recording from the console? 2. I often get digital clipping on a few samples in a several minute piece. It seems like a job for some dynamics or soft clipping at the end of the chain, right? Is there something I can use? I guess I could try writing a sample-level limiter in ChucK. (One reason this may be happening is that the center or DC of the waveform seems to drift up and down towards the edges without being too loud, lately I've been using lots of FMVoices with reverb. This seems different from what a recorded sound would do) best, Graham

5 5

chuck wiki uploading, old links
by Graham Coleman 04 Mar '06

04 Mar '06

When I tried to upload my version of chuck-mode.el at the upload page: http://wiki-new.cs.princeton.edu/index.php/Special:Upload I type in the file details, and then I get this: Upload warning ".el" is not a recommended image file format. and it doesn't show up in the uploaded file list: http://wiki-new.cs.princeton.edu/index.php/Special:Imagelist Is there something I'm missing? Also, it seems that the wiki link on this page: http://chuck.cs.princeton.edu/community/ still points to the old wiki. best, Graham

2 2

Longish example with 2 problems...
by Mike McGonagle 03 Mar '06

03 Mar '06

/* This discusses two different problems. As the goal is to work with granular synthesis, the time scale is something of concern. 1. Time is NOT necessarily infinitly controllable. a time of (sample-rate * .5) seems to be a comfortable limit for the "synchronization" of shreds when using flags to control execution. (having only tested this with one sample rate [default], on one platform [10.3.9, using 1.2.0.4], I am not quite certain about this assertion...) 2. 'spork' appears to have some trouble when used within a function (I get the same results when trying to use within an Object function as well). I want to use two shreds to control two different layers of a composition. the bottom layer (MaskComposition.perform) controls the ranges for each synthesis parameter, while the top layer (MaskComposition.execute) is a means of selecting a value for each of the synthesis parameters. In building this piece/program, I discovered that, while trying to use a flag to control a "main" (while(inPerformance) from MaskComposition.execute) loop, there appears to be an oddity in how ChucK handles time. I had first discovered that to get the main loop to generate any data, it had to be delayed a small amount of time to ensure that the control flag was set. Later, as I tried to extend the main loop for additional iterations, I found that the main loop may or may not execute with each iteration. With some additional experimentation, I found that the interval of time that the main loop is delayed will effect weather or not the main loop gets executed. I found that values below half the sample rate for the delay may or may not allow the loop to execute. Once this delay is set to half the sample rate, it successfully executed the main loop without dropping any iterations. The point at which this "error" shows up is when the inner loop (while(inPerformance)) does NOT execute because the child shred has NOT set 'inPerformance' to true yet. what issues are there that concern "control" flags (i.e. 'inPerformance')? is there a better mechanism that would produce reliable results with times less than half the sample rate? what is the smallest unit of time that ChucK can reliably execute? is this a scheduling issue of each of the child and parent shreds? */ fun float at() { return now / 1::ms; } fun float dur_ms(dur d) { return d / 1::ms; } class MaskComposition { 1::samp / 2 => dur tolerance; false => int inPerformance; /* represents the bottom layer for controlling a set of parameters. */ fun void perform(float d[][], int iteration) { <<< at(),"perform", d.cap(), inPerformance, iteration >>>; if (inPerformance) { <<< at(), "returning from perform", iteration >>>; return; } true => inPerformance; for(0 => int i; i < d.cap(); i++) { now + d[i][0]::ms => now; } <<< at(),"finished doing something:", iteration >>>; false => inPerformance; } /* used to generate a "score" for perform. a score is a time ordered table (array of arrays) of floating point. the first element in each of the arrays is considered to be a "delta-time", or the time until the next item in the table should be triggered. the tables can be explicitly defined, or generated programmatically, or anywhere inbetween. */ fun float[][] compose() { <<< at(),"compose", "" >>>; return [ [ 250.0, 0.0 ] ]; } fun void execute(float tol, int times) { 0 => int iter; 1::samp / tol => tolerance; <<< at(), "tolerance:", dur_ms(tolerance) >>>; while(iter < times) { <<< at(), "trying to do something.", "" >>>; spork ~ perform(compose(), iter); now + tolerance => now; while(inPerformance) { (0.01, 3.0) => std.rand2f => float onset; <<< at(), iter, onset >>>; now + onset::ms => now; } 1 +=> iter; } } } MaskComposition mine; /* this function encapsulates the stuff just past the end of this commented block. as far as I can tell, it does the same thing as below, except that when it gets executed, it generates an error of [chuck](VM): NullPointerException: shred[id=285:spork~exp], PC=[3] the only sense I can make of this is that 'spork' can't produce another shred, but is this error because this 'spork' is inside a function? */ fun void ex(MaskComposition mc, float tol, int t) { 0 => int iter; 1::samp / tol => mc.tolerance; <<< at(), "tolerance:", dur_ms(mc.tolerance) >>>; while(iter < t) { <<< at(), "trying to do something.", "" >>>; spork ~ mc.perform(mc.compose(), iter); now + mc.tolerance => now; while(mc.inPerformance) { (0.01, 3.0) => std.rand2f => float onset; <<< at(), iter, onset >>>; now + onset::ms => now; } 1 +=> iter; } } /* // the following three segments are intended to operate separately. // seg 1 - this code generates an error ex(mine, 3, 100); ex(mine, 2.1, 100); ex(mine, 2, 100); */ /* // seg 2 - as well as this. I tested this to see if 'ex' being sporked would make a difference. it doesn't. spork ~ ex(mine, 3, 100); now + 30::second => now; */ /* // seg 3 - this also produces the same error. mine.execute(3, 100); mine.execute(2.1, 100); mine.execute(2, 100); */ //* seg 4 - the "explicit" version, and the only one that works... 0 => int iteration; 100 => int times; 1::samp / 3 => mine.tolerance; <<< at(), "tolerance:", dur_ms(mine.tolerance) >>>; while(iteration < times) { <<< at(), "try to do something.", "" >>>; spork ~ mine.perform(mine.compose(), iteration); now + mine.tolerance => now; while(mine.inPerformance) { (0.01, 3.0) => std.rand2f => float onset; <<< at(), iteration, onset >>>; now + onset::ms => now; } 1 +=> iteration; } 0 => iteration; 1::samp / 2.1 => mine.tolerance; <<< at(), "tolerance:", dur_ms(mine.tolerance) >>>; while(iteration < times) { <<< at(), "try to do something.", "" >>>; spork ~ mine.perform(mine.compose(), iteration); now + mine.tolerance => now; while(mine.inPerformance) { (0.01, 3.0) => std.rand2f => float onset; <<< at(), iteration, onset >>>; now + onset::ms => now; } 1 +=> iteration; } 0 => iteration; 1::samp / 2.0 => mine.tolerance; <<< at(), "tolerance:", dur_ms(mine.tolerance) >>>; while(iteration < times) { <<< at(), "try to do something.", "" >>>; spork ~ mine.perform(mine.compose(), iteration); now + mine.tolerance => now; while(mine.inPerformance) { (0.01, 3.0) => std.rand2f => float onset; <<< at(), iteration, onset >>>; now + onset::ms => now; } 1 +=> iteration; } //*/

2 2

Globally shared functions
by Mike McGonagle 03 Mar '06

03 Mar '06

Hello all, I was wondering if there is a way to create a global function that could be shared by many public classes? I had been working with some functions that were NOT in a class, but once I changed the class to public, those functions were no longer accessible, even though they were in the same file. Mike

3 2

Looping Sample Playback
by Mike McGonagle 28 Feb '06

28 Feb '06

Hello all, I was wondering if there is a ugen that will handle arbitrary looping points? I have some samples for various instruments (ie piano, mellotron strings, etc), and would like to hook them up in ChucK. Basically, if the sndbuf ugen is the starting point for this, then do I need to write my own "looping" function to ensure that it gets back to the proper points within the sample. Or has someone already implemented this functionality and would be interested in "sharing"? Thanks, Mike

4 7

Re: chuck-users Digest, Vol 7, Issue 22
by Jim Hinds 28 Feb '06

28 Feb '06

Good analysis. However, from a probablistic viewpoint the time-out problem is vanishingly small for a lightly loaded local network (that's why UDP works very well for machine control applications REF: sixnet protocol). Pretty much give the perfomer the ability to get his files over to the server. If he is really worried about time-outs, the logical thing to do is to structure those chuck scripts to load the needed files prior to starting the sound emitting spork-ettes. Jim On Feb 27, 2006, at 7:29 PM, chuck-users- request(a)lists.cs.princeton.edu wrote: > From: Ge Wang <gewang(a)CS.Princeton.EDU> > Date: February 27, 2006 6:17:59 PM HST > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Subject: Re: [chuck-users] file open semantics for clustered chuck > Reply-To: ChucK Users Mailing List <chuck- > users(a)lists.cs.princeton.edu> > > > Hi! > >> Since an important usage mode for chuck is analogous to a server >> for multiple performers, I'd like to suggest that the file open >> semantics be extended. > > Great idea, though there are certainly more issue to consider for > remote operations, since they often aren't always as transparent as > their interface advertises. For example, network timeouts when > retrieving a file need to handled. Actually this seems to be part > of a similar problem of pre-loading/chunking sound files to avoid > interruption on large sound files. So, we should probably add some > options to control load behavior. > >> By simply extending the semantics for Chuck's "open" from >> expecting a file name, I suggest that it be a URL instead. If the >> filename starts with http:// or ftp:// or other legal prefix, give >> the URL to a curl library for access. > > Cool. The .open function already examines the path to catch > "special" internal data (i.e. "special:glot_pop"). It would make > sense to extend that to URL. We just need to find a way to semi- > gracefully deal with potential network timeout and lag. > > Thanks. We shall look into this. > > Best, > Ge!

1 0

Creating Traditional Instrument Sounds Using OSC (ChucK vs. SuperCollider)...
by DANIEL MAGNUSZEWSKI 28 Feb '06

28 Feb '06

All, I hope this is not off topic :-) I have been playing with SuperCollider for a week or two since reading an article on creating live music with Perl code (http://toplap.org/index.php/Hacking_perl_in_nightclubs). Note - I am a programmer (mainly Perl), but quite a newbie with live coding and I know little to nothing about writing ChucK/sclang code. Essentially, there is an editor called feedback.pl (http://cpan.org/authors/id/Y/YA/YAXU/perl-music-article/examples/feedback-0…) that allows you to write Perl code that will create OSC messages that will be sent to SuperCollider. SuperCollider is running the following code (http://cpan.org/authors/id/Y/YA/YAXU/perl-music-article/examples/simple.sc) that, from my understanding, the simple.sc script listens for OSC messages, of which I can send from feedback.pl using built in methods 'play' and 'trigger'. For Example (Perl Code): sub bang { my $self = shift; # play a "middle c" note every fourth bang $self->play({num => 60}) if $self->{bangs} % 4 == 0; } I currently have this working, and I can make some pretty cool "digital" sounding music. What I would like to be able to have these sounds be conventional instrument sounds (Bass, Drums, Guitar, Trumpet, Piano, etc). Is there a way to achieve this through ChucK, or do I need to use a software synth like fluid-synth? I also want to be able to code, execute, and modify this live. Is anyone else doing this? Thoughts? -Dan

2 1

file open semantics for clustered chuck
by Jim Hinds 28 Feb '06

28 Feb '06

Since an important usage mode for chuck is analogous to a server for multiple performers, I'd like to suggest that the file open semantics be extended. When a chuck script is submitted from a performers host to a remotely running chuck server, that script may open files, which must reside on the server file system, not the submitters host. This means that wave files, or other data must be first copied into the server, or otherwise exported. By simply extending the semantics for Chuck's "open" from expecting a file name, I suggest that it be a URL instead. If the filename starts with http:// or ftp:// or other legal prefix, give the URL to a curl library for access. For this to work, the performer's system need only have an httpd or ftpd or ssh deamon running locally to give the remote chuck access to those needed files. As a side effect, the files need only be present "somewhere" out there in cluster land. The URL will rule. Jim Hinds

2 1

string handling
by tim perkis 28 Feb '06

28 Feb '06

hi -- please excuse me if I've missed something discussed here previously, or missing something obvious in chuck at present... but I don't see support for any sort of basic string manipulation. -- is that the case? I understand this is reasonably a low priority in a language for processing sound! -- but it would be nice to have some way to compose strings, perhaps for use in loading/saving text parameter files, or computing strings to be passed to a SYSTEM call... something like an sprintf call? or javascript/python style concatenation operators? like 'There are ' + n_shreds + 'shreds running.' => str; Pardon me if I'm overlooking something already implemented in the language... I'm a newbie T

2 1

ChucK Inconsistencies...
by Mike McGonagle 27 Feb '06

27 Feb '06

This is a list of something that I find to be a little difficult when learning ChucK. Language inconsistencies - I am point these things out, more from a 'linguistic' point of view, not so much as 'bugs'. One syntax about ChucK that I like is that data can come before the function calls that use that data. It just seems to make reading the code much easier. While this can be good for some things, others do suffer. One of those "troubles" is: 0.0 => myFunc; 0.0 => myFloat; it is hard to tell which one of these is really a function call, and which one is an assignment statement, without knowing the full program. And when you start to deal with objects, this might get to be trouble. When using Ugen objects, this is also kind of confusing, as when you are retrieving a value from the object, you use last() => myFloat; but when setting it, you use: myFloat => next; Now onto the specifics... ************************* 1. not all function calls are created equal fun float myFunc0() { return 0.0; } fun float myFunc1(float x) { return 0.0; } fun float myFunc2(float x, float y) { return 0.0; } 0.0 => float x => float y => float z => float a; () => myFunc0; // does not compile, () is not valid in this context x => myFunc1; // valid (x) => myFunc1; // valid (x, y) => myFunc2; // valid ************************* 2. invalid cast to int from function x => myFunc1 $ int => y; // does not compile (x => myFunc1) $ int => y; // does compile ************************* 3. cannot perform '-' on object references... x => myFunc1 - z => a; // does not compile (x => myFunc1) - z => a; // does compile ************************* 4. Library inconsistencies There are many functions in the 'std' library that would fit better (IMHO) in the 'math' library. Is there a particular reason why these functions are in 'std' and not 'math'? Could this be changed (without breaking the world of ChucK)? Any objections? ************************* 5. doesn't work, but no compiler error null @=> Object v; (v == null) ? true : false => int val; <<< v, val >>>; (v == null) ? false : true => val; <<< v, val >>>; ************************* 6. Why would this compile, and not produce an error? What does ChucK do with it internally? Cause trouble? While this is a mistake, ChucKy eats it up like breakfast. I found this will testing something, and mistakenly entered 'public' instead of 'fun'. When I tried to use 'at()', ChucK said "undefined variable/member 'at' in class/namespace 'MyClass'..." 'at()' was defined outside of the class. public float at(time n) { return n / 1::ms; } ************************* 7. You can't use the "ChucK" form when sporking a shred... fun void doit(float s) { } (0.0) => spork ~ doit; // not valid spork ~ (0.0) => doit; // not valid spork ~ doit(0.0); ************************* While some of these are important, I don't expect everything to be addressed. Thanks again to everyone who is working on this, it is wonderful, dispite my "complaints"... Mike

6 6

pointing the ChucK Homepage to the new WIKI
by Mike McGonagle 26 Feb '06

26 Feb '06

Hello Ge, Thanks for all the hard work in getting the WIKI updated. I was noticing that on the home page for ChucK, it still points to the old one. Just thought it might be a good time to update that... Thanks again, Mike

3 4

New WIKI functional
by Adam Tindale 22 Feb '06

22 Feb '06

Hello All, Ge and I have been working for most of the day making the new WIKI functional. Please take a look and make some suggestions. We would love it if you would post some of your code or audio. Also, take a look at the old WIKI and see if we missed anything. We have moved some v1.1.x programs out of the way. If they are yours then maybe could upload your 1.2.x compatible versions. We would like to make the full switch in a day or two. With your help we should be able to do it. NEW http://wiki-new.cs.princeton.edu/index.php/ChucK OLD http://wiki.cs.princeton.edu/index.php/ChucK --art

1 0

Chucking scores
by Pedro Lopez-Cabanillas 21 Feb '06

21 Feb '06

Hi all, I've written a little article on the subject, that you can find here: http://www.telefonica.net/web/plcl/chuck/ There are also some merry melodies for ChucK. Hope you enjoy it. I would like to hear your opinion about everything, the music, the proposal, and the wording. Sorry for my poor English, BTW. Regards, Pedro

3 7

wiki upgrade and transfer
by Ge Wang 21 Feb '06

21 Feb '06

Hello again, Our ever-hardworking system staff has upgraded the wiki to a new version of mediawiki and also added more rigorous measures to prevent spammers from defacing the wiki. The upgraded wiki is temporarily at: http://wiki-new.cs.princeton.edu/ http://wiki-new.cs.princeton.edu/index.php/ChucK The existing wiki will remain at the current URL until we make the switch: http://wiki.cs.princeton.edu/ http://wiki.cs.princeton.edu/index.php/ChucK The new wiki requires one to be logged in before he/she can edit a page. Furthermore, the registration page now has a CAPTCHA feature to help prevent bots. I guess this would be a good time to start moving contents from the old wiki to the new and doing some housecleaning. 1. I think the <pre> tags now work, but it may be better to denote code by inserting spaces before each line, like in the page: http://wiki.cs.princeton.edu/index.php/FractalMelody 2. Some or maybe most of the page could use some organizing and updating. Perhaps the ChucK_Programs page can benefit from some basic categorization. 3.The upload feature seems to be enabled for now, though I am not sure if this will be permanet. I will find out. 4. We will switch over to the new wiki probably early next week. (just the URL change from wiki -> wiki-old, and from wiki-new -> wiki) 5. Use the talk page to avoid collisions on edit. The talk page is accessible via the 'discussion' link on the top. Ready? Everyone of course is invited to contribute. Adam T. and Mike M. might want to coordinate this? Best, Ge!

2 2

Re: [chuck-users] Joysticks anyone?
by Scot Gresham-Lancaster 20 Feb '06

20 Feb '06

While waiting for HID implementation on could use STEIM's JUNXION software which maps HID to MIDI. It works fine with a wide variety of input devices from my experience. http://www.steim.org/steim/products.html " junXion © is a software tool to process incoming data from USB devices (joysticks, touchscreens, mice) and MIDI devices using conditional processing and remapping. The outputted data can be routed to other MIDI controllable music and sound software or hardware." An HID interface inside of chuck would be great, of course ;-) Scot Gresham-Lancaster ¸,ø¤º°`°º¤ø¸,ø¤º°`°º¤ø http://o-art.org/Scot podcast: http://feeds.feedburner.com/blogspot/scotgl blog: http://scotgl.blogspot.com/ Quine in Br@!nF*ck ->++>+++>+>+>+++>>>>>>>>>>>>>>>>>>>>>>+>+>++>+++>++>>+++> +>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>+>+>>+++>>>>+++>>>+++>+>>>>>>>++>+++>+++>+>+++>+>>+++>>>++ +>+>++>+++> >>+>+>+>+>++>+++>+>+>>+++>>>>>>>+>+>>>+>+>++>+++>+++>+>>+++>+++>+>++ +>+>++>+++>+ +>>+>+>++>+++>+>+>>+++>>>+++>+>>>++>+++>+++>+>>+++>>>+++>+>+++>+>>++ +>>+++>>+[[> >+[>]+>+[<]<-]>>[>]<+<+++[<]<<+]>+[>>]+++>+[+[<++++++++++++++++>-]<++ ++++++++.<]

1 0

benchmarking chuck
by Graham Percival 20 Feb '06

20 Feb '06

Hi guys, I've discovered that I can only get 47 sine waves on my system (1 ghz G4 powerbook, 512 megs ram, OSX 10.3.9). I'm curious how other systems compare -- particularly on linux. If chuck works much better on linux, I may switch back to it... Here's the code. I ran it twice (in case there was any caching issue) and listened to the sound. With 48 waves, I could hear crackling; with 50 waves, it was unrecognizable. Cheers, - Graham 48=>int NUMSINS; sinosc s[NUMSINS]; for (0=>int i; i<s.cap();i++) { // s[i] => blackhole; s[i] => dac; 440 => s[i].freq; 0.01 => s[i].gain; } 5::second=>now;

8 12

Joysticks anyone?
by Jim Hinds 20 Feb '06

20 Feb '06

I was caught bragging to my peers (all of them) about how cool chuck is to do performance and real-time good stuff. One asked me about joystick interfaces into chuck and I blanked out. I didn't have an answer -- I should have. So, does anybody know how to read a joystick and get the info into (or through) chuck? Even a Rube Goldberg approach might help me here, although extra credit is given for simplicity and elegance. If the answer only worked on the Mac OS X implementation, that would be just fine. Jim

5 4

Re: chuck-users Digest, Vol 7, Issue 11
by Scot Gresham-Lancaster 17 Feb '06

17 Feb '06

This feels like a real simple problem, but I can not suss it out. In the chuck archive: > Julian Sorrel tacitdynamite at yahoo.com Wed Jan 25 17:05:25 EST > 2006 wrote: > > chuck D:\Chuck\examples\otf_06.ck > (using otf_06.ck here because it doesn't require external sound > files) > this works fine - I hear Chuck playing the file. When I try > chuck D:\Chuck\examples\otf_07.ck > the result is > [chuck](via sndbuf): cannot stat file 'data/snare.wav' ... > even though, again, that file can be found in "dir D:\Chuck > \examples\data" ... This was on an XP machine, but I am getting the same result on my mac and linux boxes. If I put in the full path these sndbuf objects function fine, but if I use a relative address such as "../data/ foo.wav" I get the "cannot stat file 'data/foo.wav' What is the obvious error that I am making? Also, stat? Is that supposed to be start? tocs_backwards Scot Gresham-Lancaster ¸,ø¤º°`°º¤ø¸,ø¤º°`°º¤ø http://o-art.org/Scot podcast: http://feeds.feedburner.com/blogspot/scotgl blog: http://scotgl.blogspot.com/ " Well, I let it play itself as much as I can, but if it doesn't, then I interfere. " David Tudor

3 2

comments, questions about chuck
by Charlls Quarra 17 Feb '06

17 Feb '06

Hi, I wanted to comment about things that i don't find yet on chuck which i would prioritize; please, take this freely as some brainstorming from a guy that has been using SuperCollider3 for some time and finds appealing the sample-accurate emphasis in Chuck. * ugen/plugin infrastructure; what headers you include? what classes you inherit? *block processing; i find amazing the feeling of putting your code directly into the sample stream, but i realize that it comes with a price; but before talking about block processing i wanted to ask first about; *** how much multithread-eable could be chuck; in other words, how possible is to implement shreds in a true multithreaded mode where each shred can run in a different core, but keeping the sample-synchronous approach? i imagine one could relax that to a "block-synchronous" multi-shreding. Currently one could have a chuck instance per core and pipe outs and in thru jack, but this would fix the block frame size to whatever jack is set to. * dynamic allocation of resources; of course, this could be implemented on top of the language; for example, creating a fixed number of audio buffers and calling .read as a score progresses a number of times in the same sndbuf object would (i imagine) free the previous allocated buffer and alloc for the new one. --------------------------------- 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo Abrí tu cuenta aquí

4 9

sndbuf.valueAtPos
by Charlls Quarra 14 Feb '06

14 Feb '06

Hi, I think a way to look ahead buffer values ahead could help solve a few issues, like avoid popping when a buffer jump is done; while (true) ... if (must_jump) { if ( std.fabs( buf.last() - buf.valueAtPos( toPos ) )< 0.01 ) { toPos => buf.pos; false => must_jump; } } ... 100::ms => now; --------------------------------- ¡Llamá a todo el mundo con las mejores tarifas! Comprá tus tarjetas de llamadas en tres simples pasos en Yahoo! Telefonía

2 1