> shouldn't portmidi process messages in the order of their timestamps, not > the order in which they were sent? >
ah, i found the documentation in portmidi.h: Do not expect PortMidi to sort data according to timestamps -- messages should be sent in the correct order, and timestamps MUST be non-decreasing. evan's recent thread about merging midi streams touches on this issue: http://www.mail-archive.com/media_api@create.ucsb.edu/msg00188.html i don't get why portmidi doesn't handle the sorting -- if it's going to have timestamps, why not allow nonmonotonic usage? i agree with evan that it doesn't make sense for every app to reimplement sorting. if the app has to buffer messages until the last moment (in case a message with an earlier timestamp comes along), then it has to essentially operate in realtime mode (latency=0) and can't take advantage of any latency optimizations in the driver/hardware. roger says "Merging MIDI streams with timestamps is a difficult problem, at least from an API point of view." but i don't get why? somewhere there is obviously a queue where future events are buffered, and it should be possible to insert events that arrive later, but with earlier timestamps, into the right locations. if the events arrive too late (their timestamp would have already been dequeued), just send them immediately, just as events with timestamps in the past are currently handled. is the problem that a minority of platform-specific drivers that portmidi calls don't allow one to rearrange their queue? in that case, i would advocate 1) a merging Pm_Write that reverts to the current behavior if the underlying driver in use doesn't support merging (perhaps raising a warning if it detects nonmonotonic timestamps), and 2) an option to keep the queue inside portmidi, guaranteeing that merging will work, but sacrificing native driver optimizations. am i missing any negative consequences of such a design? is there a searchable archive of the portmidi mailing list? > ah, i found http://www.mail-archive.com/media_api@create.ucsb.edu/ tho the searching seems to miss matching posts... -e
_______________________________________________ media_api mailing list media_api@create.ucsb.edu http://lists.create.ucsb.edu/mailman/listinfo/media_api
