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

(no subject)
by inventor-66＠comcast.net 05 Oct '08

05 Oct '08

Kassen, I will look into tools for EChucK, though I suspect it will be a mix of assembler and C tools due to the chaotic and buggy nature of Microchip tools. It doesn't look like there is popular enough support for EChucK to justify having its own sub-forum. Lots of reads but few posts, so I doubt if it needs its own sub-forum just yet. I emailed Ge as you suggest about the name and copied to you. Thanks, Les Dear Les, Some suggestions; *If you are going the PIC route you may need to start thinking about a SDK. Some of my best friends think ASM is fun but then again... I tend to hang out with relatively unusual people. *This is veering a bit off-topic; not all ChucKists will be interested in this and not everyone who is interested in this will be interested in ChucK. I suggest you ask Mosc for your own sub-forum on EM for this project. You are already linking to EM on your page about this and Mosc is very supportive of open DIY projects. If you don't have it I could give you his address. * I'd sugest you ask Ge about using the ChucK name for something related yet different like this. I could imagine using something like "SticK", a name that would refer to a possible result of "ChucKing" some object, it could refer to sticking objects to eachother and it might refer to educational uses as well. Something like that could save confusion. These are purely my own personal opinions at this moment but right now I feel this idea is evolving into something that does -and can- stand on it's own. I suspect a aproach like that could improve things for everyone; this is note some veiled way of saying "stay on topic"; I'll be keeping a close eye on this regardless of how and where it evolves. Yours, Kas.

1 0

Re: [chuck-users] Electronic ChucK
by inventor-66＠comcast.net 04 Oct '08

04 Oct '08

Mike, I'm open to any digital control interface that anyone wants to use. Although I do have to define *some* standards, I'm trying to be as open and flexible as possible. If you've got an Arduino and you want to connect it to EChucK, then I say go for it. Just make sure you know what you are doing and don't fry another module, haha. Now having said that, I'm planning to actually *sell* PIC processor boards. The dsPIC I have chosen is $3 US in low quantities direct from Microchip, and for that you get a stand-alone 40 MIPs DSP with 6 channels of oversampled audio in and a few PWM outputs. That's a lot of processor for three bucks and it is only 18 pins so it is small too. The dsPIC is my next circuit board, and it will be programmable to be a do-it-all module. Whatever you need, a SinOsc, an FFT/IFFT class, a delay line, a multiplier - if you can program it then you can load up one of those modules to do the job. So some of the more digitally inclined folks will buy a bunch of dsPIC modules and code them up. Others will prefer to buy true analog modules, both will be available. Now, since folks will be learning and using PICs, natually the PIC interface products like USB, UART, RF, etc. will become product options. But that doesn't mean you can't use an Arduino if you want to do so. Of course smart technical people, being resourceful and creative, will do whatever they want regardless of the standards I set anyway, lol. So all I can really do is set standards for *my* boards and ask that people generally try to stick to them unless there is reason to do otherwise. I hope that clears things up a bit. Take care, Les (Inventor)

2 1

Time to SMIRK!
by Rebecca Fiebrink 04 Oct '08

04 Oct '08

Hi folks, We call your attention to the Small Music Information Retrieval toolKit, SMIRK, available and waiting for your download and abuse at http://smirk.cs.princeton.edu . Like smelt (http://smelt.cs.princeton.edu), SmirK is a set of ready-to- use building blocks and examples. It's all written in ChucK, so there's nothing to "install." (But it does come with its own ChucK class hierarchy, which you'll have to download, so you'll have to set your path carefully, unlike smelt. See the comments in each file for instructions.) Use the code as-is, or modify it to suit your needs. sMiRk includes 2 key components: feature extraction (using the UAna framework at http://chuck.cs.princeton.edu/uana/) and classification (e.g., k-nearest-neighbor, AdaBoost). This comes with some simple keyboard-based and MAUI-based interfaces for training and running classifiers. For example: * Train a classifier to recognize vowels versus consonants, and then apply it to pan the incoming audio appropriately * Do the same based on instrument, speaker, or even genre of songs in your iTunes collection * Recognize different trackpad or accelerometer gestures * Do all this training on-the-fly, in real-time! * Use MAUI to do simple visualizations of features and classification results (for Mac only; not required) We'd love you to download smirk, read about it, ask questions about it, abuse it, request new features, and contribute to it yourselves. We've set up a wiki at http://wiki.cs.princeton.edu/index.php/Chuck/SmirK where you can do all these things. Meanwhile, we're continuing to hack away... Cheers, Rebecca, Ge, and Perry

6 5

Re: [chuck-users] Time to SMIRK!
by Rebecca Fiebrink 03 Oct '08

03 Oct '08

> Problem solved. Please recommence your surfing! > This sounds good but I'm getting a "403, forbidden" on that and on > /index.html there. /index.htm gives me a 404 so I suspect there is a > issue > with settings on the index file. Regarding include/import mechanism: I agree, it would be totally wonderful. My hack for getting around this in smirk: A cludgey "add-machine" file for all mini-projects/examples. I don't have anything better right now, sorry! Rebecca

2 1

Re: [chuck-users] Electronic ChucK
by inventor-66＠comcast.net 03 Oct '08

03 Oct '08

Mike, The computer interface I am planning is an analog one. It will receive stereo audio from the headphones jack and send stereo audio to the line-in Jack. This way we can generate whatever signals we want from ChucK and pipe them into EChucK on adc.left and adc.right. We can also receive two separate audio signals on dac.left and dac.right. I was sort of generalizing the stereo input and outputs into a pair of do-anything audio outs and do-anything audio ins. This opens up many possibilities for ChucK to control EChuck or provide signals for EChucK. Don't have a filtered noise module in your EChucK module collection? Just write a ChucK program and you've got it. Want an analog multiplier but don't have a multiplier module? send the two signals to line-in, have ChucK multiply them, and receive your result on headphones out. That's the idea. The computer interface module will be just a quad opamp circuit with perhaps variable gain/attenuation and diode clamping for the line-in signals to protect your computer. It should be quite low in cost, just $5 or so in parts + profit margin for the seller. Other computer interfaces such as USB, parallel port, etc. are planned but I'm doing the simplest, easiest modules first to get a working prototype built and tested/working. Cheers! Les (Inventor)

4 3

Re: [chuck-users] Electronic ChucK
by inventor-66＠comcast.net 03 Oct '08

03 Oct '08

I threw together a quick starter web page with a somewhat funny introduction. It has links to the Eagle CAD files so you can download them and check them out. So far there is only the Power and ADC microphone interface. Here is the link: http://www.freedomodds.com/music/echuck/index.html I think that perhaps the next most important module for me to create is a computer interface module. Please let me know what other things you would like to see on the page or created next. Also if you would like to contribute in some way, tell me that as well. Cheers! Les (Inventor)

4 5

Re: [chuck-users] Electronic ChucK
by inventor-66＠comcast.net 03 Oct '08

03 Oct '08

Peter, Yes, any kind of transducer would be an excellent addition to EChucK. I'm open to anything that is inexpensive and adds to the fun. I'm most excited about the notion of making music synthesis in all its forms accessible to us, and especially to kids. Breadboarding is inaccessible due to cost, complexity, and learning curve. Traditional synthesizers are inaccessible due to cost and size. Typical electronic experimenter's kits have the same problem as breadboarding, though they do make it fun with sensors and output devices. What is needed is something with a granularity that exists somewhere above component level and below system level, while still retaining the component level cost advantage. And how boring and useless would EChucK be without a diverse selection of sensors? I'd like to have or facilitate the building of rain detectors, wind sensors (weather sensors), EKG sensors to detect heartbeats, and Kassens' suggestions of excited resonators is perfect for EChucK. Well, perhaps my imagination runs amok, I've had only a few short naps these past two days so I'm a bit over tired. Oh, by the way, the EChucK web site is now up to 400 hits in less than 24 hours of existence. I sure hope this means some folks will collaborate, that would be great fun! And as Ge once said... "For those about to ChucK, we salute you!" Les (Inventor)

1 0

Re: [chuck-users] Is it possible to get mp3 output instead of wav?
by Manish Mittal 03 Oct '08

03 Oct '08

> Hi, My first post here. I stumbled on chuck this morning and have not > been able to take my hands off it.. its fun!! While going through the manual > I found chuck can write a Wav file to disk, can it also write an .mp3 file? > I searched through the chuck-users archives messages but found no direct > response. > > Also, I was curious if chuck can read in from a mp3 file. If not, are you > aware of a command line tool that can convert from mp3 to wav and then feed > into chuck (that's assuming wav files can be chucked). One of the reasons to > try something like above is to make my own karaoke files (20-30 of them), > but all my songs are mp3. I was planning to use chuck to do some frequency > filtering to achieve karaoke effect and then possibly add some computer > generated sounds to create a mix. > > Thanks for developing chuck .. pretty cool :-) > Manish >

3 2

Re: [chuck-users] Electronic ChucK
by inventor-66＠comcast.net 03 Oct '08

03 Oct '08

Wow. I posted to the ChucK forum about EChucK and some nice person copied the post, cited the origin, and put it on an RSS Feed for synthesizers. This quick little EChucK web page that I worked on all night has now gotten close to 300 hits! That's a lot more than my usual 20 hits a day for the whole music site. There hasn't been much response other than a lot of web hits, but google and my hit counter say they are mostly from unique users, so a lot of people are taking a look at EChucK. The web being what it is, I have heard and found myself that I only get about one email per 1,000 web hits so I'm not surprised nobody has emailed yet. In other good news, the poll I put on the announcement indicates that four people are willing to help out with the project. So it's been an exciting night. Note that the EChucK web page has been expanded and now has sub-pages with JPGs, design files, standards, projects, links and a FAQ. So have a look, the page again is here: http://www.freedomodds.com/music/echuck/ Keep on ChucKin'! Les (Inventor)

1 0

Re: [chuck-users] Electronic ChucK
by inventor-66＠comcast.net 02 Oct '08

02 Oct '08

Thanks for your posts, folks, you're making this fun! I have completed the Power board and the ADC microphone board and I will put them on my website for you to download. The CAD tool of choice is Eagle, which is freeware for making small boards for educational use. Eagle is cross-platform to Windows and Mac, not sure about Linux but it might be. As a professional I used these types of CAD programs for 20 years and I can say that Eagle is a good one and I am enjoying the learning process. Regarding Spencer's topic of digital communication of analog signals, PICs are great at PWM and I2C. You can get a PIC chip for a few dollars US that has PWM and I2C modules, oh, and ADC also. Quite frankly, the main cost problem is the connectors which go for about 50 cents US per node. The PIC boards would not be expensive. I'm putting down footprints for the connectors and saying they are optional. Poor man's solution is to solder the interconnect and cut his cost in half. Poor woman's solution is the same, lol. let's be politically correct. No, poor woman's solution is to get a man to do the soldering for her, they are smart that way, lol. But I digress. I see each PIC processor not only functioning as a UGen, but also as a class. It's an encapsulated module with a clearly defined I2C digital interface, so treat it like a class. Different PICs access each other's private variables across the I2C and they share analog signals by PWM. To convert PWM to analog for interfacing from a PIC audio to an analog audio signal, we just use a passive or active low-pass filter module. To connect the other way we use the ADC input of the PICs. Regarding Kassen's mention of a ChucK interface, we can simply use the line-in jack for stereo input and the headphone jack for stereo output. If you have a soundcard then you can use that. Digital I/O can be done along these same interfaces. So yes, ChucK plugs into your sproingy mass of UGens and PICs. Since there appears to be interest, and I presume someday possibly actual board fabrication, I will begin a web page dedicated to EChucK. As time permits, I will put together some fun and interesting stuff to explore on the page. Does anyone have any suggestions about how to organize the page? I figure a title page with links to many topic pages. Cheers and as Ge would say, "Rock On!" Les (Inventor)

1 0

Re: [chuck-users] Electronic ChucK
by inventor-66＠comcast.net 02 Oct '08

02 Oct '08

Kassen, Your point is well taken. I guess I'm not concerned about the audiophile quality of this system at all. If it's going to be so inexpensive then it will probably be inaccurate as well, and I'm OK with that. It's not intended to produce perfectly orchestrated audio, but rather to do something fun and interesting. Also, that 555 example was indeed for a variable frequency oscillator, more specifically a pulse position modulator from the data sheet. there is a CV input that stops the oscillator at ground and sets maximum frequency at Vcc. Though to get a 50% duty cycle one must add a flip-flop to the output. I'm really just going for a cool toy that will make lights blink and go woo-woo when I put together a ring of oscillators, this does not have to be super precise. That and the limited types of modulation input kind of make for a departure from ChucK, however. But that's OK too. It can simply be ChucK-inspired not ChucK duplicated. Les (Inventor)

6 5

Re: [chuck-users] Electronic ChucK
by inventor-66＠comcast.net 02 Oct '08

02 Oct '08

OK, regarding cost concerns, I have thought this out a little but have not done thorough cost estimation. A SqrOsc can be made with a 555 chip, four resistors and two caps plus two connectors. That's only about five dollars in parts, most of it in the dang connectors. Gain block? put four of them on a single board for not much more. A general purpose, PIC processor based unit would be about the same or maybe two dollars more. Remember, Arduino is a big chip with lots of support components, while the smaller of the PIC family cost $2 and are a total system on a chip. In fact, most of the cost is in the screw-type terminals so if we were to make the system be solderable with just vias (holes) for terminals, the cost per UGen goes down to just $2 on average. And with surface mount parts the board size for a UGen goes down to about the size of a postage stamp so you get *many* UGens on a full-size board. As to closely following ChucK, this is a good point. I imagine that if this catches on, other people will create all sorts of UGens that are not constrained by ChucK at all. I had originally envisioned it months ago as a free-form system in which you can build any module that works, and it was only this morning in the wee hours that I got the inspiration to model it after ChucK. So yeah, it will probably get way different from ChucK in practice if it ever happens. I don't know what direction to take it, but I tell you what. I'm working on it. I'm using Eagle CAD to draw up some basic initial UGens. I am completing the first one, which is a battery power module, and I'm not worrying about making it perfect or adding a wall-wart jack or anything like that. I figure the early modules will get abandoned over time so they are just to get *something* up and running to start with, and they will all get replaced anyway. One cool thing is that the modules are so simple that the freeware version of Eagle can be used to design and manufacture them. I'd like to begin establishing some standards that are not written in stone, but are recommended guidelines. Let's discuss these standards and I'll start a web page for all to read up on the whole thing. The standards are: 1. Use Eagle CAD 2. +5V single supply power 3. analog and digital signals swing from gnd to +5V 4. artificial ground is +2.5V That's all I have so far. I am happy to see the responses to my messages, this is getting to be fun (which is the whole idea)! Cheers! Les (Inventor)

2 1

Re: [chuck-users] Evaluating an argument as anything but a string
by Joel Matthys 02 Oct '08

02 Oct '08

Hi Andrew. There is a handy command in the Std library for doing exactly that, Std.atof. (That's short for ASCII to float.) float harm; string arg1; me.arg(0) => arg1; arg1 => Std.atof => harm; or you can shorten it to: me.arg(0) => Std.atof => harm; Hope this helps! Joel ----- Original Message ---- From: Andrew C. Smith <acsmith(a)willamette.edu> To: chuck-users(a)lists.cs.princeton.edu Sent: Wednesday, October 1, 2008 7:55:38 PM Subject: [chuck-users] Evaluating an argument as anything but a string Hey all, Long time listener, first time caller. I'm a little bit new to this, but I managed to write a program that uses LiSa to play a sample of a piano harmonic at a specified rate, putting it at a specified partial. Here's the deal: I want to just do chuck harmonic.ck:4 for the 4th partial, or chuck harmonic.ck:5 for the 5th, but it keeps telling me that my arguments are strings, not floats. Is there a way to do a string-float conversion, or just even to read a particular argument as a float? float harm; string arg1; me.arg(0) => arg1; ... arg1 => harm; is all I have relating to the arguments. Obviously, that doesn't work, as you can't ChucK a string to a float. There's probably a simple answer to this, isn't there? Andrew Smith _______________________________________________ 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] Electronic ChucK
by inventor-66＠comcast.net 02 Oct '08

02 Oct '08

Kassen, the reinvention notion is valid, but with a twist. The twist is a physical one. You see, I have not described it completely, now I'll try more. Instead of being mounted in a rack, each module is a little circuit board. Instead of having front panels, each module has PCB-mount thumbwheel pots and little bitty PCB-mount switches. Instead of banana jacks, each module has row-style screw terminal connectors. Instead of banana jack wire, each module is interconnected with solid wire stripped at the ends. One can then form structures, like kijjaz's thunder block diagram that we investigated on the forum. You just chain the modules together rather than "patch" them. Also geometric structures like a ring of oscillators will look physically like, um, a ring. One can construct a Bucky Ball out of filters and SinOscs just to see what it sounds like. It's kind of like making a flowchart or code diagram in which each block is an actual hardware module. So yes, it's a modular synth, but no it isn't quite the same beast. You would purchase a circuit board the size of a piece of notebook paper (81/2 x 11 inches) (A4 size) and then cut or twist off the 30 or 50 or so little bitty circuit boards that were on it. AlgoMantra, cool on the crickets notion. That stuff and much more is so possible with this approach. I see parents buying kids a kit consisting of all you need to get started, and then you can buy add-on boards for like ten bucks each as they are all super small and cheap. Or just buy multiple sheets of boards. They are all held together by solid wire so that they hold their physical form if you make a Christmas tree out of them, well, that's what you get. I plan to make initial boards with 555 timers and opamps and the like, linear you know, but eventually it will make sense to create a PIC-based general purpose board that can be programmed by a PC to be a SinOsc or a multiplier or a whatever thingie. To facilitate the language features of ChucK we could use a serial interface such as I2C or other PIC-supported interface and let the programs exchange information like shreds. I'm interested in discussing standards such as what voltage levels to use and whatnot, plus I'm starting to learn Eagle PCB CAD by making little circuit board designs, beginning with a power module. Whew, typed a lot - as you can see I find the idea exciting. I'm working on it now. DigiKey has the parts, and us - we got the smarts, haha! I'm calling it EChucK for now. Comments welcome as always. Les (Inventor)

4 3

Evaluating an argument as anything but a string
by Andrew C. Smith 02 Oct '08

02 Oct '08

Hey all, Long time listener, first time caller. I'm a little bit new to this, but I managed to write a program that uses LiSa to play a sample of a piano harmonic at a specified rate, putting it at a specified partial. Here's the deal: I want to just do chuck harmonic.ck:4 for the 4th partial, or chuck harmonic.ck:5 for the 5th, but it keeps telling me that my arguments are strings, not floats. Is there a way to do a string-float conversion, or just even to read a particular argument as a float? float harm; string arg1; me.arg(0) => arg1; ... arg1 => harm; is all I have relating to the arguments. Obviously, that doesn't work, as you can't ChucK a string to a float. There's probably a simple answer to this, isn't there? Andrew Smith

1 0

Electronic ChucK
by inventor-66＠comcast.net 01 Oct '08

01 Oct '08

Hi folks, I have this Idea and let me know if it's crazy as many of my ideas are, but I think it's a good one: electronic ChucK. The concept is to build little bitty circuit boards that each model a ChucK UGen. Naturally the more complex ones like the instruments are too complex to attempt initially, but the simple ones like gain, SqrOsc, LPF and the like can be easily constructed. Once these modules are available in physical form as little circuit boards, a user can hook them up just like a ChucK patch. Some of the programming aspects of ChucK can also be modeled with PIC processor modules. I envision using the miniature screw-terminals available for interconnect so that the electronic ChucKist can hook them up with wire. If solid wire is used, one could construct geometric structures that occupy physical space in three dimensions. There would be support modules such as a power module, a dac module, and some types of adc modules, plus LED modules, etc. I am interested in your opinion of the project as I believe that ChucKists work better as a group than individually. I would make the schematics and layout files available for free on the internet and also I would do production runs of the boards for people who wanted to just buy the thing instead of DIYing it. What are your thoughts? Les (Inventor)

3 3

Assigning to appended array locations (bug?)
by Kassen 29 Sep '08

29 Sep '08

Fellow ChucKists, I believe the code below demonstrates at least one bug that's keeping Mike from enjoying his spaghetti. There are definitely more related issues here but this is one. Appended non-primitive array locations can't be assigned to; clearly these are somehow different from array locations created when the array was created. Not creating a explicit "new" instance and instead appending a different instance directly also leads to reference issues, quite probably these are related. ================================= class Foo { int value; } Foo foo[8]; Foo bar; bar @=> foo[7]; foo << new Foo; <<<"all is fine so far", "">>>; Foo baz; <<<"everybody crash ChucK tonight", "">>>; baz @=> foo[8]; ================================ Yours, Kas.

3 5

upper-case class (bug)
by Kassen 28 Sep '08

28 Sep '08

Dear list, For today's bonus-bug; This is simply a syntax error; class foo; This on the other hand crashes outright; Class foo; This on the other hand gets picked up by the parser as there is no type "Bar" defined; Bar foo; Kinda trivial but still a crash. Kas.

2 2

Re: [chuck-users] Object reference weirdness
by Tiemen Meerman 28 Sep '08

28 Sep '08

In the meantime, what exactly is a bus error? What generally causes them? Bus errors can be caused by memory accesses that are misaligned: ie. a 32 bit read off of an odd memory address. Sounds like some pointer arithmetic going wrong somewhere in ChucK. -T

4 4

crash caused by definition order (bug)
by Kassen 25 Sep '08

25 Sep '08

Dear list, Consider the following; ============================== spork ~foo(); me.yield(); Gain dest; fun void foo() { Gain source => dest; } ================================== Note that this is incorrect, I should have defined "dest" before sporking foo but mistakes are made... This code crashes my Mini (compiled with the latest ChucK so non canonical) on Linux outright (the whole thing just disapears). Variations on this theme under the canonical Windows version gave a "nullpointer Ugen connection" error and just exited the shred. Sadly I didn't have the time to document that exact permutation under win yesterday due to stress about a deadline. The parser does correctly catch this; =============================== fun void foo() { Gain source => dest; } spork ~foo(); me.yield(); Gain dest; ========================== ..but on a functional level that's the same, the place where a function is defined doesn't (well, *shouldn't*) matter; I like to keep mine at the bottom of the file below classes unless it's a especially large function that's especially fundamental for the structure of the program. Yours, Kas.

1 0

Object reference weirdness
by mike clemow 25 Sep '08

25 Sep '08

I have an array of objects that I've created and I'm abstracting arrays of these objects as a class of its own right. While testing my code I've run into some weird snags. I would get bus errors when calling a print() function, which is supposed to just print to the screen the values of the object's members. I've been trying to track this down and then ran into a situation where I am instantiating a brand new object and changing it's member values (without adding it to the array). Whenever I change it's values, a certain object in my array changes with it--it's reference is identical to the new one I just created. This is like a warp in spacetime somewhere. My object is some quantum object that has a twin and is being changed instantaneously but at a distance. Schrodinger's cat is rolling over in its grave. (kidding). What is happening here? Is this a garbage collection issue? I will send my code (and instructions on running it) to anyone who wants to take a look, but I'm afraid of subjecting the entire list to my spaghetti... ;-) -mike -- http://semiotech.org http://semiotech.org/michael

