[gmpi] Re: Topic 6: Time representation
- From: RonKuper@xxxxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 1 May 2003 16:07:35 -0400
>>>
> 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.
<<<
I do develop hosts for a living, so I don't complain about burdens
lightly.<g> Anyway, I'm not talking about performance burden, I'm talking
about code compexity. I'd much rather have a code path that steamrollers
all events together and send them out, without having to decide event by
event, plugin by plugin, "is this event type subscribed to by this plugin?"
>>>
Every beat, scan the beat list and send a beat event.
<<<
You assume that our streaming engine care about beat boundaries. It doesn't
really, so we don't know when "every beat" arises. Our timeline is ever
increasing sample count and MIDI tick count. Conversions to measures and
beats is a UI conversion. The fundamental internal storage unit is tick,
musical time.
>>>
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.
<<<
The allocation and queueing will still happen even with a filtering
mechanism. You would build the set of events to stream first, and then
filter them out when you deliver to different plugins in your system. This
is overhead for building different filtered lists, one for each plugin. Or
else its overhead for building new different lists, one for each plugin. In
either case its overhead.
Better is to allocate and queue once, and pass the same "packet" to
everyone.
----------------------------------------------------------------------
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:
