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

global UGen effects processing
by Graham Coleman 24 Sep '06

24 Sep '06

Chuck architects, In some cases, you may wish to filter sounds originating in several shreds. For example, dynamics processing, or just to provide a dramatic effect. I attempted to do this using a global HPF defined as a static variable, but it doesn't quite work the way it seems it should. I also figured out how to make it work as expected. The class in superfilt.ck: public class SuperFilt { static HPF @ highPass; } new HPF @=> SuperFilt.highPass; //instantiate SuperFilt.highPass => dac; //connect to dac The test class, superfilt-test.ck: StifKarp inst => SuperFilt.highPass; //connect to filter SuperFilt.highPass.gain( 0.4 ); SuperFilt.highPass.freq( 1000 ); while ( true ) { std.mtof(std.rand2(10,70))=>inst.freq; //random note inst.noteOn( 0.5 ); 200::ms => now; } As I was writing this post, I figured out how to fix it. Connect the filter to the dac in the instrument shred: StifKarp inst => SuperFilt.highPass => dac; //connect to filter & dac And things seem to work fine. But wierd. Maybe the ticking or copying is per-shred? best, Graham

1 0

Shirts
by Kassen 23 Sep '06

23 Sep '06

Esteemed ChucKists... It seems that the shirt plan has drifted to the bottom of the priority stack. There were some ideas on that but nothing final. We had a picture of Guile (from Street Fighter), we had "chuck spork shred", "realtime isn't fast enough" and it occured to me that "powertools can maim" (from the Audicle video) would be fun as well. I might have missed one or two? I still think we need a shirt but I myself suck at organising such things. Is there still demand? Can we reach a consensus on a good slogan/design? Is there somebody with convenient access to a press and organisational responcibility? else is something like cafe press acceptable? I'll just asume at least somebody can make a design conform to printers demands? On the other hand, perhaps this plan drifted away from the list's atention because Tshirts might be completely out of fashion and now everybody wants sloganed chamber-robes? Kas.

4 4

Hid joypads in 1.0.2.7
by Kassen 23 Sep '06

23 Sep '06

Hi, list/ developers. I seem to have a problem with the new version of the Hid input. Particularly it looks like "msg.type == 3" has disapeared altogether. Practically speaking this means the directional buttons of my two joypads no longer work in ChucK. If this is true and there is no overwhelmingly solid reason to abandon those I'd realy, realy like to have them back because almost half of the notes of my joypad-melody construction depend on those and now the melodic side of my sequencer has become unplayable with no easy solution in sight (I realy need all the buttons and keep the axis free for modulations). For a second I thought they might have been given a proper name like the buttons and axis but those still show op on /examples/hid/joy.ck and now the directional ones don't anymore. None of the updated examples use the directional buttons either. This is a bit disturbing to me, could somebody tell me wether I'm missing some improved functionality or could we please, please talk about bringing them back? Yours, Kas.

2 2

Re: [chuck-users] Shirts
by babiakb＠bellsouth.net 23 Sep '06

23 Sep '06

lol how bout "Chuckers spork better" i want a shirt! > > From: Graham Coleman <gc(a)gehennom.net> > Date: 2006/09/22 Fri PM 10:45:49 EDT > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Subject: Re: [chuck-users] Shirts > > I forgot to mention the mode of production of my t-shirt. > > My friend had a party where we were doing this. > > He had a roll of acetate (like the stuff in overhead projector > transparencies). We printed out designs from an inkjet printer and used an > xacto knife to cut out the stencil. > > Then we mixed half and half acrylic paint and fabric medium. We used a > paint roller to paint the design over the stencil. > > All in all it was a good time, and not too much work. I'm still > experimenting with hand-painting to get the classic 3-color logo. > > Graham > > On Sat, 23 Sep 2006, Kassen wrote: > > > Esteemed ChucKists... > > > > It seems that the shirt plan has drifted to the bottom of the priority > > stack. > > > > There were some ideas on that but nothing final. > > > > We had a picture of Guile (from Street Fighter), we had "chuck spork shred", > > "realtime isn't fast enough" and it occured to me that "powertools can maim" > > (from the Audicle video) would be fun as well. I might have missed one or > > two? > > > > > > I still think we need a shirt but I myself suck at organising such things. > > > > Is there still demand? > > Can we reach a consensus on a good slogan/design? > > Is there somebody with convenient access to a press and organisational > > responcibility? > > else is something like cafe press acceptable? > > I'll just asume at least somebody can make a design conform to printers > > demands? > > > > > > On the other hand, perhaps this plan drifted away from the list's atention > > because Tshirts might be completely out of fashion and now everybody wants > > sloganed chamber-robes? > > > > > > Kas. > > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

2 1

m4 expansion for sample libraries hack
by Graham Coleman 22 Sep '06

22 Sep '06

Sample librarians, This is a stupid hack as a holdover for string ops. (if you can think of an idiomatic way to do this, lemme know) I have a local sample library in a file called drum.ck that formerly used relative paths like so: //a sampling UGen to compile all my drums public class Drum { ["drums/kick.wav", "drums/kick1h.wav","drums/kick2h.wav", "drums/kick3h.wav","drums/kick4h.wav", "drums/kick5h.wav","drums/kick6h.wav", "drums/kick7h.wav","drums/kick8h.wav", "drums/kick9h.wav","drums/kick10h.wav", "drums/C_Kick.wav"] @=> string kicks[]; ... } Problem with this arrangement is that executing a file not in the same directory would change the current directory. Hereafter referring to Drum in another shred would return the same relative path, but would fail to load the sample as a result of the change in current directory. To make sure my samples always loaded, I thought of using a macro processing language. I first tried the C preprocessor, but the one on my system (all of them?) did not want to expand macros inside double quotes. Next, I tried m4, of which I was able to find a windows port: http://gnuwin32.sourceforge.net/packages/m4.htm So, I made a variant of the drum sample library (drum.ck.m4): define(`DRUMPATH', `C:/Documents and Settings/Graham/My Documents/chuck/drums') //a sampling UGen to compile all my drums public class Drum { ["DRUMPATH()/kick.wav", "DRUMPATH/kick1h.wav","DRUMPATH/kick2h.wav", "DRUMPATH/kick3h.wav","DRUMPATH/kick4h.wav", "DRUMPATH/kick5h.wav","DRUMPATH/kick6h.wav", "DRUMPATH/kick7h.wav","DRUMPATH/kick8h.wav", "DRUMPATH/kick9h.wav","DRUMPATH/kick10h.wav", "DRUMPATH/C_Kick.wav"] @=> string kicks[]; ... } And ran an expansion command: >m4 < drum.ck.m4 > drum2.ck To get the expanded form: //a sampling UGen to compile all my drums public class Drum { ["C:/Documents and Settings/Graham/My Documents/chuck/drums/kick.wav", "C:/Documents and Settings/Graham/My Documents/chuck/drums/kick1h.wav","C:/Documents and Settings/Graham/My Documents/chuck/drums/kick2h.wav", "C:/Documents and Settings/Graham/My Documents/chuck/drums/kick3h.wav","C:/Documents and Settings/Graham/My Documents/chuck/drums/kick4h.wav", ... } Any other thoughts on doing this sort of thing? Making the world safe for samples, Graham

1 1

Re: [chuck-users] [chuck] 1.2.0.7 (dracula) released
by Graham Coleman 21 Sep '06

21 Sep '06

