>> 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