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

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