[gmpi] Re: Topic 6: Time representation
- From: "Silver Blade" <lists@xxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 2 May 2003 11:37:06 +0100
Just to skip back to the start (as I like to do, since reading others posts
and thinking up some of my own ideas requires me to start with a blank
message so I can put my thoughts down)...
There seems to be 3 types of plugin processing we need:
1) Realtime - processes sound/music events as they happen
2) Non-realtime - for processing sound using methods which might take too
much CPU time? (im not sure as I'm not experienced with these.)
3) Look-ahead/Future - for processing events that are about to happen
It seems that the 3rd type is dismissed because it's impractical (you can't
see into the future.) However, for a pre-defined series of events, such as
events placed on a timeline, it looks possible.
The difficulty comes when an expected event suddenly disappears (user
deletes/moves a part) or when events suddenly appear (user creates/copies a
part.)
For example, say you had a schedule of meetings for work. You know what time
they're *supposed* to be happening - but you can't guarantee that everything
will go according to plan. If a meeting is cancelled or re-scheduled before
you've started getting ready for it, you don't need to go to the meeting.
But if the meeting is cancelled while you're making your way there in your
car, you'll need to turn round and go back - you can't just prevent yourself
making your way there *after* you've started your journey. Also, a new
meeting might need to be scheduled between others. If you can make it, you
do. But if you can't, it has to be cancelled.
It might not be the best way of explaining, but it illustrates my point that
plugins should not *predict* the future, but they should be able to see the
"plan" and try to stick to it, and be able to adapt to any changes in the
plan.
Secondly, I have an idea to improve the speed of searching for events on a
timeline (although this is probably a job the host should do):
Events could probably be timestamped with the tick they occur at, which is
fine in principle, but it could be a long process to find events if they're
not in order, or to sort the events into the correct order.
To make things more efficient, I implement a second event list, which stores
segments of events. In the case of my program, the segments are similar to
"parts" in Cubase, but a segment could also have a fixed length.
What happens is this: when an event is searched for, 2 parameters are used
for specifying the time period to search within - one to identify the start
tick, and one to identify the end tick.
To search through an entire event queue for an event with a start time (or
end time??) equal to or greater than the search start tick, and then search
for events with a start time equal to or smaller than the end tick, would be
a tremendous waste of CPU time (especially as for low-latency operation, the
timeline would need to be searched every few milliseconds or so!)
But with the use of segments, a segment could span 1 beat for example. When
a search is performed, all segments that are even partially in-range are
selected (possibly using flags) and then searched for events inside them
that are inside the search range.
With the method I've used (where the segments can be any length), the events
inside the segments use times relating to the segment start (not the song
start), so an event placed at the start of a segment will have a start time
of 0. The song position for this note is SegmentStart + EventStart.
Not sure if this would be useful for GMPI... Especially as the timeline
should be managed by the host. But it might be interesting/useful for some
developers out there.
As far as GMPI is concerned, the event searching should be transparent.
Plugins should just be able to say "find all events between time X and time
Y", where the time could be in a variety of formats. The host could supply
one time type, and GMPI could translate the times from host to plugin and
vice versa.
If anyone wants anything clarified, let me know - sometimes when I try to
explain something, it doesn't even make sense to me :)
-SB
----------------------------------------------------------------------
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:
