Re:
>By the way, have you noticed that all these timings have a precision of 
>around 16ms?
>
>Andres.

Squeak's Time millisecondClockValue primitive is typically implemented
using a convenient OS time function such as the ANSI C "clock()"
function. On the Mac, this function uses a hardware clock  originally
based on the vertical retrace of the display, with a resolution
of 1/60th of a second. I recently made the Mac VM use a higher resolution
timer, allowing accuracy down to the millisecond. (This will be
be in the Squeak 2.0 release.)

I'm hoping that Ian and Andreas can find similar higher-resolution
clock functions to use in the Unix and Win32 VM's. (Andreas: Note
that windows has a high res clock called something like Timer.time(),
documented in the Multimedia API's.) However, not all platforms
will support high resolution clocks, or the overhead of using a
high resolution clock may be high enough to degrade Squeak's
performance unacceptably. Historically, Smalltalk's millisecond
clock has had only 1/60th second accuracy.

My big motivation for trying this is in anticipation of Stephen
Pope's MIDI primitives. I'd love to be able to support real-time
MIDI music applications with all the event scheduling implemented
in Squeak. The Squeak garbage collector pauses are sufficiently
short on a fast machine to contemplate doing this (under 10 milliseconds
on a 110 MHz PowerPC and under 3 milliseconds on the new G3 Macs).
Stephen's MIDI performance benchmark is a drum roll that starts at
ten drum hits per second and smoothly accelerates to twenty hits
per second. (Stephen: correct me if I'm wrong.) I believe that
if the occaisional hit is 3 milliseconds late--or even 10 milliseconds
late--due to a GC pause that this will still sound smooth, although
I know the ear is quite sensitive to small deviations in timing).
If 3-10 milliseconds isn't good enough, the GC pause time can be
tuned downwards (at the cost of more frequent GC's).

	-- John