15 Dec
2002
15 Dec
'02
2:29 a.m.
We've been talking about 'TEMPO' and
'TRANSPORT' and 'TICKS' and 'METER'
controls, which (honestly) kind of turns my stomach. This is not what
controls are meant to be doing. the answer strikes me in shadowy details:
Each host struct has a timeline member. Plugins register with the host for
notification of ceratin things:
host->register_time_event(plugin, event, function);
events:
TIME_TICKS // call me on every tick edge
TIME_TRANSPORT // call me when a transport happens
TIME_METER // call me when the meter changes
What about multiple timelines, you ask? Use different host structs. Or
something. If we standardize a timeline interface, we don't have to
overload the control-event mechanism (which forces hosts to understand the
hints or the plugin won't work AT ALL).
Replying to myself with two other ideas:
1) the host->tick_me(plugin, 100, cookie) // call me back in 100 ticks
- This could be a simple host-based time-management API
- This depends on a 1-1 map between host and timeline, which I think is ok
2) rather than having per-channel TEMPO etc controls, have a small set of
host-global (timeline global, if you prefer to say) event queues. If a
channel is concerned with TEMPO, they will have already gotten the hosts
TEMPO queue. They can then check it. This saves delivering the same event
struct to potentially many plugins, and still is sample accurate.
Again, just blathering. Trying to find something elegant..
Tim