On 14 Aug 2009, at 14:23, Kassen wrote:
There seems to be a timing problem with <<< ... >>> in ChucK. So take all that away in all time critical positions, and see if the problem goes away. And report back here, if it does.
I think the main issue is that printing isn't done by the VM itself and that printing to the screen is expensive, CPU-wise.
I have been searching the sources a bit, and it seems that the engine has to do a lot of interpretation to get the stuff printed out. Searching for "<<<" gives chuck.y: | L_HACK expression R_HACK { $$ = new_exp_from_hack( $2, EM_lineNum ); } Then "new_exp_from_hack" is defined in chuck_absyn.cpp: a_Exp new_exp_from_hack( a_Exp exp, int pos ) { a_Exp a = (a_Exp)checked_malloc( sizeof( struct a_Exp_ ) ); a->s_type = ae_exp_primary; a->s_meta = ae_meta_value; a->primary.s_type = ae_primary_hack; a->primary.exp = exp; a->primary.linepos = pos; a->linepos = pos; a->primary.self = a; return a; } Then ae_primary_hack is used in chuck_emit.cpp, where the case calls emit_engine_emit_exp(), which seems to be a function that unwinds the closure that the expression points to. Continue the chase if you so like - it would be fun to know where it is printed. So it seems a lot of stuff has to be done in real-time interpreting. Probably has nothing to do with buffering to the computer, which are so fast nowadays. It would explain other timing problems, like with audio-files. Hans