[gmpi] Re: ramps vs audio-rate controls
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 16 Jan 2004 10:56:21 +0100
On Friday 16 January 2004 10.34, Steve Harris wrote:
> On Thu, Jan 15, 2004 at 04:17:43 -0800, Tim Hockin wrote:
> > Pros:
> > Same end result as ramps
> > More flexible than ramps
> > No issues with long-running ramps beyond a buffer
> >
> > Cons:
> > Memory bandwidth
> > Host needs to enable hooking up point-value controls to
> > audio-rate controls
>
> Not neccesarily. That only matters if the host allows
> plugin->plugin control chains. Not all will. Event to CV conversion
> is easy, CV to event is much harder and adds latency.
Why would CV->event add latency...?
> Other cons:
> If the host is responsible for drawing the UI then it makes
> generation the control data much harder (host needs to worry
> about things like buffer boundaries). Unless were assuming that
> the control data will be unsmoothed?
You'd need to resample audio rate control data if it's generated by
external code that isn't sync'ed with the host. Actually, you have to
do that with timestamped events as well, sort of - but it's
(normally) much less data.
> Makes native UI control over IPC (which a lot of people think is
> desirable) tricky. It would need some kind of (optional)
> intermediate (and probably event like) representation to make it
> practical.
That's a good point. Didn't even think about that. With ramped events,
you can pretty much transfer events as is, since it's obvious what's
intended if you look at the data. However, if you have to deal with
audio rate control data, you'll have to decimate one way or another.
Probably means users will have to tweak "quality" controls or
something, to balance accuracy and bandwidth...
> NB all it needs is a hint on some (otherwise normal) audio input
> that its to be used for control purposes (and it needs the control
> hints, if any), please dont make audio input and audio rate control
> fundamentally different.
Right. There are unavoidably differences at the lower levels, but as
long as the fundamental logic behind it all allows connections,
convertion can always be done one way or another.
> Other systems that have PCM control signals define a k-rate that
> can be less than the audio rate. I dont know if its neccesary, but
> its something to think about.
Seems to me that a variable k-rate - that is, one that isn't fixed at
compile time - would eliminate most of the optimizations a lower
k-rate would allow. Requiring that the k-rate is always the audio
rate divided by a power of two would help a great deal, though.
Timestamped ramp events sort of do that as well (though you can still
quantize your internal event resolution if you like), but the major
advantage is that the "k-rate" is fully dynamic all the way down to
DC. Might not be a big win in a modular synth, but I think it matters
in the kind of systems where VST, DX, AU etc is normally used. (Large
plugins with lots of controls and relatively few controls that are
constantly modulated by automation or other plugins.)
//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:
