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

optimization
by jochen.hartmann 17 Sep '06

17 Sep '06

hi, i am running mini-audicle to write my chuck code on a mac ... i love this stuff i began writing more complex code where a lot of geometry is figured out to generate dynamically morphing sounds and now things are getting pretty slow. mini-audicle tends to eat up 90% of my cpu so once i have about 10 shreds moving at once, i can't do anything but force-quit to stop things... now most of this probably has to do with my code not being very optimized. so i was wondering: a. are there ways to give more memory to the chuck vm ? b. is it faster to run shreds from the command line (i would imagine so...) ? c. are there any other tips/tricks to help me optimize my code (maybe something to figure out where the bottlenecks are...) ? thanks! best - jochen HSDOM SOUND http://hsdom.com RECORDS http://phaserprone.com Brooklyn, NY

2 1

adsr envelopes
by babiakb＠bellsouth.net 14 Sep '06

14 Sep '06

i was wondering how to use the stk adsr. the best way i found was the following: sinosc wave => ADSR env => dac; wave.freq(440); env.attackTime(0.3 => float a); env.decayTime(0.2 => float d); env.sustainLevel(0.2 => float s); env.releaseTime(0.3 => float r); a + d => float ontim; 1 => env.keyOn; ontim::second => now; 1 => env.keyOff; r::second => now; is this what you all do? how do you run adsr, is there an easier way?

1 0

Re: [chuck-users] Reading materials.
by babiakb＠bellsouth.net 13 Sep '06

13 Sep '06

people might disagree with me, but i don't think most of what you said will help you. for example, the csound book would help on all the above areas in depth, but i don't think you chuck music would be better. i think roads computer music tutorial is the only thing anyone needs to start in computer music. it's a great book. also, chuck is not really the most musical tool in it's current incarnation. it's a lot like csound or supercollider. it;s more for experimental synthesis, understanding sound, etc. if you are just trying to make good new electronic music of any genre, ableton is the simplest path from brain to speaker, whether glitch, electro, classical, indie pop, trance, you name it. the stars of music either use cubase/ableton/protools, or hardware. mostly hardware. for example, everyone says autechre uses maxmsp, but they don't on envane and the previous album, they use max to control their hardware, and the max interface was self-designed. albeton now does the same thing right out of the box. chuck for me is like supercollider, to make experimental sounds, learn about sound synthesis and algorithmic music. all these topics are covered beautifully in roads' book. to just make a good tune, grab a damn guitar. you don't chuck sine oscillators to dacs and then construct an lpf out of biquads to make music easily ;) all that would be like two clicks in fl studio or ableton, and sound the damn same. you do this to hold sound in your hands and learn. probably going to get flamed for this pov, but that's my 2c. > > From: Vassili Slessarenko <urbanmuzak(a)urbanplexus.net> > Date: 2006/09/12 Tue AM 07:48:42 EDT > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Subject: [chuck-users] Reading materials. > > Hey you all, > > Just a question I have meant to ask for a long time. I'm looking for > good literature (be it e-book or paperback) on Audio DSP, Algorithmic > Composition, and perhaps Object Oriented programming. Not being a CS > student I am just trying to get into the whole world of > Chuck/PD/Reaktor, I do have basic programming skills, but largely feel > they are not enough, especially without the understanding of how audio > signals work. > > I have found one book very useful. It is by Miller Puckette - "Theory > and Techniques of Electronic Music". It is quite heavy reading though > and not much is sinking in I find.... > > I am particularly interested in how-to use programming techniques to > transform algorithms into sound and a reference on what are the basic > building blocks of common audio effects or how to create them. For > example right now I am trying to replicate a hardware delay I own into a > software model so that I can extend the delay time beyond that of the > hardware one (for some crazy looping fun), but also I want to set up all > sorts of EQ filters on both input and output of the signal and can't > quite get my head around doing it in Reaktor even. > > So this question is mostly for Perry and Ge I guess as they are teaching > chuck and such to uni students, but I welcome any responses :) > > Could someone just give me a list of essential readings (and maybe some > of the extended, just in case I want to see things in more detail) to be > able to work with ChucK/PD/Reaktor? > > Thanks a lot in advance, > > Vassili. > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

5 5

Re: [chuck-users] heads up for 1.2.0.7
by Ollie Glass 12 Sep '06

12 Sep '06

I think the CamelCase is great, it brings ChucK syntax a little closer to Java which suits me :-) I've found deprecations very useful in Java to smooth transitions between versions, glad they're being used in ChucK. Would love to see VST input and output, audio and midi. Ollie

5 5

Re: [chuck-users] Reading materials.
by babiakb＠bellsouth.net 12 Sep '06

12 Sep '06

and you could always kill someone with it if you had to . . . :) > > From: Kassen <signal.automatique(a)gmail.com> > Date: 2006/09/12 Tue PM 06:49:34 EDT > To: "ChucK Users Mailing List" <chuck-users(a)lists.cs.princeton.edu> > Subject: Re: [chuck-users] Reading materials. > > On 9/13/06, Vassili Slessarenko <urbanmuzak(a)urbanplexus.net> wrote: > > > > > > and finally thanks a lot to everyone who has made a recommendation... > > btw, what would be the absolute essential one of these readings if you > > had to choose? > > > > For a all-round bird's eye perspective you can't go wrong with Roads. It's > not cheap but it'll be with you for years to come every time you're unsure > of a word. > > > > Kas. > >

2 1

Reading materials.
by Vassili Slessarenko 12 Sep '06

12 Sep '06

Hey you all, Just a question I have meant to ask for a long time. I'm looking for good literature (be it e-book or paperback) on Audio DSP, Algorithmic Composition, and perhaps Object Oriented programming. Not being a CS student I am just trying to get into the whole world of Chuck/PD/Reaktor, I do have basic programming skills, but largely feel they are not enough, especially without the understanding of how audio signals work. I have found one book very useful. It is by Miller Puckette - "Theory and Techniques of Electronic Music". It is quite heavy reading though and not much is sinking in I find.... I am particularly interested in how-to use programming techniques to transform algorithms into sound and a reference on what are the basic building blocks of common audio effects or how to create them. For example right now I am trying to replicate a hardware delay I own into a software model so that I can extend the delay time beyond that of the hardware one (for some crazy looping fun), but also I want to set up all sorts of EQ filters on both input and output of the signal and can't quite get my head around doing it in Reaktor even. So this question is mostly for Perry and Ge I guess as they are teaching chuck and such to uni students, but I welcome any responses :) Could someone just give me a list of essential readings (and maybe some of the extended, just in case I want to see things in more detail) to be able to work with ChucK/PD/Reaktor? Thanks a lot in advance, Vassili.

3 2

I don't get the hint (more static stuff)
by Kassen 11 Sep '06

11 Sep '06

Hi list, I wanted to have a static array of strings within a public class. This turns out not to be allowed yet but there is hope; instead of a plain error I got a hint; "cannot declare static non-primitive ojects (yet) (hint; declare as ref (@) and initialise outside for now)" This I don't get. What am I going to reference to what and where do I declare it? Maybe I'm missing something. My reasoning was that I clearly needed something more primitive then a array so a int seemed like a good sort of thing I then declared the trouble maker (the array) outside of the class and tried asign the array to the int. At this ChucK protests (like a thought it should) because arrays and ints are different sorts of things. Now I'm lost. What does this hint mean? Aparently no static strings are allowed at all (and I can't realy see why those are less primitive then ints)? Could somebody get me un-stuck? Thanks, Kas.

2 2

Re: [chuck-users] heads up for 1.2.0.7
by q.h.r.h. 11 Sep '06

11 Sep '06

Sweet, I'm excited for the new filters. -Quinton

1 0

Re: [chuck-users] heads up for 1.2.0.7
by babiakb＠bellsouth.net 10 Sep '06

10 Sep '06

I am really excited to see some new filters in ChucK. I think the new version sounds promising and hope to try it out soon! Graham, your links are great! thanks for sharing the ugens. i didn't know ChucKdev had this sort of thing. i need to look that over too. Brian > > From: Graham Coleman <gc(a)gehennom.net> > Date: 2006/09/10 Sun PM 05:05:30 EDT > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Subject: Re: [chuck-users] heads up for 1.2.0.7 > > Hi David, > > On Sat, 9 Sep 2006, David Powers wrote: > > > If I was going to request three additional "bread and butter" UGen's, > > I'd ask for > > 1. Compressor > > 2. Limiter > > 3. TubeOverdrive (ie. analog simulation) > > I just built a combination compressor/limiter/gate/expander for chuck > and posted it to chuck-dev, along with instructions for installing it. > > https://lists.cs.princeton.edu/pipermail/chuck-dev/2006-September/000182.ht… > > If you have time, please try it out and see if it works for you! > > > I'd also love to see a port of the destroyFX stuff, I think their > > source code is available: > > http://destroyfx.smartelectronix.com/ > > It seems like a cool way to do this would be implementing VST support. > Then chuck could talk to lots of plugins. > > Not sure how difficult it us, but the "standardness" of it might make > it worth it. > > cheers, > > Graham > > > On 9/9/06, Ge Wang <gewang(a)cs.princeton.edu> wrote: > > > Greetings fellow ChucKists, > > > > > > Here is a (not so) quick summary/warning about upcoming changes in > > > chuck-1.2.0.7, to be released probably next week. > > > > > > what it don't got: > > > - garbage collection is still on a holding pattern and will not be in > > > 1.2.0.7 > > > - the long-overdue string operations, unfortunately, insist on waiting > > > for garbage collection, and also will not in 1.2.0.7 > > > - file i/o api's have been implemented (thanks to Martin Robinson), > > > will be included soon but not in 1.2.0.7 > > > Sorry about that. > > > > > > Now that we've apologized about what's not in the release, it's time to > > > apologize about what is. Due to recent discussions on this list, two > > > sets of changes and additions have been made. We want to preview them > > > here to get feedback before setting them in concrete. > > > > > > API deprecations. Our discussion more or less determined that it's > > > best to unify the naming scheming now before things get further out of > > > hand, particularly for UGen names and such. So the current solution > > > deprecates the object names in question and provides more consistent > > > naming. By default, when a deprecated name, such as 'sinosc', is > > > encountered, a warning will be issued, such as 'line(1): deprecated: > > > 'sinosc' --> use: 'SinOsc''. The behavior should be otherwise > > > unchanged. In other words the program should still work as before. > > > We've also added a --deprecate flag that allows you to stop, warn, or > > > ignore upon encountering a deprecated item. The default is 'warn'. > > > > > > Here are the objects deprecated so far, and their replacements: > > > > > > - (api) deprecated --> new classes > > > -------------------------- > > > sinosc --> SinOsc > > > triosc --> TriOsc > > > sqrosc --> SqrOsc > > > sawosc --> SawOsc > > > pulseosc --> PulseOsc > > > phasor --> Phasor > > > osc --> Osc > > > noise --> Noise > > > cnoise --> CNoise > > > impulse --> Impulse > > > step --> Step > > > halfrect --> HalfRect > > > fullrect --> FullRect > > > gain --> Gain > > > zerox --> ZeroX > > > delayp --> DelayP > > > sndbuf --> SndBuf > > > pan2 --> Pan2 > > > mix2 --> Mix2 > > > onepole --> OnePole > > > onezero --> OneZero > > > polezero --> PoleZero > > > twopole --> TwoPole > > > twozero --> TwoZero > > > biquad --> BiQuad > > > > > > std --> Std > > > math --> Math > > > machine --> Machine > > > > > > A few more UGen's. From another discussion on list, also by popular > > > demand, it seems convenient to have out-of-the-box filters, in addition > > > to general 1st and 2nd order filters (OnePole/Zero, BiQuad, etc.). > > > We've examined and plundered from Csound, SC, and PD source code, and > > > chuckified a few UGen's. We are going to do this in installments, > > > adding various UGens every release. In 1.2.0.7, They include: > > > > > > LPF : lowpass filter (2nd order butterworth) (also with > > > cutoff resonance control) > > > HPF : highpass filter (2nd order butterworth) (also with > > > cutoff resonance control) > > > BPF : bandpass filter (2nd order butterworth) > > > BRF : bandreject filter (2nd order butterworth) > > > ResonZ : resonant filter (BiQuad with equal-gain zeros) > > > FilterBasic : base class to above filters > > > > > > Of course, all of these can be designed and implemented using existing > > > filters, but these provide direct access to cutoff and Q out-of-the-box > > > and behave in a familiar um Butterworthy way. (More are on the way) > > > > > > We'd appreciate your feedback on these. For example: > > > 1. api changes are in general, not reasons for group celebration. what > > > can be done to further smooth the transition? > > > 2. new naming optimal? > > > 3. anything else > > > > > > Thanks! > > > > > > Best, > > > chuck team > > > > > > _______________________________________________ > > > chuck-users mailing list > > > chuck-users(a)lists.cs.princeton.edu > > > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > > > > _______________________________________________ > > chuck-users mailing list > > chuck-users(a)lists.cs.princeton.edu > > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

