13 Jun
2005
13 Jun
'05
10:36 p.m.
You're right. On OSX the MidiShare interrupt source
can be derived
from the audio timing, so that the MidiShare time will not drift
form the audio time in case an application has special needs of Midi
+ audio synchronization. A timer only mode is also available.
well, see .. to me .. MIDI precedes AUDIO in priority, time or otherwise..
otherwise, what is a music event but a description of that event, executed?
This "audio timer mode" is not available of
other platforms where it
was difficult to get audio buffer size (like 64 frames) not "too far
form the 1 milliscond duration. On OSX with audio timer mode at 64
frames, the MidiShare interrupt handler is called every 1.45 ms with
a system that call the interrupt handler twice every n interrupt
(don't remember the precise value here...) so that is MidiShare time
remains correct.
from a purely musicians' standpoint, 1ms ought to be good enough for anybody.
;)
of course, i reserve the right to change my mind, authority or none.
An idea we had some years ago...
no reason it couldn't happen this year.
but even when MidiShare time is
synchronized with the audio time, a MIDI event still has a
time-stamp with this 1 interrupt time resolution. We would need a
more precise time-stamping to do sample level synchronization.
but, if MidiShare is the 'hidden API' behind a nice front-end, and
Audio+MIDI events are happening when they should, who cares?
don't ever forget, Stephane, you launched an API on the world.
--
;
Jay Vaughan