On Sat, May 26, 2012 at 4:59 PM, Fons Adriaensen <[email protected]>wrote:
> On Sat, May 26, 2012 at 04:22:58PM -0400, Paul Davis wrote: > > > as once again another discussion that could be a useful technical > > discussion turns into a stupid spitting match. sigh. > > So far I didn't spit and I have no intention to do such a thing. > I think you know precisely what I mean. > look fons, variable size frame counts were one approach to a genuine > problem: how to deliver automation data to plugins. but they were not > added solely for that reason. That is probably true. But that doesn't make using that mechanism > to deliver automation data a good idea. in the absence of a part of the API designed specifically to deliver automation data, its one of the few reasonably straightforward choices. > A well-designed plugin > should actually impose its own limits on the rate of change or > plugins are free to do this with or without a requirement that they handle 0..N frames. certainly, doing so can be a bit more complex with the 0..N requirement, but its not impossible - there is an entire company's suite of plugins that all do this across more than 6 plugin APIs all of which have the 0..N requirement. I didn't comment *at all* on the desing process of the LADSPA plugin > standard. Please re-read. I did imply that copying some aspects of it > LADSPA and LV2 are not independent here. the requirement that you're talking about: > - the requirement for a plugin to accept any value of nframes is shared across just about every plugin API out there. on the other hand, its use as an > easy way to allow 'sample accurate' control - into the 'next generation' > is host-specific, and doesn't have much to do with the API. > Question: do A2 and/or A3 actually subdivide a period in order to > deliver automation data or not ? > depends on the plugin API in use. in some cases yes, in others no. > If yes, do they also try to deliver 'sample accurate' control values > in case these are real-time (from GUI widgets, MIDI, OSC) ? > data from control surfaces of any kind is quantized to the blocksize, and when delivered during non-automation playback, delayed by up to one block. automation data is recorded by sampling plugin control port values. the only thing that can generate sub-block size resolution is GUI-based (or similar) editing of the data.
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
