[linux-audio-dev] XAP Time/Transport - varispeed/shuttle

[Tim Hockin]

> > 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.

Agreed - I am not convinced we need it.

> > > 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.
> 
> Yeah. It's just that HDRs tracking the play cursor and that kind of 
> stuff is so commonly used that I think it makes sense to have the 
> timeline work the same way.

OK, So we have some mechanism to indicate STOP/START and another to indicate
position.  You can get position changes regardless of STOP/START state.
Does that sound correct?

> 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