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

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 01 Oct '08

01 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 01 Oct '08

01 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 01 Oct '08

01 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 28 Sep '08

28 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