ChucK Bugs Reports and Requests
- 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)
- exiting main shred seg faults --confirmed on Mac OS X, 10.3.5 -- FIXED (version 188.8.131.52) shreds liberate children recursively when they are liberated!
- 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)
- killing a secondary chuck process on Mac OS X: zsh: bus error ./chuck ../examples/wurley.ck (or any other .ck)
- chuck uses a lot of CPU compared with, say, SuperCollider
- Weird one - not necessarily ChucKs fault. When sending ChucK shreds from within XEmacs to a running --loop, the sound playing depends on whether XEmacs retains focus or not. (platform: Win32)
- I think I have my MIDI setup wrong for ChucK (184.108.40.206, built on Gentoo Linux with "make linux-alsa")
znmeb@DreamSong examples $ chuck gomidi2.ck chuck: rawmidi.c:961: snd_rawmidi_drain: Assertion `rawmidi' failed. chuck: rawmidi.c:987: snd_rawmidi_read: Assertion `rawmidi' failed. Aborted znmeb@DreamSong examples $ chuck gomidi.ck chuck: rawmidi.c:961: snd_rawmidi_drain: Assertion `rawmidi' failed. chuck: rawmidi.c:987: snd_rawmidi_read: Assertion `rawmidi' failed. Aborted
email@example.com or post to the mailing list
- I have what might be a similar MIDI problem as znmeb, I'm using ChucK 220.127.116.11, also on Gentoo with ALSA. I get the following:
aldimond@localhost ~/sigmusic/chucktutorial $ chuck miditest.ck [chuck]: MidiIn: couldn't open MIDI port 0... [chuck]: ...(RtMidiIn::openPort: error starting MIDI input thread!) "Could not find MIDI device." : (string)
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 18.104.22.168. I'm sorry for not checking that before posting here. - Al
- This sample program causes a double-free crash when it returns: ChuckCrash
- It seems that dac is still dac instead of being "Dac". In fact "Dac" results in a error for being a "undefined variable" (Kas.)
- empty arrays crash chuck when attempting to access them associatively (e.g. int a; 0 => a["crash"];) (spencer)
- parenthetical expressions (e.g. ( 0, 1, 5 ) ) push a bunch 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)
- The VM is too stable. Please spice it up.
- Need a deterministic manner of crashing. How about machine.crash()? Thanks.