[gmpi] Re: Topic 6: Time representation
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 16 May 2003 19:51:04 -0400
>I'd like to chime in and add my support for what Chris just said.
>Removing the ability to mark times in the future would be short sighted,
>in my opinion, especially when dealing with music time.
nobody has said anything about not being able to mark times in the
future. the question is who queues the event and who delivers it and
when is it delivered.
issues relating to transport control are prime examples of things
where is the potential for "persistent state" that can be represented
as a series of long-lived events. think of looped playback, for
example. the loop points have to "registered" in advance, and they
cannot be usefully handled by all potential plugins if they are only
delivered in the relevant timeslice - disk seeking will kill
performance.
so there certainly needs to be some way queue up certain kinds of
"persistent" events and let plugins know about them. but i see this as
entirely different from the basic model in which plugins receive
events for the timeslice they are about to process.
its so different that the "advance delivery" system by itself is not
enough to make it work: transport looping requires a 2 way handshake
between plugins to ensure that its robust.
----------------------------------------------------------------------
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:
