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

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

MAUI Window Shooting Game
by Les Hall 17 Jul '09

17 Jul '09

Here is a fun little game that involves some MAUI abuse - moving target windows! Click on the moving target button to get a smaller, faster target window and an exciting phasor sound (from Kassen). Every mouse click makes the window faster, hit or miss. It's classic 1980's arcade excitement; I found that the growing tension of the speed and noise was rather exhilarating. Krank up the volume and blast away! I hope it's OK to post code to the list (it's only 4.5 kB) - I seem to recall posting code works, we'll see... Enjoy, Les

4 3

Kassen's Phasor
by Les Hall 17 Jul '09

17 Jul '09

I just gotta share this one-liner that Kassen posted. It rocks! SubNoise s=>dac;int n;while(++n%241+1=>s.rate){(n%83)*ms+ms=>now;5=>Std.srand;} Try ckicking on "replace shred" in miniAudicle a few times, it's a phasor! Les

6 10

CNoise
by Kassen 14 Jul '09

14 Jul '09

Fellow ChucKists. CNoise is under-documented, the only official reference to it seems to be that "cnoise" is depreciated, with "CNoise" being prefered since 1.2.0.7. Still it's there in the source and can be used without errors. However, it doesn't seem to work like I expect it to. Based on the source I'd say correct usage should be something like this; CNoise n => dac; "white" => n.mode; second => now; "pink" => n.mode; second => now; "flip" => n.mode; second => now; "xor" => n.mode; second => now; "brown" => n.mode; second => now; "fbm" => n.mode; second => now; This does indeed compile but all I get is one type of noise only. Could somebody kindly help or explain? Yours, Kas.

2 2

Std.srand() abuse
by Kassen 14 Jul '09

14 Jul '09

Dear list, While exploring noise UGens I chanced upon the rather interesting technique of periodically resetting Std.srand() which sets the seed for noise in ChucK, thus resetting the output of the noise UGens; //mind your speakers, ears and neighbours! SubNoise n => dac; .2 => n.gain; while(1) { ((now/2::second)$int)%8 + 2 => n.rate; now%250::ms+ms=>now; 5 => Std.srand; } Interestingly this type of modulation is system-wide so running two files that both try to do this at the same time will result in rather complex sounds. Have fun, Kas.

1 0

The ChucK Show
by Les Hall 11 Jul '09

11 Jul '09

Hi folks, The ChucK Show this week was our best one ever. Sunshine is back in town and she always makes the show fun. I wrote a 1,000 line controller program with lots of bells and whistles. There were contributions from two newbie ChucKists, mattb was the ChucKist of the week, we took a quick tour of the Princeton ChucK website and went through a bunch of examples. Plus I played guitar a little bit as I have newly learned a basic finger picking technique. For next week I'd like to continue the exploration of the examples, but I'm not overly familiar with the entire collection of what's there. Would anyone on the list mind suggesting some examples that make good audio for the show? I will go through the STK directory, but I am unfamiliar with all of the other directories and it would be torture to go through *everything* this week before the show. So suggestions are welcome, thanks. Enjoy! Les (Inventor)

1 0

chuck mode for emacs
by Kao Cardoso Felix 05 Jul '09

05 Jul '09

Hello folks, I've just discovered and started learning ChucK and It's very neat. As I'm an Emacs user I downloaded the emacs mode for editing ChucK files. It was rather old and was missing some functionality so I've made an update. http://bitbucket.org/kcfelix/emacsd/src/tip/my-lisp/chuck-mode.el I've changed the syntax highlight to be more consistent with how other languages are highlighted inside Emacs and added all keywords, types and library functions listed on the documentation. Class and method name highlighting is not working yet, but I plan on adding it soon. Code to run the ChucK VM as an inferior process inside Emacs was commented because it wasn't working before. I've made it work and changed some keybings. Now it work like this: C-c C-c inside a ChucK buffer will send the buffer code to the VM. If there's no VM process one will be created. C-c C-d remove a shred from the VM by a numeric id (is there other ways to identify shreds besides numbers?) C-c C-r replace a shred with the code on the current buffer. I also added support for easy customization for the path of the chuck executable, so you don't have to edit lisp code to change it. Well, I'm planning to update it frequently to make it better according to my use of it, but if there's anyone using Emacs for ChucK and want to give some advice it would be very nice :) []'s -- Kao Cardoso Félix Página pessoal: http://www.inf.ufrgs.br/~kcfelix Blog: http://kaofelix.blogspot.com

4 8