2 3

STK shakers wrench rattling?
by Kassen 23 Sep '08

23 Sep '08

Hi, list! I'm having a bit of a problem with the wrench and guiro presets of Shakers; they won't rattle nicely. That is; they do for the first .noteOn() after the preset was set but after that the following noteOn's merely make them click. I tried all parameters in lots of permutations, I also tried to understand the source (which has lots of exceptions for these two) but it's beyond me and some of the comments look scary ;¬). I'm suspecting this isn't proper behaviour; sometimes messing with the .energy() parameter will get them to make some sort of noise but no nice rattles. Could somebody please comment on this? Yours, Kas.

2 9

int *=> dur (syntax inconsistency?)
by Kassen 22 Sep '08

22 Sep '08

Dear list, Consider; =================================== //definition second => dur foo; //this is fine 2.0 *=> foo; //this is not fine 2 *=> foo; ==================== The last line gives a error about not being able to resolve *=> on types int and dur. I wonder if this is correct behaviour; I can imagine many cases where a integer multiple of some duration is needed to avoid "trainwrecking" (a DJ term for two concurent tracks running at slightly different speeds). While we can obviously express integers as floats as well there may be cases where the int data-type can make guaranteeing we are dealing with a natural number easier, for example Std.rand2( ). while correct I don't think either alternative looks especially nice; Std.rand2(1,4) * 1.0 *=> foo; Std.rand2(1,4) $ float *=> foo; This does work in the comparable case of; //correct but not as ChucKian foo * 3 => foo; or even; 1.2 => float bar; //implicit casting in *=> does work here 3 *=> bar; So; I'd like to sugest a implicit casting of int to float or further overloading *=> in these cases. Yours, Kas.

