- chuck-dev - lists.cs.princeton.edu

Re: [chuck-dev] chuck-dev Digest, Vol 27, Issue 2
by Perry R Cook 13 Feb '07

13 Feb '07

This is a bigger problem in ChucK, where things are supposed to "do the right thing on the fly" in real time. But as you point out, what's the right thing for a given UG? I suspect the answer is "it depends." In fact I'm almost certain about it. At any rate (no pun intended), Ge is busy this week preparing for his "pre-FPO" talk/exam, which is a cryptic Princeton term meaning pre Final Public Oral (sort of a thesis proposal/defense). This was instituted after a series of tragic incidents wherein a PhD student got all the way to their final thesis defense and was torpedoed in some profound way. So the rule is that if you don't come to the preFPO then you can't pipe up with any deep critiques at the FPO, which takes place about 6 months after and has now become mostly a formality. Here's the happy announcement: Ge Wang will present his preFPO on Friday February 16 at 2:00pm in Room 402. The members of his committee are: Perry Cook, advisor; Andrew Appel and Roger Dannenberg (Carnegie Mellon), readers; Paul Lansky and Brian Kernighan, non-readers. Everyone is invited to attend his talk. His abstract follows below. ------------------------------------- ChucK + Audicle: Strongly-timed, On-the-fly Audio Programming Language and Environment The computer has long been considered an extremely attractive tool for creating, manipulating, and analyzing sound. Its precision, possibilities for new timbres, and potential for fantastical automation make it a compelling platform for expression and experimentation - but only to the extent that we are able to express to the computer what to do, and how to do it. To this end, the programming language has served, perhaps, as the most general, and yet most precise and intimate interface between humans and computers. Furthermore, "domain-specific" languages can bring additional expressiveness, conciseness, and perhaps even different ways of thinking to the domain (e.g. sound synthesis). This thesis argues for the philosophy, design, and development of ChucK, a domain-specific programming language designed for computer music. The goal is to create a language that is "expressive" and "easy to write and read" with respect to time and parallelism, and to provide a platform for precise synthesis/analysis and rapid experimentation in computer audio. In particular, ChucK provides a syntax for representing information flow, a new time-based concurrent programming model that allows programmers to easily (and flexibly) control the flow of time (we call this "strongly-timed"), and facilities to develop programs "on-the-fly" - as they run. A ChucKian approach to "live coding" as a new musical performance paradigm is also described - and ultimately motivates the Audicle, a specialized graphical environment designed to facilitate on-the-fly programming, to visualize and monitor ChucK programs in real-time, and to provide a platform for building highly customizable user interfaces. Additionally, this presentation shall include a brief history of computer music and programming, and offer contrast between ChucK and other languages and environments. The various aspects of the ChucK language (with and without Audicle) are evaluated in the context of computer music research, performance, and pedagogy. As part of an extensive case study, the presentation discusses ChucK as a primary teaching and development tool in the Princeton Laptop Orchestra (PLOrk), which continues to be a wonderfully useful (and fun) platform to observe the effectiveness of ChucK for teaching topics ranging from programming to sound synthesis, and for crafting new instruments, compositions, and performances for a laptop ensemble. We also present additional applications, including classrooms, live coding "arenas", compositions and performances, user studies, and integrations of ChucK into other software systems, such as the sound design environment TAPESTREA.

4 7

RK4 - ODE
by David Michael 12 Dec '06

12 Dec '06

Hello I am interested in writing a Runge-Kutta ugen for numerical integration. A few questions before I dive in... 1) Has someone out there already written one? 2) Will the performance of this Ugen be good enough to even attempt this? (ChucK is quite slow at runtime) 3) Is a ugen the proper place to do this processing - perhaps I need to write another sort of object? My thought is that a class using this ugen would be advancing something like 1::sample => now, and the output of the ugen could sent to the dac... The ugen would need accept arrays and output arrays... is this possible? And what about the function it will need to perform the operation on? Can this be fed into a ugen? Thoughts on how this would be possible? Thanks in advance, David

1 0

stereo ugens?
by Imre Kéri 29 Nov '06

29 Nov '06

Hi chuck-dev, Is there a way to code stereo (or multi-channel) ugens in the chuck source? I want to write an own ugen and already found out how to do it, but I can't get the stereo output working. How should I write an ugen which has 0 inputs and 2 output channels? Or is the stereo feature not ready yet and I better stick to mono? Imre

1 0

embedding chuck
by Graham Coleman 02 Nov '06

02 Nov '06

Chuck-devs, While working on a chuck embedding project of my own, a had a bit of an idea in relation to future chuck projects. To fit chuck into my target application, I had to define an interface and make a few minor changes to get things to work properly. In all cases so far, I just call the main method with arguments depending on if I want it to start looping, or send an OTF command. Besides the application specific stuff, here are the changes I've made: 1. When calling {"chuck" "--loop"}, you must create a new thread. 2. Replaced a few "exit" calls after OTF commands (on success and failure) with returns. "exit"ing from a library is not a good idea. In addition, I've got some design yet to do, as well as figure out how to set variables, etc. Anyway, I'm not the only one doing an embedding. Brad and Martin have ported chuck to Max/MSP and pd respectively. I imagine chuck will be an attractive option for adding interactive procedural music to games and other applications in the future. Perhaps we should create and extend a standard chuck library interface, so the behavior of the library will become more well understood and the cost of the embedding will be easier, as well as stay current with the source tree. Graham

2 1

CVS?
by Burton Samograd 21 Oct '06

21 Oct '06

Is the ChucK source available from CVS or any other version control system? I'd like to do a bit of hacking and I prefer to use the VC versions for that. TIA. -- burton samograd kruhft(a)gmail.com kruhft.boldlygoingnowhere.org www.myspace.com/kruhft

