Formatted with nixpkgs-fmt

I get

[INFO:Zyn] setup_pugl()
libGL error: MESA-LOADER: failed to open radeonsi (search paths /run/opengl-driver/lib/dri)
libGL error: failed to load driver: radeonsi
Jack info message: Jack: JackClient::ClientNotify ref = 6 name = zynaddsubfx notify = 18
Jack info message: Jack: JackClient::ClientNotify ref = 6 name = zynaddsubfx notify = 18
libGL error: MESA-LOADER: failed to open radeonsi (search paths /run/opengl-driver/lib/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths /run/opengl-driver/lib/dri)
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  55
  Current serial number in output stream:  54

I have services.xserver.videoDrivers = [ "amdgpu" ];
Not sure if this is related to packaging.

@Sohalt I'm also using an AMD graphics card (Radeon RX 590) and I haven't run into this issue with Zyn-Fusion, but I've seen this issue before on blender. I fixed it by using the same nixpkgs for NixOS that I used to build blender. I assume there are some ABI incompatibilities with AMD OpenGL drivers between different versions?

I'm sure you would be able to get it to work if you used my NUR package instead: nur.repos.metadark.zyn-fusion.

I was having issues running this with the zest ui under Ardour. The issue is that when using the zest ui, the ZynAddSubFx plugin does a dlopen to libzest.so. The standalone binary works around this with some LD_LIBRARY_PATH trickery, but Ardour falls flat trying to load the plugin, since the dlopen fails.

I was able to resolve the issue by forcing libzest.so into the rpath of the plugin shared objects with something similar to the snippet below (VST untested, although I'd assume it needs the same fix), although I'm not sure if this is the best way to resolve this issue:

postFixup = ''
  rp=$(patchelf --print-rpath $out/lib/lv2/ZynAddSubFX.lv2/ZynAddSubFX_ui.so)
  patchelf --set-rpath ${mruby-zest}:$rp $out/lib/lv2/ZynAddSubFX.lv2/ZynAddSubFX_ui.so

  rp=$(patchelf --print-rpath $out/lib/vst/ZynAddSubFX.so)
  patchelf --set-rpath ${mruby-zest}:$rp $out/lib/vst/ZynAddSubFX.so
'';

Using this PR with guiModule = "zest", when loading ZynAddSubFx as a plugin in a different application and trying to open the GUI, it will complain that libzest.so cannot be found and shows a blank screen. I've tried patching the Zyn*.so object files in lib/vst using patchelf, but they're actually all statically linked, so I'm not quite sure where the issue is.

When I add the directory of libzest.so to LD_LIBRARY_PATH the plugin's GUI works, so it seems these statically linked objects are still doing some dynamic loading.

@Sorixelle & @Beskhue Hmm, that's strange. It dynamically links to libzest here: https://github.com/zynaddsubfx/zynaddsubfx/blob/3.0.5/src/Plugin/ZynAddSubFX/ZynAddSubFX-UI-Zest.cpp#L68-L72.

But when ZynFusionDir is specified in the build, it should automatically set up LD_LIBRARY_PATH before starting the UI: https://github.com/zynaddsubfx/zynaddsubfx/blob/3.0.5/src/main.cpp#L705-L740.

I will try it out in Ardour to try to reproduce it.

Ardour doesn't use the standalone binary, it just goes straight to the LV2 plugin. The LD_LIBRARY_PATH setup is only in the standalone binary.

I've tried patching the Zyn*.so object files in lib/vst using patchelf, but they're actually all statically linked

Are you sure about that? I ran file on the VST object files in my install and it reported them as dynamically linked.

@Sorixelle Oh right, thanks I misread your comment. I think patching the rpath would be the best approach then.

@Sorixelle I get:

thomas@argo /nix/store/0m3nr7s3yac9zm9nm4darm7ifwg72217-zynaddsubfx-3.0.5/lib/vst
 % file *.so
ZynAddSubFX.so:      ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, not stripped
ZynAlienWah.so:      ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, not stripped
ZynChorus.so:        ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, not stripped
ZynDistortion.so:    ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, not stripped
ZynDynamicFilter.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, not stripped
ZynEcho.so:          ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, not stripped
ZynPhaser.so:        ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, not stripped
ZynReverb.so:        ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), statically linked, not stripped

@Beskhue I think that file is printing that because there are no load-time dynamically linked dependencies, but libzest.so is linked at runtime.

@MetaDark You're right. @Sorixelle's patch works, and the GUI loads without setting LD_LIBRARY_PATH. The error from patchelf I got previously was due to mistaken use of the --set-interpreter option.

Ok I'll submit the patch. I was trying to remove ZynFusionDir by wrapping $out/bin/zynaddsubfx with zest in the PATH, but it doesn't seem to properly find the zest executable, so I'll just leave it in.

EDIT: Oh right, it's because it looks for zyn-fusion instead of zest when not using ZynFusionDir. I'll try again.

Thank you @Sorixelle & @Beskhue. Now it should properly load libzest.so when using the lv2 & vst plugins.

Builds and works wonderfully, both the standalone and the lv2.

I've been using this to make some songs in Ardour, and I just love it.
It would be wonderful to have this in nixpkgs.
Thanks a lot @MetaDark!

Could the people in this thread have another look and see if it works for them now?
@Sohalt @Sorixelle @Beskhue

Maybe the maintainers could also have a look?
@cillianderoiste @nico202

Nice! I always wanted to try zyn-fusion, but unfortunately I'm not using nix on a desktop anymore, so I cannot test this patch. Could you remove me from the maintainers?
Thanks

@nico202 Just submitted an update that removes you as a maintainer

@magnetophon It's working great for me.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/386

@magnetophon Sorry for the late reply. It works perfectly for me as well.

It's working well for me as well. It'd be nice to get this merged. @SuperSandro2000 can you have a look?

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 91674 run on x86_64-linux 1

@SuperSandro2000 Thanks for reviewing this! I didn't resolve all of your comments, but does this look ok now?

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 91674 run on x86_64-linux 1

Thank you @SuperSandro2000! I really appreciate the review ❤️