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

chuck/[mini]audicle vs. gcc 4.4.x
by Fernando Lopez-Lezcano 04 Sep '09

04 Sep '09

This tiny patch makes chuck compilable under gcc4.4 (Fedora 11): ------- --- chuck-1.2.1.2/src/util_string.h~ 2008-07-16 02:55:17.000000000 -0700 +++ chuck-1.2.1.2/src/util_string.h 2009-06-11 18:24:55.349093274 -0700 @@ -36,6 +36,7 @@ #include "chuck_def.h" #include <string> #include <vector> +#include <stdio.h> // itoa -------- I'm also hitting this error in miniaudicle and audicle, any help?: gcc -D__LINUX_ALSA__ -D__CHUCK_STAT_TRACK__ `pkg-config --cflags gtk +-2.0` -O3 -c -I../lang/chuck-1.2.1.1/src -D__CK_SNDFILE_NATIVE__ ../lang/chuck-1.2.1.1/src/ugen_xxx.cpp ../lang/chuck-1.2.1.1/src/ugen_xxx.cpp: In constructor 'CNoise_Data::CNoise_Data()': ../lang/chuck-1.2.1.1/src/ugen_xxx.cpp:1183: warning: deprecated conversion from string constant to 'char*' ../lang/chuck-1.2.1.1/src/ugen_xxx.cpp: In function 'void sndbuf_ctrl_read(Chuck_Object*, void*, Chuck_DL_Return*, Chuck_VM_Shred*)': ../lang/chuck-1.2.1.1/src/ugen_xxx.cpp:2590: error: invalid conversion from 'const char*' to 'char*' make[1]: *** [ugen_xxx.o] Error 1 -- Fernando

3 4

browser-controlled circular synth
by Andrew Turley 30 Jul '09

30 Jul '09

I thought you guys might be interested in this. I put together a little demo of a circular sequencer that is controlled through a web browser. I use Chuck for some (most) of the back end. Here's a link to the blog post which includes video and code: http://www.pillowsopher.com/blog/?p=107 andy

2 2

Re: [chuck-users] MAUI Window Shooting Game
by Les Hall 26 Jul '09

26 Jul '09

mike - glad you enjoyed it, 13 is pretty good, I usually get to 13 myself. Tom - 19? dang, you must have the reflexes of a teenager! Yes, the minimum button size is one pixel. Kas - being a music novice, I don't know what polyphony is. I just modified your code until it made a one-shot. The only thing is, it doesn't quit for some reason - once you fire your first shot you get sound for the rest of the game. That's a good thing for the game because it keeps the tension level up, but I don't understand why it does that. All - I would like to add more to the game like some Space Invaders marching noises or some Nintendo music, or perhaps a time-based score factor, but what the hey, it's done and it's fun. I wonder how else we can muck with MAUI for entertainment purposes? Les

3 2

Re: [chuck-users] GC vs real-time (was Getting Started with ChucK)
by Hans Aberg 25 Jul '09

25 Jul '09

On 24 Jul 2009, at 23:53, Stefan Blixt wrote: > I don't follow all the theory and reasoning here, so I don't know if > you're suggesting something different, but I constantly make use of > the exact timing in stuff like this: > > fun void shred1() { > while (true) { > // Play note > 50::ms => now; > } > } > > fun void shred2() { > while (true) { > // Play note > 50::ms => now; > } > } > > spork ~ shred1(); > spork ~ shred2(); > > With the timing model in ChucK I can depend on these to run in sync > forever, and when one note is initiated the other has either been > initated just before or just after. The discussion was about how to change the timing in more fine-grains below what Chuck does. So in your example, in "Play note", you want the notes to be initiated at the exact same time. But do you need the notes to play exactly in phase, say? This would be important if you want to combine different shreds into a single sound generator, say in left and right channels. But suppose you have built your sound generator, and combined them in different music lines, or as several strings in the same note as in a piano. Then the timing of the notes on should still be exact, but not of the individual generators. So the "Play note" can "out-source" the playing of the sound of the note :-). > I don't know how SuperCollider and CSound and others work, but I > feel that with another timing module based on threads, these beats > would start to drift apart in a manner that would be noticeable > fairly quickly (minutes or tens of minutes). Also, I can speed up > sequences into audible range and back again in a reliable manner. I > don't need to kludge with some synchronizing event or stuff like > that. I wouldn't want this feature to be broken. It is a good point that Chuck syncs forever, even if there is a long concert. Here is a program with a different approach http://impromptu.moso.com.au/tutorials/time.html It is a good question what happens with that model in long sessions. Perhaps there results unwanted phasing. Hans

1 0

Re: [chuck-users] Getting Started with ChucK
by Hans Aberg 24 Jul '09

24 Jul '09

On 21 Jul 2009, at 20:30, Tom Lieber wrote: > 2009/7/21 Hans Aberg <haberg(a)math.su.se>: >> So it might be better to tweak some existing functional language into >> accepting Chuck's timing concepts. > > Want to help with ruck? :D > > http://github.com/alltom/ruck/tree/master > > It all works and has nice sugar like chucking arrays of objects and > lambda properties, but it's too slow for real-time at reasonable > sample rates. I haven't sat down to do the porting to C I think it > needs to perform well, even though I think it shows promise. I looked at Ruby, and didn't like some aspects of it, though I do not remember what it was :-). But there is a problems with the GC. The Wikipedia page did not specify. Pretty much the only GC that can fulfill the requirements of exact timing without jumps and concurrency is reference counting. Experts will ensure that this need not be so, but also admit that it is hard to achieve in practice. So I think Chuck, if extended with lambda calculus might try adding it on top what already exists, and then just use reference counting for GC. Hans

6 24

Getting Started with ChucK
by Greg Sabo 21 Jul '09

21 Jul '09

Hello, I've been interested in trying ChucK for several years now but I've just recently started playing with it in earnest. I like what I see so far :) I have one thing that's bothering me - coming from SuperCollider, I'm used to being able to put UGens in pretty much any argument, like this: {a = SinOsc.kr(freq: 20, mul: 300); SinOsc.ar(freq: a, mul: 0.8)}.play If I wanted basic FM. So intuitively, trying out ChucK for the first time, I tried to do: SinOsc mod => SinOsc car.freq => dac; Which didn't work. After a bit of reading, I understand that UGens have "inputs" in ChucK, by default set to modify the frequency, and if you want to modulate a different parameter, you change that object's sync attribute. That seems kind of weird/unintuitive to me, is there something that I'm missing that went into making the syntax like this? Besides that, I find ChucK really fun to play with, and I look forward to making some zany sounds with it :) -Greg Sabo

8 21

odd hid issue (touchpad)
by Kassen 18 Jul '09

18 Jul '09

