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

Rock Band Wireless Keyboard: is it any good?
by Lucas Zawacki 11 May '11

11 May '11

Has any of you experimented with this device http://www.amazon.com/Rock-Band-Wireless-Keyboard-PlayStation-3/dp/B003RRTX… ? It looks interesting and packs a lot of punch for a $60 device. It has a midi interface, a lot of neat buttons and a touch sensitive bar! It would be especially cool if the computer could recognize it and all the keys as a joystick device so one could use it in a true wireless fashion without worrying about the midi adapter. I'm seriously thinking about buying one, but don't want to risk getting one just to find out that it won't work or has lot's of limitations... Thanks!

3 5

MIDI guitars
by Robert Poor 10 May '11

10 May '11

Though bit off topic, I remember a nifty guitar to MIDI system that Julius Smith and Phil Gosset developed in the back rooms of CCRMA. At the moment it detected a string pluck, it would make a rough guess of the pitch and immediately issue a NOTE_ON command. Then it would start issuing pitch bend commands to refine the guess as the waveform became more periodic. So it was responsive and didn't require a guitar with a wired neck. Julius: did anything come of that design? - Rob

1 0

(no subject)
by musicdev 08 May '11

08 May '11

http://kabarknives.handmadebestgifts.com/wp-content/plugins/myblog.html

2 1

prevent samples from clipping
by Timothy Leonido 28 Apr '11

28 Apr '11

Hey all, What's the best way to prevent samples from clipping in chuck? My problem is that my bass samples are too long for the time advanced, which creates a rythmic popping sound. Any advice would be appreciated. Thank you, Tim

2 1

safe delay
by Timothy Leonido 21 Apr '11

21 Apr '11

I am often getting a console message reading "DelayL: setDelay(-) too big!" I change the parameters in my patch but the warning persists. Any advice here? Thank you, Tim

2 1

SndBuf allocating 2x memory?
by Josh Adams 18 Apr '11

18 Apr '11

Hey everybody, After noticing my test SndBuf programs were eating more memory than I expected I started looking around on the list and wiki but couldn't find any relevant discussions. Here's how it goes: airj:~ josh$ chuck --version chuck version: 1.2.1.3 (dracula) exe target: mac os x : universal binary http://chuck.cs.princeton.edu/ airj:~ josh$ cat tmp/buf.ck SndBuf b; "tmp/bigfile.wav" => b.read; while (1::second => now); airj:~ josh$ du -sk tmp/bigfile.wav 769308 tmp/bigfile.wav airj:~ josh$ chuck --loop & [1] 20706 airj:~ josh$ ps -orss= 20706 4484 airj:~ josh$ chuck + tmp/buf.ck airj:~ josh$ [chuck](VM): sporking incoming shred: 1 (buf.ck)... airj:~ josh$ ps -orss= 20706 1531692 airj:~ josh$ Looks like ChucK/SndBuf's resident size is growing a little under 2x the size of the file I'm trying to buffer. Any ideas? Cheers, -josh

2 1

SndBuf resource usage
by Josh Adams 18 Apr '11

18 Apr '11

Hi there, I found a thread or two in the past that talked a little about this. I'm hoping that in the time since those discussions there've been some internal improvements to ChucK that might help me have a bunch of samples ready to fire concurrently without eating my box alive. Here's how I repro the issue (running on a late-model 2.13GHz MacBook Air): SndBuf buf[512]; // gets more responsive as I reduce to <384 or so fun void connect(SndBuf b) { b => dac; } for (0 => int i; i < buf.cap(); i++) { spork ~ connect(buf[i]); } while (1::second => now) <<< now >>>; If there's nothing I can do about SndBuf's wasteful behavior is there a better/more ChucKian-approved way to prepare a bunch of independent audio buffers (hopefully >1024) for arbitrarily-timed concurrent playback? Really hoping that the answer isn't that I need more cpu cycles on that core and/or that I'll need to distribute ChucK and set up some kind of sync mechanism :-/. I have very similar performance results with WvIn btw. Thanks a bunch! -josh

2 3

record and play multiple LiSa objects on multiple channels
by Harald Gutsche 11 Apr '11

11 Apr '11

