linuxaudio.org

--20cf300fae7db85a0204c0f81700

Content-Type: text/plain; charset=ISO-8859-1
On Sat, May 26, 2012 at 4:59 PM, Fons Adriaensen wrote:
> On Sat, May 26, 2012 at 04:22:58PM -0400, Paul Davis wrote:

quoted text
>

> > 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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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'

quoted text
>

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

quoted text
> 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

quoted text
> 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.
--20cf300fae7db85a0204c0f81700

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
On Sat, May 26, 2012 at 4:59 PM, Fons Ad=

riaensen <fons@linuxaudio.org> wrote:

On Sat, May 26, 2012 at 04:22:58PM -0400, Paul Davis wrot=

e:
> as once again another discussion that could be a useful technical

quoted text
> discussion turns into a stupid spitting match. sigh.

So far I didn't spit and I have no intention to do such a thing.<=

br>I think you know precisely what I mea=

n.=A0

quoted text
> look fons, variable size frame counts were one approach to a genuine

> problem: how to deliver automation data to plugins. but they were not<=

br>

quoted text
> 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 absenc=

e of a part of the API designed specifically to deliver automation data, it=

s one of the few reasonably straightforward choices.=A0

A well-designed plugin

should actually impose its own limits on the rate of change orplugins 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 wit=

h 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 co=

mment *at all* on the desing process of the LADSPA plugin

standard. Please re-read. I did imply that copying some aspects of itLADSPA and LV2 are not independent here. the requiremen=

t that you're talking about:=A0
- the requirement for a plugin to accept any value of nframes =

is shared across just about every plugin API out there. on the oth=

er hand, its use as an=A0=A0
easy way to allow 'sample accurate' control - into the 'next ge=

neration'is host-specific, and doesn't ha=

ve much to do with the API.=A0=A0
Question: do A2 and/or A3 actually subdivide a period in order to

deliver automation data or not ?depends on the pl=

ugin API in use. in some cases yes, in others no.=A0
If yes, do they also try to deliver 'sample accurate' control value=

s

in case these are real-time (from GUI widgets, MIDI, OSC) ?data from control surfaces of any kind is quantized to the blocks=

ize, and when delivered during=A0 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 si=

milar) editing of the data.
--20cf300fae7db85a0204c0f81700--