[gmpi] Re: Reqs 3.8 Events - ramped events
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 12 Jan 2004 12:26:30 +0100
On Monday 12 January 2004 05.01, Tim Hockin wrote:
> On Wed, Jan 07, 2004 at 12:20:29PM +0100, David Olofson wrote:
> > Then again, how important is it that controls not designed for
> > ramping sort of try to emulate it? I think it's irrelevant in
> > most of cases, since normally, controls that make sense to ramp
> > will support ramping, at least to the extent where you get a
> > reasonable approximation of the expected result.
>
> The issue is that a sender of events needs to know whether the
> receiver can properly handle ramps.
I think that depends on the implementation. Both <start, delta> and
<target, duration> events, in conjunction with the "drive inputs as
long as you're connected" rule, will set the target value at the end
of the ramp, if the receiver just ignores the ramping ang grabs the
start or target value.
<target, duration> allows plugins to set the new value in the middle
of the ramp, resulting in a maximum error of 0.5 * |start - end|,
which is half of what you get if you set the target value at the
start or end of a ramp.
<start, delta> does not allow this, as you cannot know the duration of
the ramp until you get the next event - and then you're already at
the end of the ramp.
(The next stage is obviously to actually implement ramping. Internal
resolution, accuracy filtering etc, is another matter.)
> > Ramping integer controls, enums and stuff like that sounds like
> > "weird, experimental stuff" to me - and if you really want to do
> > it, you can just throw in some control type converter. (Probably
> > required anyway; see below.)
>
> Acceptable to me. We still have to either mandate that float
> controls support ramps, or we have to provide the info to senders,
> and all senders have to handle it properly.
I'd prefer that "ramping of real valued controls must be supported, or
at least emulated" in that case - but from an implementation POV, I
don't see why that's strictly required, just to avoid senders having
to know how well receivers handle ramping.
There *is* a problem if ramp duration is unrestricted and some
controls don't implement ramping, but that could be handled by hosts,
as long as control inputs are hinted with their level of ramping
support. (None - step at duration/2 - stepped/buffer - full, or
something...)
> > Or maybe plugins should be required to have event handlers for
> > all relevant event types for each control, regardless of type...?
> > I don't quite like the "exploding number of possible combinations
> > to test" part of it, but it would be a very efficient way of
> > supporting float->double, double->float, float->int etc. No
> > converters, and still no extra conditionals and stuff. (If events
> > are decoded with a single switch() with sensibly chosen case
> > values, the number of cases has no effect on performance.)
>
> yuck. Better to have generic control type converters.
Yeah... As long as they're just things that the host put on the
"wires" when needed, the total cost should be insignificant unless
you seriously abuse your plugins, I think.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
