<br><br><div class="gmail_quote">On Sat, May 26, 2012 at 4:59 PM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org" target="_blank">fons@linuxaudio.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On Sat, May 26, 2012 at 04:22:58PM -0400, Paul Davis wrote:<br>
<br>
> as once again another discussion that could be a useful technical<br>
> discussion turns into a stupid spitting match. sigh.<br>
<br>
</div>So far I didn't spit and I have no intention to do such a thing.<br></blockquote><div class="im"><br>I think you know precisely what I mean.  <br><br>
> look fons, variable size frame counts were one approach to a genuine<br>
> problem: how to deliver automation data to plugins. but they were not<br>
> added solely for that reason.<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That is probably true. But that doesn't make using that mechanism<br>
to deliver automation data a good idea. </blockquote><div><br>in the absence of a part of the API designed specifically to deliver automation data, its one of the few reasonably straightforward choices.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A well-designed plugin<br>
should actually impose its own limits on the rate of change or<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I didn't comment *at all* on the desing process of the LADSPA plugin<br>
standard. Please re-read. I did imply that copying some aspects of it<br></blockquote><div><br>LADSPA and LV2 are not independent here. the requirement that you're talking about:<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

- the requirement for a plugin to accept any value of nframes </blockquote><div><br>is shared across just about every plugin API out there. on the other hand, its use as an <br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

easy way to allow 'sample accurate' control - into the 'next generation'<br></blockquote><div><br>is host-specific, and doesn't have much to do with the API. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Question: do A2 and/or A3 actually subdivide a period in order to<br>
deliver automation data or not ?<br></blockquote><div><br>depends on the plugin API in use. in some cases yes, in others no.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

If yes, do they also try to deliver 'sample accurate' control values<br>
in case these are real-time (from GUI widgets, MIDI, OSC) ?<br></blockquote><div><br>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. <br>
<br>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.<br><br></div></div>