23 Dec
2002
23 Dec
'02
4:06 a.m.
you can't
- we'd need to make METER a two-control tuple...
...Isn't this really the
domain of the user, though? What is it used for?
Do you actually need the beat value for anything on this level?
Remember that tempo and position are based on the *beat*, rather than
on a fixed note value, so you don't need the beat value to know what
one beat is in terms of musical time. One beat is N ticks. I think we need a special event, since otherwise you
can't move
the transport position when the transport is stopped. (See my
post on cue points.)
Maybe moving the transport position (play-head, if you will) should
not be sent to all plugins? If you have Cuepoints (will talk in
another thread), then you have cuepoints. If you don't, you get
the TRANSPORT value when play is resumed. Well, if TEMPO uses a "special" event, it
*cannot* be a normal float
(or whatever) control, and thus it *must* be hinted as a different
type, or the host wouldn't be able to make correct connections. I've
never suggested that these events should be hinted as normal controls
unless they really are 100% compatible in all respects.
One event set <==> one event data type.
What if, rather than have these as controls, they were explicit event_ports.
The host has to call "plug->get_event_port(some_indexing_scheme);" anyway,
right? What if it had a list of 'special' queues.
plug->get_event_port(plug, EVPORT_TEMPO);
Then we get all the goodness of events, without the overloading of the
notion of controls. Just another idea.
The SEEK control, OTOH, would provide the information
needed to get
it right most of the time, though. (It doesn't work if you pitch bend
Which is exactly what I dreamed it up for. It's not particularly useful for
CD-quality rendering, but for live play or studio work, it's SO nice.
(I've had a weekend off, as it seems did everyone else :)
Tim