On Sat, May 26, 2012 at 4:59 PM, Fons Adriaensen <fons@linuxaudio.org> 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.