Nicely done. I can't wait to road test the new filters. Graham On Mon, 18 Sep 2006, Ge Wang wrote: > Dear all, > > chuck-1.2.0.7 (dracula) is available: > > http://chuck.cs.princeton.edu/ > > API deprecations. In the interest of more consistent naming, we have > deprecated some object names. 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. We've added a --deprecate flag that allows you > to stop, warn, or ignore upon encountering a deprecated item. The > default is 'warn'. > > Thanks to all who discussed on chuck-users and forum and contributed to > the many additions and changes in this release. They include Kassen, > Brian, Matt, Jukka, Eduard, Atte, David Powers, Graham Coleman and many > others. Also thanks to Ananya for much documentation work. A summary > can be found at the end of this message. Please let us know if you run > into any issues. > > Thanks and Happy ChucKing! > > Best, > chuck team > > --- > 1.2.0.7 > - (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 > -------------------------- > - (added) --deprecate:X flag > X can be stop, warn, or ignore - default is warn > - (added) STK BiQuad get functions pfreq, prad, zfreq, zrad > - (added) ADSR functions: > void .set( dur a, dur d, float s, dur r ); > void .set( float a, float d, float s, float r ); > - (added) new UGens (adapted from SC3 Server, Pure Data, CSound) > -------------------------- > LPF : resonant lowpass filter (2nd order butterworth) > HPF : resonant highpass filter (2nd order butterworth) > 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 > -------------------------- > - (added) new HidIn static variables for HidMsg message and device > types (spencer) > - (added) HidMsg fields to determine device type and number (spencer) > - (added) HidMsg functions with capitalization rather than > underscores (spencer) > (underscored functions deprecated) > - (added) .period for all oscillators > - (fixed) floating point denormals no longer cause potentially > massive CPU usage on intel processors, this includes > BiQuad, OnePole, TwoPole, PoleZero, JCRev, PRCRev, NRev > - (fixed) STK Echo.max no longer gives incorrect warnings > - (fixed) linux makefiles now respects CC/CFLAGS/CXX (Cedric Krier) > - (fixed) SinOsc/TriOsc/PulseOsc/SqrOsc/Phasor.sync now unified: > .sync == 0 : sync frequency to input > .sync == 1 : sync phase to input > .sync == 2 : fm synth > | > NOTE: the above changes may break/affect existing patches > using TriOsc, PulseOsc, or SqrOsc > - (fixed) TriOsc/PulseOsc/SqrOsc phase consistent with convention > - (fixed) ADSR now handles keyOff() before sustain state > - (fixed) ADSR now correctly inherits Envelope > > _______________________________________________ > chuck mailing list > chuck(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck >

1 0

HidIn @ joy-shake.ck with dracula
by Tasmo 20 Sep '06

20 Sep '06

I played around with my joystick and ChucK 1.2.0.7 on OS X and found something to change in chuck/examples/hid/joy-shake.ck The line 26 "if( msg.type == HidIn.joystickAxis )" must be "if( msg.isAxisMotion() )" now and so line 36 "if( msg.type == HidIn.buttonDown )" now "if( msg.isButtonDown() )". Same with examples in the miniAudicle folder.

2 1

More on what Envelope.time does.
by Kassen 18 Sep '06

18 Sep '06

Hi list, I had some question about Envelope so I did some looking around. I found this; https://lists.cs.princeton.edu/pipermail/chuck-users/2005-October/000049.ht… But strangely it has no replies. I can confirm the behaviour Graham found there, in fact it seems that when .target is quite high (like say around 500) and .time is set at .5 Envelope takes a huge amount of time to reach it's target. This is quite mysterious to me and not at all like what it's supposed to do. Could somebody kindly look into this? Thanks, Kas.

3 5

triosc phase
by Jukka Akkanen 18 Sep '06

18 Sep '06

With ChucK-1.2.0.7, triosc value is -1.0 at phase 0, and reaches 1.0 at phase 0.5. Does this happen for a specific reason, or is this accidental behavior? This appears wrong because the fundamental frequency of a triangle oscillator is a quarter wavelength ahead from a sine oscillator operating at the same frequency and same nominal phase. A similar issue exists with sqrosc, except the phase appears to be the opposite from expected when compared to a sine wave. I haven't looked at how any other oscillators behave yet. -Jukka

2 1

crash question
by Greg Brown 17 Sep '06

17 Sep '06

Hello all, I was recording a session (using /examples/basic/rec-auto.ck -s) and I recieved the following error about a quarter of the way through: _______ chuck(366,0xa000ed98) malloc: *** vm_allocate(size=10604544) failed (error code=3) chuck(366,0xa000ed98) malloc: *** error: can't allocate region chuck(366,0xa000ed98) malloc: *** set a breakpoint in szone_error to debug terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc Abort trap _______ This is a relatively large session (ca. 6.5 hours), and at the time the .wav file size was about 514MB (out of a projected 1.5-2.0GB). There was more than adequate room on the hard disk to recieve the file and the CPU was not busy with other tasks. The machine is running OS X.4.6 with Dual 1.25 GHz G4 and 512 MB RAM. My questions: a.) what happened? b.) how can I avoid having it happen again? Thanks for chuck -- I am enjoying it very much! Greg Brown [University of Georgia]

3 2

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

Survey on Musical Instruments
by thor 08 Sep '06

08 Sep '06

Dear ChucK people. We'd be very interested in your views: [with apologies of cross posting] To all musicians (acoustic and digital instrumentalists) and composers We are doing a little survey on people's relationship with their instruments and tools. It is a comparative study of the differences between acoustic and digital instruments from the perspective of usability or ergonomics. Amongst many other things, we are interested in the experience of playing or composing for the different instruments, but also people's views on how the instrument/tool affects the musical ideas and what can be played/composed. Please help us to get an understanding of these issues by filling out the following survey: http://www.ixi-software.net/survey We will of course present our findings when processed with a research paper and online presentations. Thanks in advance. the ixi team

1 0

MAUI?
by eun.sung＠no-log.org 31 Aug '06

31 Aug '06

hi i'm trying running miniAudicle 1.3.5 on osX.4.6 as i try to launch slide01.ck, i get the following console output : [slide01.ck]:line(1): undefined type 'MAUI_Slider'... [slide01.ck]:line(1): ... in declaration ... and it gives the same with the different MAUI elements does using MAUI elements need some particular requirements? thanks

4 5

miniAudicle-0.1.3.4 failed to build on Gentoo Linux
by schwaahed 29 Aug '06

29 Aug '06

Hi, I am running Gentoo Linux. I failed to build miniAudicle-0.1.3.3, but I assumed it was the wxWidgets unicode issue. I am running wxGTK-2.6.3.2. Any clue on what I need to do to get this to build? schwaahed schwaabook miniAudicle-0.1.3.4 # make linux-jack make -f makefile.jack make[1]: Entering directory `/usr/local/music/ChucK/miniAudicle-0.1.3.4' gcc -o wxw/mAParentFrame.o -D__LINUX_JACK__ -D__LINUX__ -D__MA_WXWIDGETS__ `wx-config --cppflags` -O3 -c -DwxABI_VERSION=20600 -D__CK_SNDFILE_NATIVE__ -Ichuck/src -Iwxw -I/usr/local/music/ChucK/miniAudicle-0.1.3.4 wxw/mAParentFrame.cpp wxw/mAParentFrame.cpp: In member function `virtual bool mAApp::OnInit()': wxw/mAParentFrame.cpp:159: error: `wxCommandEventHandler' was not declared in this scope make[1]: *** [wxw/mAParentFrame.o] Error 1 make[1]: Leaving directory `/usr/local/music/ChucK/miniAudicle-0.1.3.4' make: [linux-jack] Error 2 (ignored)

4 22

syntax coloring for chuck in jedit
by jes�s gollonet 23 Aug '06

23 Aug '06

Hi all. I've just published a chuck edit mode (an xml file defining a syntax coloring scheme) for the jedit code editor. It gives different colors for ugens, methods, keywords and operators. If anyone uses jedit, you can grab the xml file and see the instructions in my blog: http://www.jesusgollonet.com/blog/?p=135 If you want to give it a try, i totally recommend it as a single all-purpose editor. It's totally extensible and I'm working on some more niceties for chuck editing (abbreviations, macros...). www.jedit.org Best! -- jesús gollonet htt://www.jesusgollonet.com

2 1

syntax coloring for chuck in jedit
by jes�s gollonet 23 Aug '06

23 Aug '06

Hi all. I've just published a chuck edit mode (an xml file defining a syntax coloring scheme) for the jedit code editor. It gives different colors for ugens, methods, keywords and operators. If anyone uses jedit, you can grab the xml file and see the instructions in my blog: http://www.jesusgollonet.com/blog/?p=135 If you want to give it a try, i totally recommend it as a single all-purpose editor. It's totally extensible and I'm working on some more niceties for chuck editing (abbreviations, macros...). www.jedit.org Best! -- jesús gollonet htt://www.jesusgollonet.com

1 0