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

David Olofson david at olofson.net
Mon Dec 23 14:09:00 UTC 2002


On Monday 23 December 2002 18.58, Tim Hockin wrote:
> > 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.

Actually, the *beat* based approach is purely theoretical. These 
kinds of things (as implemented in h/w synths at leat) usually talk 
about note values; not "fractions of a beat".


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

Yeah. It seems like beat based timing is generally more useful, so 
there might not be much point in using the traditional method at 
all...


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

Yeah... Macros? (Like for your average float control...)

The good part is that the host doesn't have to do anything special 
about it.


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

Not much, really. If you have a "timeline generator" in the net, it's 
going to have a bunch of outputs of types corresponding to the 
timeline inputs of plugins that want timeline events. This is just 
like the "Cable/Wire" approach; the host will look for matching 
inputs and outputs and connect them. Doesn't matter what types they 
are, as long as they're the same.

In the sender, you have something like this somewhere:

	if(me->outputs[OUTPUT_TEMPO].queue)
	{
		XAP_event *e = xap_event_alloc(me->host);
		if(!e)
			...;
		e->target = me->outputs[OUTPUT_TEMPO].cookie;
		e->... = ...;
		...
		xap_event_send(e, me->outputs[OUTPUT_TEMPO].queue);
	}


And in the receiver:

	switch(e->action)
	{
	  ...
	  case XAP_A_TEMPO:
		...handle tempo change...
		break;
	  ...
	}


Connection is still done with the usual "get cookie + queue and tell 
the sender to connect it's output to it" approach. The host never 
cares what events are used.


> Another alternative - have a new control type that does not have
> default, range, etc fields.

Well, they *are* of different types, so why should they have 
defaults, ranges etc at all? Each control type has it's own struct 
for this anyway, right?


> SYS_CTRL just has hints to the host
> about the existence of a 'special' event port, without actually
> specifying a full control.

Yes, that could be one way. These "things" have to be strictly 
standardized anyway, so there's no real need for dragging any 
metadata around. Only the type field is needed, basically.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list