23 Dec
2002
23 Dec
'02
3:08 p.m.
On Monday 23 December 2002 18.58, Tim Hockin wrote:
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".
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.
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.
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.) 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 ---