Difference between revisions of "ChucK/Bugs/Reports"

From CSWiki
Jump to: navigation, search
(Have one?)
(Have one?)
Line 4: Line 4:
  
 
== Have one? ==
 
== Have one? ==
 +
* [[OSC send and receive issues]] (from Jascha)
 
* Current CVS code as of 5/7/2008 does not compile on Linux with either the linux-alsa or linux-oss targets. (from Andrew Schran)
 
* Current CVS code as of 5/7/2008 does not compile on Linux with either the linux-alsa or linux-oss targets. (from Andrew Schran)
 
Error is:
 
Error is:

Revision as of 17:35, 20 February 2009

ChucK Bugs Reports and Requests

[chuckles] (at v. 1.2.0.8): do HalfRect and/or FullRect exist yet? -- later: answered my own question. At least FullRect exists and appears to work.

Have one?

  • OSC send and receive issues (from Jascha)
  • Current CVS code as of 5/7/2008 does not compile on Linux with either the linux-alsa or linux-oss targets. (from Andrew Schran)

Error is:

chuck_lang.o: In function `HidIn_cget_tiltPollRate':
chuck_lang.cpp:(.text+0x1008): undefined reference to `TiltSensor_getPollRate()'
chuck_lang.o: In function `HidIn_ctrl_tiltPollRate':
chuck_lang.cpp:(.text+0x10d6): undefined reference to `TiltSensor_setPollRate(long)'
            class ChannelPoint { ... }

            ChannelPoint points[4];

            if (false) {
                // this statement causes a memory corruption
                points[i].set_distance(dx, dy, dz, hyp);
            
            } else {
                // my work around simply embeds the member function here
                (hyp - points[i].distance(dx, dy, dz)) / hyp => float d;
                Math.min(1.0, Math.max(0, d)) => d;
                points[i].Set(d);
            }
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)

  • 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 (1.1.5.5, 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
 znmeb@cesmail.net or post to the mailing list


  • 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.)


  • 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.


  • 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"

Example:

[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)

  • Declaring/initalizing global variables after the main loop results in undefined behaviour. Maybe it should result in a compiler error?
while (true) { 
   misterFunction(); 
   1::second => now; 
} 
8 => int variable; 
fun void misterFunction() { 
   <<< "Today, my variable is ", variable >>>; 
}

chuck test2.ck 
Today, my variable is  0 
Today, my variable is  0 
  • Frostburn ( chuck version: 1.2.1.1b (dracula) exe target: linux (jack) )

Cannot read the value of .width or .sfreq of PulseOsc or SqrOsc.

PulseOsc p;
<<<p.width()>>>;
<<<p.sfreq()>>>;

Output:
[temp.ck]:line(2): arguments type(s) do not match:
[temp.ck]:line(2): ... for function 'PulseOsc.width(...)' ...
[temp.ck]:line(2): ...(please check the argument types)
  • Frostburn

Most of the oscillators cannot handle sync modes well

//Bugs with phase sync
//chuck version: 1.2.1.1b (dracula)
//exe target: linux (jack)
//Found by: Pyry Pakkanen (Frostburn)


//Step m => SinOsc c => blackhole; //Works fine
//Step m => Phasor c => blackhole; //Works as probably intended ie. The value of the carrier is the same as the modulator's
Step m => TriOsc c => blackhole; //BUG: Goes out of the [-1.0,1.0] range.
//Step m => SawOsc c => blackhole; //BUG: Gets stuck on 0.0 at positive phases and crosses bellow -1.0 with negative phases.
//Step m => SqrOsc c => blackhole; //BUG: Gets stuck on -1.0 with positive phases and 1.0 with negative phases.
//Step m => PulseOsc c => blackhole; //BUG: Same as above


0 => c.freq;
1 => c.sync; //sync mode 2 is bugged too!

<<<"Should not cross -1.0 or 1.0">>>;
0.0 => float tmp;
for(0 => int i; i < 30; i++){
    tmp => m.next;
    0.1 +=> tmp;
    samp => now;
    <<<c.last()>>>;
    if(Std.fabs(c.last()) > 1.0) <<<"Oscillator out of range! At phase:",tmp>>>;
    }

<<<"Negative phases">>>;
0.0 => tmp;
for(0 => int i; i < 30; i++){
    tmp => m.next;
    0.1 -=> tmp;
    samp => now;
    <<<c.last()>>>;
    if(Std.fabs(c.last()) > 1.0) <<<"Oscillator out of range! At phase:",tmp>>>;
    }
  • Gen17 when driven by a SinOsc only uses the absolute value of the input. This goes against what chebyshev distortion synthesis should be ie. making a sum of sinusoid partials out of a sinusoid input. Now it's horribly distorted.
  • Where does FFT store the results of a .transform( float[] ) call? It's not in the .spectrum( complex[] ).
FFT fft;
8 => fft.size;
float samples[fft.size()];
complex s[fft.size()/2];
for(0 => int i; i < samples.cap(); i++) Std.rand2f(-1.0,1.0) => samples[i]; //make some noise
fft.transform( samples );
fft.spectrum( s );
<<<"Noise spectrum using fft.transform",":">>>;
for(0 => int i; i < s.cap(); i++) <<<s[i]>>>;

//Make some noise by pulling samples:
Noise n => fft => blackhole;
fft.size()::samp => now;
fft.upchuck();
fft.spectrum( s );
<<<"Noise spectrum using fft.upchuck",":">>>;
for(0 => int i; i < s.cap(); i++) <<<s[i]>>>;

//output:
//Noise spectrum using fft.transform : 
//#(0.0000,0.0000) :(complex)
//#(0.0000,0.0000) :(complex)
//#(0.0000,0.0000) :(complex)
//#(0.0000,0.0000) :(complex)
//Noise spectrum using fft.upchuck : 
//#(-0.3233,-0.1557) :(complex)
//#(0.1657,-0.0947) :(complex)
//#(0.0922,0.2100) :(complex)
//#(0.0926,0.0465) :(complex)
  • Antimon - being evil to ChucK again
Hailstone:~/Documents/workspace/ChucK_stuff stefanblixt$ cat test.ck 
class TestClass {
        fun void method() {
                while(true) {
                        1::second => now;
                }
        }
}

spork ~ (TestClass testClass).method();
Hailstone:~/Documents/workspace/ChucK_stuff stefanblixt$ chuck test.ck
chuck_type.cpp:2690: failed assertion `value != NULL'
Abort trap
Hailstone:~/Documents/workspace/ChucK_stuff stefanblixt$ chuck --version

chuck version: 1.2.1.1b (dracula)
   exe target: mac os x : universal binary
   http://chuck.cs.princeton.edu/
  • int a[10], b[10], c[10]; 0 => b[0]; /* yields: "can't chuck an int to an int[]!" */

Fixed

This is what I know from memory is fixed, there may be more? I didn't touch the ones I didn't understand or was otherwise unsure about(kas)

  • 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.)
  • The folowing two lines (in this order) will crash ChucK;

1.3 => test[3]; float test[6];

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.)

  • empty arrays crash chuck when attempting to access them associatively (e.g. int a[]; 0 => a["crash"];) (spencer)
  • I have what might be a similar MIDI problem as znmeb, I'm using ChucK 1.2.0.0, 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 1.2.0.4. I'm sorry for not checking that before posting here. - Al
  • exiting main shred seg faults --confirmed on Mac OS X, 10.3.5 -- FIXED (version 1.1.5.3) shreds liberate children recursively when they are liberated!

Want one?

  • 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 1.2.0.8 says this can be done. Haven't tried it out actually myself.