[LV2] [PATCH 5/5] add external UI as valid UI

Robin Gareus robin at gareus.org
Mon Jan 6 10:19:54 PST 2014

On 01/06/2014 06:26 PM, Kaspar Emanuel wrote:

> but when I glance
> over at the definition of write_set_file in uris.h I want to take
> cover and hide (though less so with the explanations from your last
> email).

NB. lv2_atom_forge_path()

The path can be abstracted depending on OS. e.g. Windows uses '\', POSIX
systems use '/', Posix has support for symlinks, windows not.
The plugin-state of this example plugin is LV2_STATE_IS_PORTABLE.

It is also an official 'patch_Set' which the plugin-*host* could
intercept and understand.

If you just wanted to communicate some data from UI to backend, it could
be simplified a lot. The complexity here comes from the semantics.


> For nanopb, you define maximums in your .proto or .options file.
> Regular protobuf uses dynamic allocation. How is the varying length
> actually dealt with for atom sequences? I guess it's the buffer size
> you set for your forge?

for LV2 you can request it in the .ttl using
see eg05-scope for an example.

It is allocated by the LV2-host in non-realtime context.

>> Embedding generally works fine and most users and developers are happy
>> with it.
> Well rncbc and falkTX seem to both be expressing some concerns 

[citation needed] :)

IIRC Rui criticized the point of QT3/4/5 compatibility when swallowing
UIs. -- That might be a non-issue if you write it at high-level in python.

As for falkTX. ACAICT, he chose to re-implement libsuil (which does the
embedding) in his plugin-host -- rather than use the existing official
libsuil. I don't know why -- I guess it's to go along with the NIH
syndrome of KXStudio in general. AFAIK this work is not complete yet and
therefor embedding some UIs does not [yet] work in Carla.

@Rui, @Filipe: did I get this right? Please correct me, if this is FUD.

> I can't say I understand the issues with
> embedding widgets at all but there is definitely some resistance to it

Sadly, yes. I think it's a mainly a geek thingy; the dislike giving up
control and programmer-laziness.

* externalUI -> plugin author is in control of everything, easy
* embeddedUI -> plugin is at the liberty of the Host

Compare to 'commercial Mixbus' which can embed plugins directly on the
Mixer-strip. Undo, state, look&feel and interaction all integrated, this
is only possible with embeddable UIs.

Granted, Harrison writes most of these plugins themselves. They are in
control and they can pay programmers to not be lazy. Also the some of
the more visual heavy ones also externalUI - but that's IMHO valid
because they make creative use of openGL and have no widgets that can
reasonably be embedded in any way... YMMV.


More information about the Devel mailing list