[LAD] LADSPA dilemma

[Tim Goetze]

[Fons Adriaensen]

>On Fri, Jun 15, 2007 at 12:01:10PM +0200, Tim Goetze wrote:
>> I've thought of 2. too but would prefer a host side solution because
>
>There is no host side solution within the LADSPA spec.

I disagree.  I think the solution is possible within the spec, though 
it may not be spelled out in ladspa.h.

>> * you only have to do it once per host, not once per plugin
>
>Hosts shouldn't be burdened with keeping what is essentially 
>internal processing state of a plugin. The matter we are
>discussing is just the simplest possible case of a something
>that could be much more complex, depending on what's inside
>the plugin. Since that complexity is created by the plugin
>and what it tries to do, and there are no limits to it, it
>has to be handled at that side. What is required is an API
>that supports more complex plugin behavior - in this case
>a call that would reset the flag and force a jump to the
>current control values at the start of the next run(). (*).

I agree that the API should support parameter smoothing, but again, I 
postulate that a generic solution is simpler than you suggest.  (And 
it doesn't require hosts to "keep internal processing state of a 
plugin".)

>> * it keeps the plugin code simple
>> * it is more efficient
>
>You must be kidding :-)

No, I'm not, and I do not understand why you think I am.  

Let's assume the host provides the values that are going to be used at 
run() right when activate() is called.  The same values have to be 
calculated sooner or later anyway, so why not in time for activate().

(Of course there may be reasons why this approach is undesirable for 
hosts, but I'm looking at this as a plugin developer only, trying to 
solve it within LADSPA.)

If the host simply did this then the plugin would not have to run the 
extra "should I sweep now?" check in run() and toggle corresponding 
flags in run() and activate().  It'd simply initialize its state in 
activate() and sweep from the previous state to the current parameters 
during run().  Both of which it has to do anyway.

Less code, more efficiency, no kidding.  

In fact, it's already working exactly like this with CAPS and select 
hosts, and has been so for quite some time now.

>(*) [OT] After the latest LV2 thread in which I participated,
>I've stopped suggesting such simple things, becaues the reaction
>is always the same - it's too complicated for the plugin developer,
>it's inefficient, etc. while this is in general not true - e.g.
>the call suggested above can just be ignored if you don't
>interpolate control values. Anyway I won't even try again,
>and I'm currently developing my own plugin API. 

That's a bit sad to hear. On the other hand I can see your point, in 
open source advancing on your own seems about the only way to 
accomplish things like these in time and in style.

Anyway, I'm teaching the CAPS plugins the "is this the first call 
after activate() or am I going to smoothen parameters" dance now.  
Since LADSPA is unlikely to move an inch, I propose we agree to 
disagree and hope for the best.

Actually, the point of my original post was not meant to be "let's fix 
LADSPA" but rather "Please, Ardour developers, at least zero the 
memory you connect plugin control inputs to, it would have saved a lot 
of people a lot of headache, yes I know the law is on your side but 
pretty, pretty please?".

Cheers, Tim