1 0

Fun ChucK Game for Nerds Like Us
by inventor-66＠comcast.net 20 Sep '08

20 Sep '08

Memorandum To: All ChucKists From: Inventor Re: HSTechSpy ChucK Game Greetings fellow ChucKists. You will be pleased to learn that I have endeavored to create one more way to waste your time on ChucKian adventures. I have developed a new game (last year actually) and recently added a healthy dose of ChucK content to it. In the game you are a Hardware / Software Tech Spy and you receive various Mission Briefings which you may or may not chose to perform. So far the first five missions have been software only and primarily based on the Perl programming language, but now I have added a 6th mission which is hardware based and involves a little ChucKing around. Rather than blog on endlessly as I often do in forum and list posts, I'll just give you the link and invite to explore the page: http://www.freedomodds.com/hstechspy/ If you visit, be sure to scroll down and check out Mission 6: USB Hardware Interface, which is the latest and most interesting ChucK mission. HSTechSpy is fun, it's silly, it's educational, and it's a great way to waste some time so stop on by and give it a read. Forever creating useless ways to spend your time with ChucK, I welcome you to join me on the neverending journey to nowhere. Enjoy. Les (Inventor)

1 0

ChucK Humor (or the lack thereof)
by inventor-66＠comcast.net 20 Sep '08

20 Sep '08

How many ChucKists does it take to change a light bulb? Four. One to make a feature request, one to develop a custom light bulb interface that works great but is so complex that nobody else will ever use it, one to imagine a future in which ChucK can change it's own light bulbs, and one to hold the light bulb up while the world revolves around ChucK. How do you annoy a group of ChucKists? Ask them how to do file I/O in ChucK. Mention garbage collection just one more time... Joke about their excessive CPU consumption. Tell them that Csound is more powerful than ChucK. Ask them if ChucK can take advantage of multiple processors. If ChucK were an automobile, what kind of automobile would ChucK be? 1. A Corvette because it's built for performance but it's always in the shop. 2. A 1967 VW beetle because it's cute and everybody loves it. 3. A Corvair because it is "unsafe at any speed". Why did the ChucKist cross the road? 1. Because the other four ChucKists were busy changing a light bulb. 2. Because he was livecoding and wasn't paying attention to where he was going. 3. Because the CPU is always faster on the other side.

1 0