[LV2] Buffersize, Options and Externtion-Data

[David Robillard]

On Wed, 2015-09-09 at 17:48 +0200, Filipe Coelho wrote:
[...]
> What I want to make sure we agree on, is that this "current" value we're 
> after it's the "engine realtime maximum",
> not the actual number of frames used in run() since that is not 
> guaranteed to be always the same.
> Plugins can use this value to know that run() calls will always use 
> equal or less frames than it, never more.

That is precisely what maxBufferSize means.

> If the host needs to call run() with a higher number then it should 
> report that to the plugin via options->set().
> This is the case of Ardour offline/freewheel mode.

Unless there's a really good case for making plugins have to deal with
this, I'd rather just say it doesn't change.  Hosts can reinstantiate
the plugin if necessary.

> PS: Anyone got a suggestion for a "engine realtime maximum" property name?

Yeah.  maxBufferSize ;)

> When the spec says:
> "There are two facilities for passing options to an instance: 
> opts:options allows passing options at instantiation time,
> and the opts:interface interface allows options to be dynamically set 
> and retrieved after instantiation."
> 
> Seems to me that options:interface and instantiate-time feature serve 
> the same purpose.
> Giving special meaning to one of them seems wrong.

One is static, the other is dynamic.

There is currently no fine-grained mechanism to say whether changing a
specific property dynamically is supported by a plugin.

The easiest way to do so would be the "better to beg for forgiveness
than ask permission" approach of a return value from options.set() that
says "I can't change this dynamically".

> >   (3) the opts:interface [6] to get/set the value must not be used in the
> > run() realtime-process function. It's only valid to get/set options
> > during activate(), deactivate(), worker-thread or state-load/save.
> Isn't that what the "instantiation thread class" exactly means?

Yes, but I think you are thinking about this backwards.  These are
plugins methods called by the host.

> > Discussion
> > ----------
> >
> > If a above interpretation is correct there is no way for a plugin to
> > know what the current period size it. (except maybe using a
> > worker-thread to periodically poll the opts:interface)
> As I said, the host can simply pass those values in its options feature.

The case for needing to know the maximum is obvious.

The "current period size", if not fixed, and not the max... well, not so
much.  How useful is "oh, run() might be called a bit more often with
this value than some other one" in reality?

> > The run() function already passes the actual sample-count. So what
> > number does "current" mean?  The total number of samples is expected to
> > span various run() calls resulting in one hardware cycle?
> I tried to answer this in a comment above.
> If it makes sense to you please let me know (I find it very important).

I don't think it means anything sensible/useful at all.

-- 
dr