[LV2] inline plugin displays

[Robin Gareus]

On 03/16/2016 12:18 PM, Niko Efthymiou wrote:
> On 15.03.2016 03:47, Robin Gareus wrote:
> 
>> This is function is provided by the plugin's shared-object itself (not
>> the GUI) because it must also be available when the plugin GUI is not
>> visible (not even loaded).
> 
> I don't like the idea of doing pixel drawing in the audio part of my
> code. The ui module is way more apropriate, as it already has some
> Toolkit providing pixel drawing funktions.

Hi Niko,

I'm glad that you pointed this out.

The drawing code can live anywhere. Personally I prefer to keep it in
separate file. You just need to provide a pointer to the function when
linking.

I think the issues here is that all LV2 examples keep the GUI in a
separate object file. It's straight forward really: a single shared
object can provide both: LV2_Descriptor and LV2UI_Descriptor and link to
allrelevant libs.

Still, if you have a better proposal, I'm all ears.


The motivation for the current design is simplicity and consistency.


The only reasonable place to make the decision if a visual update is
needed is during realtime run(). The GUI itself is not reliably
scheduled and is usually event triggered and not aware of the full
state, particularly when touching automation.  So at least one half of
the API has to be in the DSP code. Using different handles for
queue_draw() and render() would require additional host interaction to
complete the interface which seemed like bad design and may also differ
significantly between hosts.

The threading design is exactly like the LV2 Worker extension. One call
from run() where all relevant information is present to schedule. A call
in a low priority thread to process the information and render it.
Alike LV2:Worker this interface also implies instance access.

Another consideration that went into the design was that custom GUI need
not be a prerequisite for providing an inline-display.

Even if a plugin has a custom GUI, that GUI may not even be on the same
machine. If the interface was split, it'd be the obligation of the
plugin author to transfer all relevant data. The current interface puts
moves this responsibility to the host (which is usually already has
infrastructure available to that end).

Instance access also avoids code duplication: There is no need to
explicitly transfer data to and parse information on the GUI side, nor
to special case GUI state itself:
The current proposal does not impose any thread-context constraints.
This is intentional to leave freedom to both plugin and host authors.
The OS usually imposes constraints (particularly X11 and Cocoa).
Additional constraints part of the plugin spec would need to be very
careefully designed.

The GUI expose may be in different thread context and run concurrently
with inline-display render(). GUI Handle instance-access would be new
territory.  DSP side instance-access is well understood (VST and AU
authors cope with it from day one, LV2 has this as option). Yes it
allows to shoot oneself in the foot, but nannying plugin authors: (*)
no, you don't get instance access because it's dangerous and (*) yes,
you must provide a GUI first. Were two constraints that I rejected.


best,
robin