10 Dec
2017
10 Dec
'17
11:07 p.m.
On 10.12.2017 22:19, Filipe Coelho wrote:
On 10.12.2017 22:14, Markus Seeber wrote:
There's more info about these issues on the LV2 mailing list archive. Here two
well-suited thread entry points interested individuals may want to look at. The
solutions (aka best practices) are known, they *just* need to be implemented.
[1] http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2016-March/001593.html
[2] http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2017-March/001755.html
Hm, I did not think about that hard enough,
honestly. Then again this makes
me want to explore the idea of a plugin GUIs separately from the DAW process.
This is not a new idea, but has it already been implemented and explored in
detail,
apart from the obvious translation of MIDI/OSC from/to track automation>
Carla
has been doing this since it gained support for lv2 gtk2 UIs.
Since Carla's backend does not rely on any toolkit, it can not show a toolkit
based UI directly.
For such plugins Carla opens the UI in a separate process, using a separate tool
that supports that specific UI type.
Messages to/from the main host are passed via pipes (which I now kinda regret
going for, shared memory would be better)
The exception to this are "external uis", but those do not take away the issue
with symbol conflicts on shared libraries.