* parenthetical expressions (e.g. ( 0, 1, 5 ) ) push a the result of each subexpression onto the stack, even if there is no corresponding pop. E.g. ( 0, 1, 2 ) => int i; assigns 2 to i, but leaves 0 and 1 pushed on the stack. Perhaps expressions of this nature should not compile? (spencer)

* parenthetical expressions (e.g. ( 0, 1, 5 ) ) push a the result of each subexpression onto the stack, even if there is no corresponding pop. E.g. ( 0, 1, 2 ) => int i; assigns 2 to i, but leaves 0 and 1 pushed on the stack. Perhaps expressions of this nature should not compile? (spencer)

+

+

* "chuck --silent --loop" eats up your whole cpu doing nothing. This is logical in a way but has no actual use. Since chuck might be set up this way in order to wait from input from a user or another program it would make sense to give that user or program the cpu in order to do other thing, like make or edit the .ck files to be rendered/computed (Kas.)

== Want one? ==

== Want one? ==

* The VM is too stable. Please spice it up.

* The VM is too stable. Please spice it up.

* Need a deterministic manner of crashing. How about machine.crash()? Thanks.

* Need a deterministic manner of crashing. How about machine.crash()? Thanks.

Revision as of 00:07, 14 December 2006

Have one?

jahbini at romantictrances.com: sending script to chuck demon gets screwed up when waave files are needed: they may not be accessable to the existing chuck which may have been started by another user, or started in another directory or even running on some remote host. Sending the whole user directory environment seems overkill, but a suggestion here would be to use URL syntax for reading wave files so any remote chuck could fetch using libcurl or ssh) That would work for all of the above situations.

STK Flute controls are a bit confused. jetReflection and endReflection read as 0.0, even though the internal STK values are 0.5. noteOn and startBlowing controls are confusing -- one sets internal amplitude, rate; the other sets internal frequency, amplitude. startBlowing probably needs to set STK internal amplitude, as it does nothing unless a previous noteOn has been played. would be kinder and gentler if rate was in seconds instead of 1.0/sample_rate; but in either case, it seems to do nothing with either noteOn or startBlowing. (ok, ok. I'm off to go ask for access to source. :-/ ). stopBlowing rate units are also a bit odd. and vibrato controls aren't exposed. That basically boils down to an oddity with every control except frequency. :-(...

(gewang: we will look into this. STK ugen will be updated for easier chucking in 1.2)

starting a secondary chuck process on Mac OS X: [chuck]: cannot bind to udp port 8888... sound plays anyway(gewang: this is correct behavior - there should be not need for the second chuck if you use chuck + foo.ck which will play sound in the first instance of chuck, with synchronized timing) (jahbini AT romantictrances.com: Yes. This is current behavior, but not documented and is it the best choice? Should chuck be chuck aware? ie. look up in "chuck.pid" file in conventional place and or just attempt connection to a previously running chuck)

The "Could not find MIDI device" is from my .ck file. I might have a look through the source code but I've never done any ALSA or any other audio system programming before so I'm not sure I'll be able to figure it out. My e-mail is businessmanprogrammersteve - at - gmail.com.

Turns out the above bug was fixed in ChucK 1.2.0.4. I'm sorry for not checking that before posting here. - Al

This sample program causes a double-free crash when it returns: ChuckCrash

parenthetical expressions (e.g. ( 0, 1, 5 ) ) push a the result of each subexpression onto the stack, even if there is no corresponding pop. E.g. ( 0, 1, 2 ) => int i; assigns 2 to i, but leaves 0 and 1 pushed on the stack. Perhaps expressions of this nature should not compile? (spencer)

"chuck --silent --loop" eats up your whole cpu doing nothing. This is logical in a way but has no actual use. Since chuck might be set up this way in order to wait from input from a user or another program it would make sense to give that user or program the cpu in order to do other thing, like make or edit the .ck files to be rendered/computed (Kas.)

Want one?

The VM is too stable. Please spice it up.

Need a deterministic manner of crashing. How about machine.crash()? Thanks.