Hi chuckers, Kassen: >Fortunately that's not correct. You can use quite a few, if you like; >LiSa a => dac; >LiSa b => dac; >//etc > >If this gave you trouble there is likely something else that went wrong. If you send a (minimal) example that demonstrates the trouble you had we can look at it and try to help. ok, I tried again to do the following (as a beginning): - record stereo sound - play it back in loops - save it in parallel ---------------------------------------- I tried many variations and until now didn't find a way to do this all together. Please use a fast panning stereo sound for all examples (e.g. one panning cycle in 1 second). I could simulate this in chuck, but then this would make everything less clear. Let's start with a first problem. LiSa as you said above can be instantiated multiple times, you are right, this works (and there are examples for that). The chuck crashes I mentioned in a former mail can be reduced to the following code: LiSa looper; // this works: adc => looper => dac; adc.chan(0) => looper.chan(0) => dac.chan(0); adc.chan(1) => looper.chan(1) => dac.chan(1); when running on chuck 1.2.0.8 (which was my first contact with chuck). Now I compiled 1.2.1.4-dev-2 (from the posted svn repo), which doesn't crash, "fine" you say. ---------------------------------------- So next thing coming to mind is: 2000::ms => dur record_time; //1 => int nchannels; 2 => int nchannels; LiSa looper; record_time => looper.duration; for(0 => int c; c < nchannels; c++) { adc.chan(c) => looper.chan(c) => dac.chan(c); } adc => dac; <<<"record", "">>>; 1 => looper.record; record_time => now; 0 => looper.record; adc =< dac; <<<"play", "">>>; looper.play(1); looper.loop(1); //for(0 => int c; c < nchannels; c++) { looper.chan(c) => dac.chan(c); } // go while( true ){ 1000::ms => now; } this seems to record only one channel which is played on both dac channels. ---------------------------------------- Ok, lets try another one, multiple LiSa objects connected to the adc/dac channels: 20::ms => dur crossfade; 2000::ms => dur record_time; fun void loop_sampler(int c) { LiSa looper; adc.chan(c) => looper => dac.chan(c); adc.chan(c) => dac.chan(c); record_time => looper.duration; <<<"record", c>>>; 1 => looper.record; record_time => now; 0 => looper.record; adc.chan(c) =< dac.chan(c); <<<"play", c>>>; looper.play(1); looper.loop(1); looper => dac.chan(c); 2 * record_time => now; } spork ~ loop_sampler(0); spork ~ loop_sampler(1); // go while( true ){ 1000::ms => now; } surprisingly, this doesn't play back anything in chuck 1.2.1.4-dev-2. I checked the general logic by simply replacing all occurencies of ".chan(c)" with nothing in the editor, which works, but is mono. But in chuck 1.2.0.8 it works unchanged!

5 13

Re: [chuck-users] wiimote hacks? GameTrak by Mad Catz is pretty cool...
by Robert Poor 10 Apr '11

10 Apr '11

[David: I'm adding chuck-users to the To: list -- hope you don't mind] On Sun, Apr 10, 2011 at 16:55, David Loberg Code <d.loberg.code(a)wmich.edu>wrote: > Any further advice on gametrak hacks? I found this DIY. > http://x37v.com/x37v/writing/mad-catz-gametrak-mod-for-maxmsp/ > Does it have to be a specific version of the gametrak? (i.e., gametrak > for x-box, gametrak for pc, etc.) > thanks, > david > I think that mod will work with "nearly any" GameTrak you can get your hands on, but I won't promise it. All I know is that I bought a Game Trak for $10 on Amazon, made the mod, and it worked on the first try. FWIW, the source code I just pushed to github has a bunch of GameTrak specific code, including a "raw MIDI to event" driver, a sensible filter (so your code doesn't get flooded with spurious updates), and a "pluck detector" (you can pluck on the monofilament to generate an event). Relevant files are "game_trak_*" in https://github.com/rdpoor/chuck_performance_setup/tree/master/lib - Rob

1 0

chuck_rational and chuck_performance_setup on github
by Robert Poor 10 Apr '11

10 Apr '11

ChucKers: By popular request, I've just created two ChucK specific "git repositories" that you can view, download and (if you are versed with git) create branches and update. One is a rational number package, that efficiently converts between floating point numbers and rational approximations (in the form of a/b, where a and b are integers). The other is the extensive setup I have used for live performance. One of the funner bits are: * lib/semaphore.ck, which can wait for an event or for a time, whichever comes first. * a comprehensive dispatch/observer message passing mechanism for distributing events. To get there: * https://github.com/rdpoor/chuck_rational * https://github.com/rdpoor/chuck_performance_setup Share and enjoy (code and comments, etc) - Rob

2 2