Subject: Re: [linux-audio-dev] XAP Time/Transport - varispeed/shuttle
From: Tim Hockin (thockin_AT_hockin.org)
Date: Mon Dec 23 2002 - 10:00:47 EET
> > 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
This archive was generated by hypermail 2b28 : Mon Dec 23 2002 - 10:05:16 EET