On Sat, May 26, 2012 at 04:22:58PM -0400, Paul Davis wrote:
> as once again another discussion that could be a useful technical
So far I didn't spit and I have no intention to do such a thing.
> look fons, variable size frame counts were one approach to a genuine
That is probably true. But that doesn't make using that mechanism
to deliver automation data a good idea. A well-designed plugin
should actually impose its own limits on the rate of change or
the bandwidth of its controls, which means it should ignore some
of the things the host tries to make it do. Which in turn means
it's futile for the host to even try.
> you write as if when we designed LADSPA to "support" this, that no
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
- the requirement for a plugin to accept any value of nframes as an
easy way to allow 'sample accurate' control - into the 'next generation'
was probably a bad idea. Some others parts of the LADSPA specs were not
retained - for good reasons.
> ardour has no requirement to subdivide blocks for automation data.
Question: do A2 and/or A3 actually subdivide a period in order to
deliver automation data or not ?
If yes, do they also try to deliver 'sample accurate' control values
in case these are real-time (from GUI widgets, MIDI, OSC) ?
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Linux-audio-dev mailing list