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

Tim Hockin thockin at hockin.org
Mon Dec 23 13:04:01 UTC 2002


> If you're sync'ing with beats or measures, you're fine. But if you're 
> doing it the traditional way - sync'ing with a note value - you'll 
> need to know what one beat actually is. Then you'll need the beat 
> value as well.

hrrm, this is purely theoretical.  We can either add it because we MIGHT
want it, or wait.  I'll put it in my notes to implement and we can think
more about it.

> > 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.
> 
> It doesn't really change anything - and the selection of a suitable 
> queue is still something that belongs in the plugin implementation. 
> (Most simple plugins will want a single queue, since otherwise, 
> they'll just have to merge the incoming queues anyway.)

Right, but what it DOES do is take away the overloading of controls.  With
overloaded controls, a plugin developer has to specify control type
(float/double/int), default value (N/A), ranges (a priori), flags for
'NO-PRESET', etc.  So many things that don't _REALLY_ apply to these
pseudo-controls.  I'm just exploring alternatives to it, trying to find
something more elegant.

The host could walk through a list of known 'special' event ports, such as
tempo.  These special event ports get special events.  They are still
events, but they are not really 'control set' events (well, they may taste
that way..).  What the plugin feeds it for a queue doesn't really matter.
These are special to the host/timeline setup and to the plugin.

Hrrm, how does that affect controllers and output ports.  Hrrm.

Another alternative - have a new control type that does not have default,
range, etc fields.  SYS_CTRL just has hints to the host about the existence
of a 'special' event port, without actually specifying a full control.

Other ideas/thoughts?


I'm off again tomorrow for the Christmas holidays.  I'm going to try to be
online, but no guarantees as to how effective I'll be from my mother's house
:)

Work will resume with a passion in the new year.



More information about the Linux-audio-dev mailing list