ChucK Bugs Reports and Requests
[chuckles] (at v. 22.214.171.124): do HalfRect and/or FullRect exist yet? -- later: answered my own question. At least FullRect exists and appears to work.
- array/genX issue (from dan)
- Antimon (Mac OS X, ChucK 126.96.36.199):
Hailstone:~/Documents/workspace/ChucK_stuff stefanblixt$ cat bugtest.ck <<< "Fred is", int fred >>>; Hailstone:~/Documents/workspace/ChucK_stuff stefanblixt$ chuck bugtest.ck chuck_type.cpp:2415: failed assertion `value != NULL' Abort trap Hailstone:~/Documents/workspace/ChucK_stuff stefanblixt$
Don't know if the variable declaration should be accepted or trigger an error message. Shouldn't trigger the assert though.
- 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
- 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 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.)
- The folowing two lines (in this order) will crash ChucK;
1.3 => test; float test;
Trying to send a MIDI message using a message and port that get defined below the send statement will crash as well. Both compile fine and without warning. (Kas.)
- Refering to a location in a array of undefined size seems to give a "bus error" instead of a complaint when compiling or a array out of range error.Details on the forum.
- Wurley and Rhodey don't react properly to 1 => my_piano.noteOff; and instead get "stuck" droning. 0=>my_piano.moteOn; does stop the note (if very quickly) (Kas.)
- SndBuf.interp(0) seems to yield to the same results a SndBuf.interp(2) (eduard)
- It seems as if chuck is comparing the type of the first index with the user-defined type of the array. If they differ, one gets an error like:
"array[...] contains incompatible types"
[1, 2., 3, 4.] => float array; // this crashes. Note that 1 and 3 are integers
[1., 2, 3, 4] => int array; // also crashes. Note first index is a float but array is defined as int.
[1., 2., 3, 4.] => float array; // this doesn't crash. Note 3 is still an integer
- Assigining window to ifft seems to yield "poorer" results than not assigning it. Try it in /examples/win.ck and you'll notice a rougher (faster beating) sound. (eduard)
Actually it works find. The problem in the example is that window_size is half fft_size and should be the same size(eduard)
- The VM is too stable. Please spice it up.
Um, maybe for you. I like its stability thank you very much.
- Need a deterministic manner of crashing. How about machine.crash()? Thanks.
The manual for 22.214.171.124 says this can be done. Haven't tried it out actually myself.