linuxaudio.org

On Sat, 2012-05-26 at 20:05 +0000, Fons Adriaensen wrote:

quoted text
> On Sat, May 26, 2012 at 02:23:52PM -0400, David Robillard wrote:

[...]

quoted text
> Which leads to an interesting observation: you extension

> actually negates part of the core specs. So that is allowed ? 

Sure it is.  In this case, it's not even weird, if we do this now it

will look EXACTLY the same as if we did it from day one.  It's a

textbook case of what the feature mechanism was designed to do, and not

weird or unnatural at all.
In LV2, stuff like this is done via "features".  A feature is either

optionally supported, or required, by a plugin.  In code, the host

passes a struct to instantiate for each supported feature which may

contain whatever (in this case, probably a get_buffer_size() function

and so on).
The host may not instantiate a plugin if it *requires* a feature it can

not provide.  So, in this case, if the plugin requires e.g. a power of 2

buffer size, and the host can't provide that, well.. it can't provide

that and the plugin can't be used.  This isn't crazy decentralized

metadata pipe-dream stuff, it's the way the API would be made from day

one anyway; extremely straightforward basic C stuff.
Because of what "required" means, you can do pretty much literally

anything with a required feature.  You could define a feature where the

host must fetch the fifteenth byte from http://linuxaudio.org and pass

that to instantiate if you wanted to.  It's crazy, and *requiring* that

feature surely means your plugin isn't going to work almost anywhere,

but that's fine.
In this case, however, it's not crazy at all.  It's the most natural

thing in the world.
Here, notice a plugin not working in the host is *inherent*.  This is

why LV2 folks generally don't consider this a "problem" - it isn't one.

If the host literally *can't* provide a given feature (e.g. fixed buffer

size) and the plugin *requires* it to function at all, well, clearly the

plugin can't work in that host.  LV2 merely provides a mechanism to

express such things.  The decision of whether to do them is inherent.
It is not my job, or your job, to tell plugin and host authors what they

can and can not do.  Ad hoc extensions are where innovation happens,

where solutions get sorted out *before* they become part of the main

spec.  You can't sort them out without actually implementing them.

Software simply does not work that way.  Ever.
Different host authors have different opinions about conservatism and

compatibility and such.  This is fine and good and expected and natural.

It will all work out eventually.  You've been around here long enough to

know everything ain't happening tomorrow regardless :)
tl;dr: If buffer size restrictions are the way to go, then let's go that

way.  It's just that simple.
> > You criticize LV2 for having control ports, but then say an alternative

quoted text
> > is impossible because it would be invasive?  This does not make sense.

>

> Not for having control ports. For encouraging (almost mandating -

> there is no alternative in the core spec) a way to provide control

> values at arbitrary points by manipulating the nframes of a process()

> call. There is a world of difference between

>

> 1. telling a plugin that at N frames from the current position the

>    parameter P should have value V, and

> 2. doing the same, while also requiring that the plugin outputs

>    N frames at that time.

>

> My argumentation is that doing (2) is a bad idea, and even more so if

> you consider that (1) is a silly thing to in the first place, at least

> for the usual audio processing tasks such as EQ, dynamics, and most

> effects. The exception is synthesis modules of course, but those should

> have a dedicated mechanism for it anyway, or accept audio rate controls.

This is a bit difficult to decipher.  You are saying you think

block-accurate controls at a given fixed minimum size are good enough?
That's just LADSPA with a simple restriction on sample_count parameter.
However, making "synthesis modules" an exception is kind of pointless

over-classification.  Either a sample accurate control mechanism is

required, or it isn't.  There is no hard distinction between "synthesis

modules" and other things anyway, it is not a useful (false) dichotomy.
> The full report included a detailed anaysis of why (1) is a bad

quoted text
> idea in most cases (with the exception of synthesis modules). It

> is because it makes it almost impossible for the plugin code to

> compute good parameter trajectories. A well-designed EQ, effect,

> compressor, etc. should actually *ignore* attempts to control its

> internals in such a way. So there was never any need to allow

> arbitrary nframes values. The correct thing to do would be to

> remove that from the core spec, and provide an extension for

> finer-grained 'sample accurate' control.

It's odd to speak of this like there has been some active decision to

"allow" arbitrary nframes values.  It's more accurate to say that

basically nothing has been said about this thus far.  It is simply an

absence of well-defined restriction because nobody has defined them yet.
If you're content with LADSPA style controls with just a restriction on

block size, that's trivial.  I don't really see why you've made such a

big deal about it.  There's plenty of questions raised by a sample

accurate control port (mainly whether to MUX the controls to a single

event buffer or not), but no questions about that.  From a spec POV,

it's easy.
It'd have been solved and implemented long long ago if it was brought up

in useful channels and not weird cloak and dagger reports...
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev