[gmpi] Re: GMPI reqs draft 1 (part 2) for review
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 31 Dec 2004 03:09:40 +0100
On Thursday 30 December 2004 22.03, Jeff McClintock wrote:
> > Small note on 4.10: Ramped or Smoothed Events
> > "In fact, these audio-rate events can eliminate the
> > need for ramps altogether."
> >
> > It might be worth noting that audio rate controls - actual
> > or this bybrid kind - add hidden costs (downsampling) when
> > plugins morph internal coefficients to avoid doing the full
> > control value to coefficients transform for each sample.
>
> Hi,
> Well, downsampling can be as simple as using, say every 8th
> sample and discarding the remainder. Not a huge overhead.
Right, but that may cause aliasing, and the only thing a plugin can do
to tell how much it's safe to downsample is to analyze the full
bandwidth control signal.
Meanwhile, a chain of ramp events can be seen as a well defined
variable sample rate signal. A ramped control output should never
send more events than are needed to describe the intended signal with
sufficient accuracy (however that is defined...), so you're safe as
long as you do something sensible with all incoming events - and you
don't wast cycles analyzing low bandwidth control signals at the full
audio rate.
One might get the best of both worlds, to some extent at least, by
using audio rate buffers with bandwidth hints... If your plugin needs
to downsample a lot, check the hint and chose an adequate
downsampling method for each buffer.
> My synths have the opposite problem, how to convert discrete
> parameter updates into a smooth, zipper-noise-free signal.
> Anytime I receive a parameter update, I ramp smoothly to the new
> value. Trouble is, I don't know what rate the host will send
> updates. the result is far from ideal...
>
> http://www.synthedit.com/stepped.gif
>
> I figure this is analogous to upsampling a signal without
> knowing the sample rate, it's simply not possible to do so
> perfectly. There is not enough information. The entire concept of
> sending parameter changes as discrete events is flawed. UNLESS:
> -The host could indicate the rate at which parameter changes occur
> -or the host included more info with each parameter change, i.e. a
> rate at which to ramp toward the new value.
>
> Including this extra information would allow much better
> recontruction of the intended (smooth) parameter signal.
That's exactly what ramp events are all about; providing that extra
information.
//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:
