Packaging ZynFusion - what to do with ZynAddSubFX

[Alexandros Theodotou]

Hi Guix,

I managed to build ZynFusion after some help from its developer (see
attachment for the current working package definitions), but we have a
small problem.

~ Background info ~
ZynFusion uses the exact same source code as ZynAddSubFX but passing a
compilation flag enables a different, more modern-looking UI called
"ZynFusion".

In addition to stand-alone binaries, they both come as LV2 plugins.
Each LV2 plugin is identified by its unique URI, and each plugin UI is
also identified by a separate unique URI (usually in the form of
<plugin URI>#UI). Plugins can have multiple UIs, and there is usually 1
UI for each supported platform.
~ End background info ~

The problem appears when when you install both ZynFusion and
ZynAddSubFX and you want to use them as plugins. If you only run their
binary versions (bin/zynaddsubfx) there shouldn't be a problem, but
when you attempt to open them as LV2 plugins, they currently use the
same URI so hosts will ignore one of them since most hosts use the lilv
library for detecting and loading plugins, which skips duplicates (I
believe it is undefined which one gets skipped - I think only the first
one found is used).

Since plugins can have multiple UIs, we could patch zynaddsubfx to
present itself as having 2 X11 UIs, one for zynfusion and one for its
current one, however current hosts don't offer an option to choose a UI
and simply choose whatever's found first. I believe this is the correct
behavior - the users are usually musicians and plugin format stuff
should be hidden as much as possible. Also, it is very rare for a
plugin to have more than 1 UI on the same platform, so hosts usually
just pick up whatever supported UI is found first.

Anyway, there will be problems if we allow users to install both
packages as-is, so here are our options as far as i can tell:
a) Change the URI of the plugin itself so that it's different from
ZynAddSubFX - this IMO is out of the question because presets won't be
portable anymore as they are bound to a plugin's URI.
b) Patch the plugin's turtle code to make it list both UIs as
available. The problem with this is mentioned above - current hosts
don't offer an option to choose a UI (and probably shouldn't) so one of
them (undefined which one - depends on the host's logic) will be
ignored.
c) Deprecate zynaddsubfx - this will mean users will no longer be able
to use the old UI if they prefer it, but it will probably be a good
solution for the majority of users and no changes are required to guix
d) Implement a "conflicts" variable in package definitions where you
can list incompatible packages, so guix won't allow you to install
zynfusion if you have zynaddsubfx installed, and vice versa.

I am personally fine with either c/d, although I believe d) is the
cleanest solution.

Any suggestions welcome.

Thanks,
Alex

tmp.scm
Description: Text Data

signature.asc
Description: This is a digitally signed message part