John M McIntosh wrote:
> The VM's attempt to provide 1 or 2 millisecond timing for servicing 
> Delays.  I believe the windows VM offered 1 millisecond timing for 
> awhile now.
> The macintosh carbon and I guess the Unix Vm offer timing resolution 
> historically in about a 2 or 3 ms window, but I see the code to do 
> that has been
> changed now to target a  1 ms window via the interpreter's setting of 
> interruptChecksEveryNms, we did this 2004 I'd guess.
>
> You could consider creating a set of Delays to fire in the future, 
> have some task responsible for doing this based on the timing that you 
> require, or you setup up
> a delay to service the next task at the end of each task completion, 
> and by tracking the latency (if any) you could ensure your code will 
> run within a 1ms window.
>
> Internally the VM attempts to check every millisecond for pending 
> delays, or when not busy, sleeps until the next interrupt is required 
> to be fired (or of course wakes up when an signal, or UI interrupt is 
> needed to be serviced).

Thank you, John. I'll investigate this approach. I like the idea of 
setting up a new Delay at every cycle.

Is it better than forking an osProcess?

Here is how I was doing this:

start
    running ifFalse: [ running _ true.].
    oldTime _ Time millisecondClockValue.
   
    [self doProcess] fork.



doProcess
       
        [running] whileTrue: [
        (Delay forMilliseconds: 1) wait.
        morphs do: [ :morph | morph advanceSecs:
            Time millisecondClockValue - oldTime.
            oldTime _ Time millisecondClockValue.]
        ].


>
> On Jan 28, 2007, at 11:13 AM, Cesare Marilungo wrote:
>
>> Stéphane Rollandin wrote:
>>> hello list,
>>>
>>> a new development snapshot of muO is available:
>>> http://www.zogotounga.net/comp/squeak/sqgeo.htm
>>>
>>> it can be installed in a 3.8 or 3.9 image (use fresh images for safety
>>> and convenience)
>>>
>>> muO is an experimental environment for musical composition
>>>
>>>
>>> Stef
>>>
>>>
>>>
>>>
>> Hi Stef,
>>
>> I've installed muO and started studying the documentation. It looks 
>> really interesting.
>>
>> I was working on a music project in squeak, too.
>>
>> I wrote some morphs to represent notes and envelopes and wanted to 
>> send events via OSC in realtime.
>>
>> But I'm stuck since I haven't found how to keep precise timing (with 
>> a decent resolution). My first prototypes used the Morph 'tick' 
>> method, but this was unacceptable for obvious reasons. Lately I've 
>> been experimenting with forking an osProcess, but I was wandering if 
>> there's a cleaner/better method.
>>
>> Can you provide me with some hints, or point me to the proper 
>> documentation where I can found some explanation about how to achieve 
>> this?
>>
>> Thanks in advance, and keep up with the good work.
>>
>> c.
>>
>> --http://www.cesaremarilungo.com
>>
>>
>
> -- 
> =========================================================================== 
>
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =========================================================================== 
>
>
>
>
>
>


-- 
http://www.cesaremarilungo.com