Dear list, Last night I found a bit of a odd issue with a touchpad on a laptop running Linux. I tried to open the mouse as a HID device and it correctly found the one mouse attached, being the build in touchpad which it described as acting through ps2 (I believe that's normal for touchpads). The odd thing is that ChucK didn't get any data from it when moving my finger over it or clicking the buttons. I then pluged in a Logitech optical mouse which was -after a restart of the vm for safety- identified as mouse 0 and which did operate correctly. I'd be happy to run any and all tests that might help diagnose the bug if it's deemed one. I should note that this was running a non-standard version of the Mini, being one with the latest ChucK plugged in and Tom's CNoise fix on top of that but I don't think either should affect this. Yours, Kas.

3 12

Re: [chuck-users] odd hid issue (touchpad)
by Hans Aberg 18 Jul '09

18 Jul '09

On 18 Jul 2009, at 22:08, Kassen wrote: >> That is an interesting use. If one does not have a turntable to >> scratch, I checked one can use the top of a matte CD or DVD - I >> only tried without print, and the underside (that carries the data) >> didn't work. So that might serve as an interface to scratch some >> audio-file > > Yes, it's a very interesting way to create a expressive interface > with little cost or fuzz. I've seen videos online of people simply > sticking a optical mouse into a pizza box they had cut up. My friend > Rob Bothof went a bit further than that; > http://forum.itchymuzik.com/viewtopic.php?f=5&t=53 > (some docs and a example video) > > I simply hooked that up to LiSa and had it control the .rate() while > continuously recording. This simple setup was already a lot of fun, > far better than the toy turntable for Playstation that I've been > using. The experience is very tactile and intuitive. He says he has problems with recording constant turn velocity. There is no information about the surface the mouse reads off - if that is uneven, that may cause problems. For recording turns, one should use a Hall sensor, like this one: http://www.globalspec.com/FeaturedProducts/Detail/BEIDuncanElectronics/9360… This is inexpensive though not USB, but netsearching for words like "USB rotary joystick Hall effect controller" may produce some results. >> These are called "extended keyboards", or full size, at least on >> the Mac side >> http://en.wikipedia.org/wiki/Model_M_keyboard >> I have an old Mac one, where the function keys are without gaps and >> no space the other keys. This was very good for the diatonic key >> map, as it becomes enlarged. But I found it difficult to do >> ornaments on it: the keys are a bit too chevy. It is A1048 here: >> http://en.wikipedia.org/wiki/Apple_Keyboard#Apple_Keyboard >> I have for couple of months used the A1242 - it is much better on >> ornaments, but not as good as a musical instrument. The rather >> short action takes some time to get used to. > > Yes, I see. Personally I don't care that much about ornaments ... They are important in melodic development to provide character and style. > ...but I do care about the tactile feel which is where I feel the > Model M really shines. Of course there are also many who detest it > for the weight, the noise, the size and the heavy feel. This is pretty much and individual preference - some like heavy weighted keys, and even think it helps playing faster, others the reverse. All typing keyboards seem to have an unpredictable depressing point which makes them less suitable for music interpretation. >>> To me these seem like under-appreciated factors. If we are going >>> to use devices like these for music then tactile feel matters for >>> expressiveness and it will pay off to find one that suits our >>> tastes. >>> >> There was a adding cards to the computer also on the Mac, but they >> are mostly gone now, because the CPU/GPU are so powerful, it is not >> needed. > > I meant that some people may want to add exotic devices, like > hookups to cash registers or industrial machines or sensor arrays or > vending machines or.... It seems to me that some drivers, some of > the time, will be unavoidable. Take for instance video editing; that > require a rather largge video card with many in and outputs. We can > hardly make vendors of such devices wait for a new OS update before > shiping a new model. Video cards seem a exception in general, Ati > and Nvidea like their strange drivers to access their own features > so well they even made Linux ones Aside from that this would give a > bit too much power to OS makers for my tastes. These are the GPUs I mentioned. Mac OS X is developing special language support for these. So the exact driver thing will be transparent. Learning a new way to program fro every device requires too much of an effort. So this is probably the trend for the future. >> One reason to avoid custom supplied drivers is that they do low >> level things that may cause the computer to crash. On Macs, that is >> called "kernel panic". Basically, it means that the kernel running >> the processes gets some code that it cannot handle. Often, there is >> a driver for a piece of hardware involved. The hardware, the OS and >> the computer, though, are fine. > > Yes, I agree. On Windows I already took to ignoring most driver > discs and having the more stable default ones sort it out. On Linux > the default ones are often all we have and I have to say they work > very well. Without aiming to get too political; I don't think the > issue is with users installing their own drivers, I feel the issue > is with vendors that create buggy ones, often without good reason > because the standard ones do the exact same thing. I've seen that > many times with joypads and joypad adapters. That need not be a > matter of platform, I have little doubt that a exotic device in need > of special drivers could bring OSX or Linux to it's knees as well if > it had a bad driver. On the Mac, I noticed that the printer drivers now all seem very small, except for HP, which was huge, like 1 GB. Hans

2 2

Ruben's tube
by Hans Aberg 18 Jul '09

18 Jul '09

A fiery musical experiment: http://www.youtube.com/user/twinrawk Perhaps something for Chuck live performances. :-) Hans

1 0

Fwd: odd hid issue (touchpad)
by Kassen 17 Jul '09

17 Jul '09

Sorry, I accidentally send this to just Hans, it should of course have gone to the list. Hi, Hans! The general interface just provides a list of (device_type, button_number, > button_range, button_intended_use) or something (don't remember details). > Chuck implements some of those choices, hardcoded with respect to > (device_type, button_intended_use). > Indeed, ChucK takes the most common and universal ones. It's not perfect but as a simplified interface it's quite pleasant to work with and mostly gets most of the job done. >> [chuck](VM): sporking incoming shred: 1 (mouse.ck)... >> mouse 'SynPS/2 Synaptics TouchPad' ready >> > > So this means that the touchpad has been registered as type mouse. > Yes, indeed. Frankly I think that so far it's a clear cut case. I feel it's a mouse, my windows manager (Gnome) agrees it's a mouse and ChucK accepts it as one yet there is no data coming in or being printed from mouse.ck. You do have a valid point about the difference in scanning between a regular mouse and a pad but at least the buttons should be buttons in any case yet I'm not seeing buttonpresses. This is why I suspect something is wrong. I do believe touchpads also output the change in position. >> > > They may or may not, I think - they HIDs can pretty much choose what > varibles they want to provide. There was another thread withy this track-pad > problem. > Yeah.... but this is not some exotic specialised device. I would think it's quite clear that a touchpad on a laptop will be used as a mouse. > > If you have a Mac with gcc on it, you might try the program I hacked up. It > lists all the variables for all attached HIDs. > No, sorry, I do have some Linux computers with GCC on them. Yours, Kas.

2 1