[gmpi] Re: Reqs 3.8 Events - ramped events

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 13 Jan 2004 13:39:51 +0100

On Tuesday 13 January 2004 02.48, Tim Hockin wrote:
> On Mon, Jan 12, 2004 at 09:53:26AM -0700, Mike Berry wrote:
> > GMPI hosts shall provide translation facilities for connections
> > between plugin controls which share a primary type but differ on
> > secondary characteristics (such as ramping support).
>
> I'm no longer conveinced we even need this requirment at all.  If
> we mandate that hosts allow ramped outputs to send to a non-ramped
> input, we force every host to insert ramp->point converters. 
> Better, I think (I know I flip-flopped on this a bit), is to assume
> all real-number inputs are capable of some semblance of ramps.  If
> your input LEGITIMATELY is not capable of ramps, you may want to
> consider a non-float type, or just handling ramps as points.  If
> you *should* be ramping but aren't, your plugin will just sound
> worse than it could.
>
> What think?

Yeah, that's fine with me.


> As for the case of very long ramps, I've had a read of the AU docs.
[...]
> It may not be perfect, but it's interesting.

Yes... It's interesting, but I don't quite like it, for various 
reasons. Most importantry, there are no less than 5 possible cases;
        1) no ramp,
        2) full buffer ramp,
        3) starts within buffer,
        4) ends within buffer, and
        5) starts and ends within buffer.

And what about multiple ramps per buffer?

Unless I'm missing something, XAP/Audiality style ramp events are *so* 
much easier to deal with. It it's simplest form; linear audio rate 
ramping, assuming <target, duration> events are used;

        In the event decoding switch:
                case EV_RAMP:
                        if(ev->duration)
                                delta = (value - ev->target) /
                                                ev->duration;
                        else
                        {
                                value = ev->target;
                                delta = 0;
                        }
                        break;

        In the DSP loop:
                <use value for something>
                ...
                value += delta;


Besides, the AU way doesn't even provide any additional information or 
capabilities, AFAICT; it might even have some more restrictions.


//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: