2009/8/22 Kassen :

Almost; I've been writing a fair amount of Scheme lately, that's where the

Well, as a long-time Schemer (and very occasional ChucK recreator), I find ChucK to be a very unfriendly programming environment. I'm curious if there's source code available. I'd like to hack on it. My apologies if I've just been blind while browsing the various bits of the ChucK web sites. david rush -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt

David;

Well, as a long-time Schemer (and very occasional ChucK recreator), I find ChucK to be a very unfriendly programming environment.

Really? Well, it's supposed to be friendly and welcoming so something is wrong there. My tips would be; *Download and read Ge's doctoral thesis. More so than the manual it explains the underlying concepts and reasoning, the "why of ChucK", if you wish. IMHO this is a undervalued document for understanding ChucK; http://ccrma.stanford.edu/~ge/thesis.html *List what you feel is wrong on the list for debate and potential fixes or perhaps explanations on why these things might make sense after all; I don't know and I can't help if you don't explain what issues you have. *Have a look at Supercollider, some people who feel ChucK is unfriendly feel right at home there (and the other way around, of course). I wish I knew how that worked. I suspect it has to do with how people reason and so far nothing seems to help as much as simply helping people pick the platorm that will make them happy. Of course it should also be said that ChucK uses some odd/new ideas that may only properly sink in after having used them for a while; I'm not sure how much ChucK you already wrote.

I'm curious if there's source code available. I'd like to hack on it. My apologies if I've just been blind while browsing the various bits of the ChucK web sites.

Yes, absolutely. You can simply grab the source, read it and edit it to your heart's content. Under some conditions you can release the result. The license comes with it. Click here; http://chuck.cs.princeton.edu/release/,note the source is the same for all platforms, and get that. You will need a C++ compiler, some related tools and a few libraries. Then again, if you dislike ChucK and come from a Scheme background C++ may not be your idea of fun. I'm not sure anybody thinks C++ is great fun. Best of luck whatever road you take; I'd be happy to help where I can but that will mostly be ChucK stuff as that's my main expertise, programming-wise. Yours, Kas.

David; Hang on. I imagine that it's very friendly to someone who is not a

working programmer :)

Yeah, I can see that. :-)

And I will also stipulate that some of my problem may be with the documentation, but seriously how can a language where I can't allocate an array who size is only known at run-time be called friendly?

Well, you can define a length zero array, then do lots of generative stuff while growing it by appending to it. Sadly that is not in the manual, you are right about that. It's just in the VERSIONS file and the examples directory.

Having said that, I do rather like ChucK. It just feels about half-finished.

Absolutely, that's because it is. :-)

Will do. And thanks for the tip.

Cool! :-) Well the second most obvious one is having to list all the files

needed on the command line :)

Well, files can call files but I think you mean dependencies. we need those, Ge mentioned plans for those, I'm not sure how far along those are.

Strict file scope for variables, but not for classes is another annoyance. No object constructors feels dangerous, especially in light of a deeply inherited class hierarchy.

Yup, the whole class thing is basically a place-holder to get by until a more serious system is in place. We also need a more convenient way of having global objects.

All of which are not really show-stoppers. But the array thing has me generating code in Scheme to run under ChucK.

That's quite interesting. I'd like to know how that works. I also think it would be useful to outline how you would like things to be. We have a shortage of development time here but I think one of the most important things we also need is ideas on extending everything in a way that stays coherent. I see a big role for that on the list. Those aren't wholy my ideas, BTW, that's just a re-phrasing of the invitations scattered through the docs.

I actually find most of ChucK's innovations (the timing constructs and shreds) to be fairly nice. It's the stuff around the edges which makes me nuts.

Oh, yes,some bits are infuriating.... The workarounds for public objects, the issues around the edges of the type system, etc. I agree. These are known issues, I don't think anyone likes them.

...

license comes with it. Click here; http://chuck.cs.princeton.edu/release/

Brill!

If you are planning serious work on some part it might be good to communicate on the dev-list to avoid clashing fixes. Some people might already be working on aspects of arrays as there has been a series of bugs involving arrays loosing track of object types, for example.

...

dislike ChucK and come from a Scheme background C++ may not be your idea of fun. I'm not sure anybody thinks C++ is great fun.

I don;t. But I've been getting paid for it for 20+ years (ick! ick! ick!). I feel competent to deal with nearly anything in C++.

Ah, ok, I didn't know. I thought you might have a allergy to curly braces, like some people seem to have. I'm sorry, it's hard to address relative strangers on these matters when you don't know their background. I noticed that despie your competence you still didn't refer to "fun" ;-)

I'm not planning to chuck out the baby just yet :)

Yay! Yours, kas.

I was referring to the musical style. I think the recursion is very good in this case. I don't understand this cast to UGens not defined 1.0 / n => (bar $ Phasor).phase; (n%3) + 1 => (bar $ PulseOsc).sync; (75 * (n-1)) + 1 => bar.gain; (5 * n) => (bar $ Shakers).freq; cheers Lucas 2009/8/21 Kassen :

Lucas;

...

A bit irritant but nice :-)D some SuperCollider style here.

Almost; I've been writing a fair amount of Scheme lately, that's where the recursion comes from. I do think SC sometimes uses arrays like that... it's viable in ChucK for quick hacks but I can't yet get ChucK to loop over them, at least not without getting extremely silly, unreadable and leaky.

In Scheme I'm how having the opposite, my natural inclination is to use a lot of "define" where in a lot of places a "Lambda" would do.

Oh, well... :-)

Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

2009/8/22 Lucas Samaruga

I was referring to the musical style.

That's interesting. I've been wondering how syntax might affect music. Why can I often recognise MAX by ear, for example? I don't know...

I think the recursion is very good in this case.

Yeah, and it even works nicely. The technique is viable, at least... Though of course GC would help a lot here for serious work.

I don't understand this cast to UGens not defined

1.0 / n => (bar $ Phasor).phase; (n%3) + 1 => (bar $ PulseOsc).sync; (75 * (n-1)) + 1 => bar.gain; (5 * n) => (bar $ Shakers).freq;

Deliberate perversity. I needed to cast to UGens of a type that had the member-function in question as UGen itself doesn't. We are fooling the type-system here, the only thing that really matters is the name of the member function. This, BTW, is why it's "playing with fire", we lose the protection of the type-system and so one typo in the name of the member function would mean a machine crash. I would advocate that the type system hierarchy here would be more like with the STK instruments, going; Object, UGen, Osc, (TriOsc/SqrOsc/SawOsc/PulseOsc/Phasor) All of those plain oscs have the same member functions and indeed behind the scenes I think they inherit (with Phasor being the core one). I don't think there is a real need for ChucK requiring this cast here. It would be more convenient (and potentially safe) to have a base-class, like the STK instruments can be used interchangably with regard to NoteOn() and .freq(). Basically we *do* have a lot of the "duck typing" that some have requested, you just need to be absolutely sure you do know it's a duck (or at least a goose) or there will be crashes. Ge did mention "chucking excptions" as a wishlist item, but I'm not sure to what degree that is a word-pun on "throwing" or whether it is a serious plan. Fortunately there is nothing wrong with word-puns inspiring features.... Kas.