2 2

Hard & soft clipping patch
by Jukka Akkanen 18 Oct '06

18 Oct '06

I posted a patch implementing hard and soft clipping UGens at http:// wiki.cs.princeton.edu/index.php/ChucK/Patches/Clip. These can be used to introduce non-linear behavior, for example, to create effects similar to overdriving an amplifier. -Jukka

7 11

chuck/miniAudicle, intel mac
by Mark Hereld 17 Oct '06

17 Oct '06

didn't see any responses so i thought i'd tell you my experience. which program: miniAudicle-0.1.3.6 did it run at all? YES was there real-tiem audio? DON'T THINK SO where'd exec originate? download from site LED example showed little window with four colored LEDs, but nothing seemed to change. Everything else that I tried seemed to case miniAudicle to bail outright. -- Mark > Hi! > > We've been getting reports of audio not working in the miniAudicle on > intel macs, using the universal binary. The folks that have been > building chuck from source on intel macs seems to have been > successful in getting audio. Has anyone had any success/problems > with the chuck universal binary on intel mac? > > None of us here actual have an intel mac to test with, so we have > been relying on external reports. If you have an intel mac and have > tried to run/compile chuck/miniAudicle on it, can you post what > worked/failed? In particular, we are interested in: > > --- > which program was tried? (chuck, miniAudicle, or both) > did it run at all? (yes/no) > was there real-time audio? (yes/non) > where did the executable originate? (download from site/built from > source) > any other issues on intel mac? > > If you get a chance, please let us know. Thank you very much! > > Best, > Ge!

3 3

UGen for dynamics processing: dyna
by Graham Coleman 09 Sep '06

09 Sep '06

Chuck enthusiasts, * introduction Ever since encountering Zolzer's DAFX (great implementation-level guide on music-dsp... along with Roads Computer Music Tutorial), I'd been wanting to implement some of the basics for my own edification. >From time to time chucking, I don't leave enough volume headroom (too loud) on the dac, so sometimes, especially when playing a drum sample with sndbuf, the sound will clip at the dac on my soundcard and make an upleasant crunchy noise. This inspired me to write a Limiter. * background Dynamics Processors are objects that monitor the signal level of a sound, and adjust a gain factor to accomplish some musical goal: - Compressor- reduces the dynamic range of events above a threshold so that they are more uniform in volume. By applying gain afterwards, this results in a louder signal overall. Used frequently in music production to produce steadier parts and louder masters. - Limiter- keeps the signal level under some threshold by applying inverse gain. - Noise gate- zeros the signal when it is under some threshold to get rid of bare audible noise. - Expander- increases the overall dynamic range by making events under a threshold quieter by a factor. Used in some cases with a Compressor to preserve the dynamic range of a signal being transmitted. for more information, see RaneNote on Dynamic Processors: http://www.rane.com/note155.html at * you are the prototype I began by drafting the processing code in ChucK. It was nice to be able to prototype in a higher-level language. Once things seem to work, I was able to figure how to turn it into a native chuck object (for performance and vanity's sake). You can use "dyna-limit-chuck.ck" to test the chuck version "limiter.ck". * implementation Since the processors differ only by the gain transfer function, I was able to implement them all with the limiter algorithm, by changing a few constants- the threshold, whether the processor acts above or below the threshold, and the slope/ratio. First, I copied the skeleton from ugen_xxx.{h,cpp} to use as a model. Then I began by creating a data object to hold the state of the processor. Next I was able to implement a tick function by translating the chuck code, and implement controls (chuck methods) for the parameters. Finally, I was able to start testing it and write samples! (Using the same basic design, one should be able to make a processor that does all of these things at once by making a compound transfer function with thresholds for each mode: http://www.rane.com/note1556.html I will leave that work until "dynb".) Though there is a peak-level CPU usage difference between the native version and the chuck version, it's not as big as I thought. * chuck samples So that you can play and get an idea of the sound of each of the effects, I've included sample code for each of the modes. Each sample plays a bit of music: first with dyna bypassed (op=-1), then with the processing on. (dyna-limit.ck, dyna-gate.ck, dyna-compress.ck, dyna-expand.ck) Warning: dyna-limit.ck can be loud and will clip at your dac, so turn down the main volume of your soundcard. * documentation I have included some suggested documentation in dyna.tex. * how to install Add "ugen_gkc.h" and "ugen_gkc.cpp" to your chuck sources, and to the build process. You'll also have to add the following to chuck_compile.cpp: towards the top of the file: #include "ugen_gkc.h" towards the middle of load_internal_modules(): //load gkc! EM_log( CK_LOG_SEVERE, "module GKC..." ); load_module( env, gkc_query, "gkc", "global" ); * conclusion I hope this is fun, and I hope this is useful. Let it never be said that "the chuck stops here." Graham

1 0

what are PMSG functions for?
by Graham Coleman 09 Sep '06

09 Sep '06

Chuck devs, what are PMSG functions for, as part of the class import process? Most of the PMSG functions that I see (in ugen_stk.cpp, ugen_xxx.cpp) just return TRUE; Graham

2 3

Improve Makefile for Gentoo ebuild
by Cedric Krier 21 Aug '06

21 Aug '06

Hi, I'm working to provide a ebuild of chuck and other tools from sound lab for Gentoo: http://gentoo-sunrise.org/svn/reviewed/media-sound/chuck/ I have made a patch for the linux makefiles here : http://gentoo-sunrise.org/svn/reviewed/media-sound/chuck/files/chuck-1.2.0.… It just allowed to specify the CC, CXX and CFLAGS with the command line. It will be great if it will be integrated in the source because I need to rewrite the patch for each version. Thanks Cédric Krier

5 10