[gmpi] Re: Topic 6: Time representation
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 1 May 2003 12:49:41 -0700 (PDT)
> The plug 'registers' to receive them. Plugins that don't care aren't
> bothered. Plugins that care get the information.
> <<<
>
> This puts a pretty heavy burden on the host, needing to manage which event
Not really - certainly less than sending every event to every plugin.
Minimal: one list of each class of event (tick, beat, bar, ?). Plugins
that register get put on the list. Every beat, scan the beat list and send
a beat event.
More usefully, add a scalar, so I can ask for every 5th beat.
> ignore what it doesn't care about. The overhead of skipping these
> low-density kinds of events is going to be tiny compared to cycles spent on
But these events need to be allocated from somewhere and enqueued and
dequeued, etc. This is potentially a lot of events (assume 100 ticks per
beat min x every plugin). I think the overhead of deciding who gets what
and when is very minimal.
There is another issue that has come to mind: If the musical timeline stops
with the transport (i.e. no beat/bar/etc events), plugins still need to
track this stuff for things in tempo-sync - which could induce drift.
Perhaps musical events need to be delivered when the transport is stopped,
too. Musical time does still continue, just every bar is bar0 or something
:)
Tim
----------------------------------------------------------------------
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:
