Subject: Re: [linux-audio-dev] XAP Time/Transport - varispeed/shuttle
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 23 2002 - 21:03:19 EET
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 ---
This archive was generated by hypermail 2b28 : Mon Dec 23 2002 - 21:07:42 EET