as once again another discussion that could be a useful technical
discussion turns into a stupid spitting match. sigh.
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.
you write as if when we designed LADSPA to "support" this, that no
other plugin API formed a part of the considerations that went into
that design process. every other plugin API that had a visible spec
specifically provided for variable frame counts. even in the AudioUnit
spec, which additionally provides much more sophisticated, scheduled,
non-scalar mechanisms to deliver automation data, it is *still*
mandatory for plugins to be able to accept any frame count from zero
up to some size specified during the last reset.
this is also a characteristic of ASIO and EASI and Rewire and many
other audio-related APIs.
now, we can sit here and listen to you and dave mudslinging about the
sanity of this or that. you can, if you want, insist that everyone who
designed AU and RTAS and VST also don't understand audio programming.
maybe you're even right about that (though it seems less likely). but
that doesn't actually solve anything or move anything forward.
ardour has no requirement to subdivide blocks for automation data.
precisely because i wasn't interested in implementing support for AU's
slightly complex automation API, its entirely possible to have do
block-accurate automation only. and if someone wanted to a bit of work
to use an API like AU where you can pre-schedule parameter changes, it
could revert to sample accurate when necessary. plugins are free to do
whatever they want with the host's attempt to do this.
On 5/26/12, Fons Adriaensen wrote: