[gmpi] Re: Topic 6: Time representation

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 29 Apr 2003 15:21:02 -0400

>> event. You end up with MIDI processors that look a lot more like audio
>> processors, with a synchronous render-callback. Genuine question to
>MIDI
>> developers: on current CPUs, is this a Really Bad Thing?

 [ ... ]

>event back. The code to keep track of a list of one or more events and
>then put them in the stream at the right time is clearly a hell of a lot
>more work, and it would seem more logical to have the host doing that in
>the first place [ ... ]

this argument applies to audio just as much as it does midi. what's
good the goose, so to speak, should be good for the gander. 

i personally don't favor any system that allows queuing data (midi,
audio, whatever) ahead of time. its true that putting queue management
in the host is simpler than putting it in the plugins, but its also
requiring the host to do a bunch of a work that there is no strict
reason to do if the plugins all behaved as synchronous rendering
engines. 

i think that the question of whether or not GMPI will allow queueing
is a fairly important design issue. its not directly related to time
representation, but is obviously connected to it in that if we do
allow queueing, the metrics for time have to be defined.

to answer angus' question, though: writing a synchronous rendering
callback for a non-streaming data type like MIDI is quite a bit harder
than for a streaming example like audio or video. with audio, you just
fill a buffer of the right size, and you're done. with MIDI, there is
no "right size buffer", and each semantic data unit you want to send
(noteon, noteoff, etc) has a timestamp associated with it that may be
hard to implement depending on how MIDI I/O is supported. when you get
right down to the low level details, you've got to contend with system
timer resolution, system scheduling resolution, MIDI h/w FIFO size,
etc. etc.

--p

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: