Hi Ge, I'm liking ChucK a lot thus far! These are FAQy kind of questions. You've probably seen them before. 1. There are a number of instruments described in the docs that I would like to play with, but that don't appear to be implemented yet (at least, not in the windows version). These include ModalBar, Sitar & StifKarp. Is there a definitive 'working' instrument list somewhere? Are the remainer going to be added any time soon? 3. I'm doing a lot of fancy-schmancy algorithmic score generation these days (using Python and/or KeyKit). Arrays are very helpful for accomplishing this (for scoring lists of phrases, chords, etc.). For example, I've implemented a version of Terry Riley's "In C" in KeyKit. I think it would make a nice demo to implement a single player of "In C" in ChucK (this player could then be run multiple times as different shreds, to create an ensemble). However, it's really helpful to be able to store the 53 seed phrases in arrays. A search of the examples shows no square brackets. From this can I assume there are no arrays? Are arrays coming? If not, is there a paradigmic ChucKish way of accomplishing this? - Jim Bumgardner
Hi Jim! Welcome to the list!
They are in not the current release, but have since been ported! (Thanks much to Phil Davidson) We are actually putting a release together today that includes these new instruments from STK: BandedWG Blowhole BlowBotl Bowed Brass Clarinet Flute ModalBar Saxofony Sitar StifKarp
You are correct, currently there are no arrays ChucK. But there most definitely will be. We are currently implementing arrays, as well as objects and synchronous and asynchronous events. These are going be in the next major release later this month. Welcome, once again! Happy ChucKing! Best, Ge!
Hi Everyone, My name is Adam Tindale and I am chucK user. I was wondering if maybe we could start a short discussion on a wishlist for chucK. Maybe some public comments, etc.
In response to this, I was hoping that there might be a line object included sometime. Something that could be easily used for break point functions with different interpolation between points as options. I can't wait for synchronous and asynchronous events. I was going to ask about this. Does anyone have any experience using midi in chucK? No offence Ge, but I would like to see a more comprehensive example involving control change messages and the use of different channels. My midi controller is broken so I can't experiment right now :( I love distortion and would love to see a simple (or complex) waveshaping distortion object. This may not be necessary once arrays are implemented. Also, math. I recently had a problem (a user problem, not a chucK problem) with casting types, blah blah blah. Are C expressions good in chucK? Did I miss that in the documentation? I look forward to seeing if this thread goes anywhere. happY chucKing a
Adam ,
My name is Adam Tindale and I am chucK user.
Welcome to the group Adam. The first step in recovery is admitting that you have a problem We do have a bug/feature request line on our sourceforge page, ( http://chuck.sf.net ) this forum's also good for requests.
I made some very basic runs at this, but it's about as illuminating as parsing out raw midi from ints can be. MIDI's very minimal now, we'll have richer functionality ( and examples ) once objects/events are on the scene.
The STK Envelope or ASDR classes are about as far as we go for breakpoints. Those only support linear interpolation. Envelope is not so pretty to code at the moment, but with arrays/objects we'll have wider range of options ( more like vline of pd or max/msp ) sinosc s => Envelope e => dac 0.10::second => e.time; 1.0 => e.target; 0.10::second => now; 0.5::second => e.time; 0.2 => e.target; 0.5::second=> now; ...etc..
I can't wait for synchronous and asynchronous events. I was going to ask about this
This would be cool. At the moment, the oscillator classes can be driven by audio-rate control value (check out sixty.ck ) . but that's not quite what you're looking for. Again, objects/arrays would simplify this In the meantime, you could drive a loop at sample rate and use the ugen.last function to DIY
(float) intval => ugen.floatfunction; (int) floatval => ugen.intfunction;
Hi All!
I was wondering if maybe we could start a short discussion on a wishlist for chucK. Maybe some public comments, etc.
Good idea. Here is what we have so far... ChucK wish list next major release: in progress --- arrays objects events proper casting global value map shred-local adc/dac cross-chucking multiple arguments to ugens stereo/multi-channel (and a few minor releases later) --- OSC MIDI (done less horrendously) network better sndbuf (many) input devices (potential) parallel efforts --- GLucK (OpenGL for ChucK) this is almost ready for release Phil have been working on this. TrucK: ChucK to C/C++ translator (for embedded platforms, and for non-on-the-fly native compilation) Paul Botelho and I talked about this last night. (I just now made up the name) MucK: okay, this is going further into la-la land. MATLAB / ChucK extension. Diemo Schwarz and I had once envisioned this renegade concept of doing analysis in MATLAB and (somehow) using ChucK from within MATLAB to quickly (and concurrently) playback/synthesize/audisize on-the-spot. I wonder if anyone still wishes for this. SucK: we need a really bad idea to go with this. And of course, the Audicle. http://audicle.cs.princeton.edu/ --- post ideas and comments here. you can also add requests at http://chuck.sf.net ThanK you! Best, Ge!
Can you embed musical notation in Chuck source code?
What the Chuck: a debugging mode where Chuck dumps pretty much
everything it's doing into a report. Show all the ugens along with
their parameters and their waveforms. Show all the points where I've
advanced the clock. Dump it to HTML and PostScript. I'm a newbie and
I make lots and lots of mistakes, so my programs produce either
obstinate silence or hideous screeching. I like how in sound
programming if you screw up you can completely shred your ears.
Eh, random programming stuff: switch statements, exceptions, modules
and imports. Oh, and since you're adding arrays, can you add a
dictionary class?
I tried to write a function that took any ugen as a parameter, but
ugen is not a type so I had to write the function for a specific ugen.
I would like to write generic functions that took any ugen as a
parameter.
Russell
On Tue, 21 Sep 2004 23:39:17 -0400, Ge Wang
I would like to second this motion. I think this is a great idea. About the multiple input. I am really into this idea. In the initial pictures of chucK it showed Ge with a whole lot of mice! Could you explain what you did to get that data into chucK? It was a very cool looking setup! Happy ChucKing adam
Your curiosity, for some reason, reminds me of a classic passage from The X-Files (the very first episode). --- DEEP THROAT: Your lives may be in danger. MULDER: Why? DEEP THROAT: Mmm, you've seen things that weren't to be seen. Care and discretion, are now imperative. MULDER: I saw something I... DEEP THROAT: As I said, I can provide you with information, but only so long as it's in my best interest to do so. MULDER: What is your interest? DEEP THROAT: The truth. MULDER: I did see something, but it's gone, they took it from me, they erased it. You have to tell me what it was. DEEP THROAT: A military UFO? Mr. Mulder, why are those like yourself, who believe in the existence of extraterrestrial life on this earth, not dissuaded by all the evidence to the contrary? MULDER: Because, all the evidence to the contrary, is not entirely dissuasive. DEEP THROAT: Precisely. MULDER: They're here, aren't they? DEEP THROAT: Mr. Mulder, they've been here for a long long time. --- So, in the interest of truth... The mice congregation was a vision at the time of this picture (2003): http://soundlab.cs.princeton.edu/images/chuck_session_01c.jpg It _still_ is a vision because we still haven't implemented that ability to do that. We meant to, but didn't. It was originally going to go into the mysterious chuck_bbq, which was to be a cross-platform library for input devices, network connectivity, and audio interfacing. But the latter two found their way into ChucK via others means, and chuck_bbq became just a point of interface for RtAudio below. Other features gained priority over low-latency input devices, giving focus to building up the core language/synthesis. Additionally, we decided to wait until events to do input devices correctly. What this all adds up to, Mr. Mulder, is that mice input is not in ChucK, and in fact, has never been in ChucK. (But it will be)
It was a very cool looking setup!
It sure was. Best, Ge!
Whoa. You have just (more or less) described the ideal Audicle. You are totally right, this would be very cool.
switch statements - good idea. (break, continue, switch coming soon) exceptions - this is going to be in 2 major releases or so? modules/imports - already in ChucK but completely undocumented. ugen_* and ulib_* are examples of modules. They can be compiled into .ckx files and dynamically linked. Right now, they are statically linked. All it takes is different compiler flags (-bundle on OS X) and a expression ( "foo.ckx" => (:foo:); ) to load them at runtime. We will post documentation about this soon. If you are interested in doing this in the meantime, please let us know. dictionary - sure - probably as an associative array (foo["bar"])?
Objects in ChucK should properly address this issue.
Can you embed musical notation in Chuck source code?
If you mean as part of the syntax, then not really. We will be soon to able to create, (with the aid of objects and the timing mechanism) create notation constructs that are appropriate (and hopefully easy to manipulate) for the tasks at hand. Inductive durations would be helpful, especially if we can formalize them in a dynamic way (as discussed a few posts previous). However, since musical notation can vary greatly depending on the music/sound, it seems that it's better left to user-defined routines, objects, and semantics. (ChucK will do it's best to make the underlying timing/concurrency easy to access and manipulate). What do you think? These are really good suggestions - let's keep going. Best, Ge!
On Wed, Sep 22, 2004 at 05:06:04PM -0400, Ge Wang wrote:
expression ( "foo.ckx" => (:foo:); ) to load them at runtime. We dictionary - sure - probably as an associative array (foo["bar"])?
yeahh yeahh careful with "foo" statements. "foo" has a meaning now, as you might remember from the banff desert table :-) happy chucking and best wishes martin
I have not forgotten "foo", nor the banff dessert. Good to hear from you, Martin. For those not yet acquainted - foo, in addition to being our most celebrated default variable name and friend of "bar", it is also a synthesis language developed in 1993 at ZKM. Martin has since revived the project: http://foo.sf.net/ Foo is a scheme-based synthesis tool. Like ChucK, there is a strong focus on temporal representation and control. And if ChucK intends to be real-time/on-the-fly, then Foo is the antithesis: it draws its power from being not real-time, in which case there are more freedom (like non-causality) available in the context of the temporal structuring. Perhaps ChucK can learn much from this: if one is not always interested in real-time, then one can use the ChucK timing mechanism to also move BACKWARD in time, operating over samples already computed. Of course, that would require additions to the semantics, but wouldn't it be cool? Best, Ge!
These are really good suggestions - let's keep going.
is the protocol used by the VM sockets documented and intented to provide an entry-point API, so that we can drive a performance by local TCP/IP ? if not what would be good to have IMHO Stef
On Sep 23, 2004, at 4:31 AM, Stéphane Rollandin wrote:
This _is_ a good thing to have! The VM sockets are not visible yet from within the language. Soon, there will be a net module (like std, math, machine) with TCP, UDP over IP. Also, OSC support is due out around the same time. Driving a potentially collaborative performance with this could be powerful (things can blow up even faster). We are looking forward to it. Best, Ge!
participants (7)
-
Adam Tindale -
Ge Wang -
Jim Bumgardner -
martin rumori -
Philip Davidson -
Russell Cagle -
Stéphane Rollandin