1 0

Re: [chuck-users] heads up for 1.2.0.7
by mrcarp＠comcast.net 09 Sep '06

09 Sep '06

One thing that comes to mind regarding to the new API naming is that it'd be faster to type the deprecated names rather than their new names. I also like how the all lower-case names look in the code. Matt -------------- Original message ---------------------- From: Ge Wang <gewang(a)CS.Princeton.EDU> > Greetings fellow ChucKists, > > Here is a (not so) quick summary/warning about upcoming changes in > chuck-1.2.0.7, to be released probably next week. > > what it don't got: > - garbage collection is still on a holding pattern and will not be in > 1.2.0.7 > - the long-overdue string operations, unfortunately, insist on waiting > for garbage collection, and also will not in 1.2.0.7 > - file i/o api's have been implemented (thanks to Martin Robinson), > will be included soon but not in 1.2.0.7 > Sorry about that. > > Now that we've apologized about what's not in the release, it's time to > apologize about what is. Due to recent discussions on this list, two > sets of changes and additions have been made. We want to preview them > here to get feedback before setting them in concrete. > > API deprecations. Our discussion more or less determined that it's > best to unify the naming scheming now before things get further out of > hand, particularly for UGen names and such. So the current solution > deprecates the object names in question and provides more consistent > naming. By default, when a deprecated name, such as 'sinosc', is > encountered, a warning will be issued, such as 'line(1): deprecated: > 'sinosc' --> use: 'SinOsc''. The behavior should be otherwise > unchanged. In other words the program should still work as before. > We've also added a --deprecate flag that allows you to stop, warn, or > ignore upon encountering a deprecated item. The default is 'warn'. > > Here are the objects deprecated so far, and their replacements: > > - (api) deprecated --> new classes > -------------------------- > sinosc --> SinOsc > triosc --> TriOsc > sqrosc --> SqrOsc > sawosc --> SawOsc > pulseosc --> PulseOsc > phasor --> Phasor > osc --> Osc > noise --> Noise > cnoise --> CNoise > impulse --> Impulse > step --> Step > halfrect --> HalfRect > fullrect --> FullRect > gain --> Gain > zerox --> ZeroX > delayp --> DelayP > sndbuf --> SndBuf > pan2 --> Pan2 > mix2 --> Mix2 > onepole --> OnePole > onezero --> OneZero > polezero --> PoleZero > twopole --> TwoPole > twozero --> TwoZero > biquad --> BiQuad > > std --> Std > math --> Math > machine --> Machine > > A few more UGen's. From another discussion on list, also by popular > demand, it seems convenient to have out-of-the-box filters, in addition > to general 1st and 2nd order filters (OnePole/Zero, BiQuad, etc.). > We've examined and plundered from Csound, SC, and PD source code, and > chuckified a few UGen's. We are going to do this in installments, > adding various UGens every release. In 1.2.0.7, They include: > > LPF : lowpass filter (2nd order butterworth) (also with > cutoff resonance control) > HPF : highpass filter (2nd order butterworth) (also with > cutoff resonance control) > BPF : bandpass filter (2nd order butterworth) > BRF : bandreject filter (2nd order butterworth) > ResonZ : resonant filter (BiQuad with equal-gain zeros) > FilterBasic : base class to above filters > > Of course, all of these can be designed and implemented using existing > filters, but these provide direct access to cutoff and Q out-of-the-box > and behave in a familiar um Butterworthy way. (More are on the way) > > We'd appreciate your feedback on these. For example: > 1. api changes are in general, not reasons for group celebration. what > can be done to further smooth the transition? > 2. new naming optimal? > 3. anything else > > Thanks! > > Best, > chuck team > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

1 0