Re: [linux-audio-dev] plugin questions

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] plugin questions
From: David Olofson (audiality_AT_swipnet.se)
Date: ti loka   12 1999 - 17:14:02 EDT


On Tue, 12 Oct 1999, Kai Vehmanen wrote:
> On Mon, 11 Oct 1999, David Olofson wrote:
>
> >> We could decide to accept string parameters only when initializing
> >> plugins. If you need to change a string value, you'd just
> > The event system supports dynamic size events - so there's no need to
> > treat strings as a special cases for that reason. View the event
> > system (and actually the whole MCS) as a slightly specialized RT-IPC
> > toolkit; no MIDI-style event specific crap. What we're after when we
>
> How is this actually done in practice? If I know what kind of events
> some plugin accepts, constructing and sending them will be easy.
> What is still unclear to me is how do I get the type-info? I imagine
> that creating a usable API for this won't be easy.

No dynamic typing! It's hard-coded in the API.

Using the defines from my first suggestions...

----8<--------------------------------------
typedef unsigned int event_code_t;
#define EV_CLASS_MASK 0xff000000 /* TIMING, SYSTEM, CONTROL,... */
#define EV_FLAGS_MASK 0x00ff0000 /* EVENT, REQUEST, REPLY... */
#define EV_KIND_MASK 0x0000ffff /* Exactly what event is this? */
-------------------------------------->8----

...the type of an event is determined by the bits in the
EV_CLASS_MASK field. For the standard events (ie *not* custom
events), EV_KIND_MASK is where the event "number" goes.

> A few thoughts...
>
> - how do we limit what kind of information plugin can ask?
> - booleans, floats (values between [0.0,1.0]), text,
> sample rate, compression ratio (= difficult to represent
> with [0.0,1.0] floats), etc
> - should we make a difference between realtime-controllable
> (filter cutoff) and rt-uncontrollable (channel count,
> sample rate) parameters

The distinction is vague. Carefully designed plug-ins and engines
*can* support changing just about anything in real time, or at least
between cycles. It might even make sense to change the number of
channels in real time in some applications... So, I don't think
dictating this in the API is a good idea.

> - should plugin provide info about valid parameter
> values (min-max isn't always enough)

No, they should stick to the rules. An integer parameter could
*possibly* be allowed to have a user defined range, but if it's
really impossible to stick to the basic types, the event should
probably be private anyway.

Note that a lot can be done when telling the engine about the "soft"
properties of an event! For example, an event that allows only
power-of-2 values should still be an integer type with boundaries.
The properties that describe the event to things like generic UIs,
will provide the details.

> - what if plugin asks for 1024 bytes of floats and says
> it represents a volume envelope -> no way to create
> a generic UI for this (not necessarily a problem, but it
> should made be clear whether these are accepted or not)

That's probably an example of a private type... Or perhaps we should
include a standard for handling arrays?

And BTW, I don't think it's a good idea to send single events that
big. The event system's memory allocator does support variable size
event, but it's not really designed events that big. (I guess we have
to figure out a way to send big blocks somehow. I have a feeling it's
pretty useful...)

Anyway, in this case, the events to fill in the envelope should
carry a single point each. That way, it's possible to connect things
to individual points, just as if they were ordinary parameters.

> - or should we just decide on all these and force all
> plugins to use standard types and value ranges ...
> although this can quickly get out of hands

I know one thing that's bound to get out of hands before we even know
what happened: Supporting dozens of fancy features as lots of special
cases.

The support for all this would *have* to be implemented, and it
would *have* to be supported by every single implementation that
gets in touch with those parts - or we'll have no standard in the
end.

Hack a Win32 compatible API, anyone? ;-)

//David

 ·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    ·Rock Solid David Olofson:
    ·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
    ·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
    ·Open Source ·Singer/Composer


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST