Incorporate Zyn-Fusion

[Anonymouqs]

As of 31/12/2017, ZynAddSub-Fx has open-sourced its new GUI known as "Zyn-Fusion", which has a more intuitive interface than the old ZynAddSubFx. I feel we should incorporate fusion and replace the old Zyn, or keep the old Zyn for backwards compatibility.

A caveat: Its pre-built binaries have a price, but its source is open and may be compiled.

[tresf]

@Anonymouqs yes, we're well aware. We may go the LV2 route and hit two birds, but we'd need some custom code for playing back the presets. We don't have a lot of expertise on this with our active developers, so it's on the back burner until we have more help.

Historically, @fundamental was very helpful in integrating code. I believe @JohannesLorenz has begun some of the LV2 incorporation code, but I'm not sure of the status.

I'd also like to cross-reference #1860 which is 3 years obsoleted but was a valiant effort by @curlymorphic to spearhead the integration of the latest Zyn version from that era. This bug report would supercede those efforts.

[fundamental]

*31/12/2017

[alex-tee]

+1 for working on LV2 support (with automation of course) instead of embedding new stuff.

users install their favorite plugins and plug them in to LMMS, thats how it should be IMO instead of embedding instruments.

[Anonymouqs]

What if we had an Atom Text Editor-esque plugin-handling system for free plugins? You would post a plugin and a user could install it via the plugin-handler. It might be complicated to set up the infrastructure for such though.

[fundamental]

@Anonymouqs if you want a plugin-handler for free as in FLOSS plugins, you want LV2 support. If you want a plugin-handler for free as in $0/freeware, then you want a full implementation of cross platform VST2 support. Perhaps you also want some sort of plugin-store like interface, though that's a separate issue.

[tresf]

What if we had an Atom Text Editor-esque plugin-handling system for free plugins? You would post a plugin and a user could install it via the plugin-handler. It might be complicated to set up the infrastructure for such though.

In theory this sounds great, but conceptually you're mixing some technologies...

Atom/Electron works predominantly off of JIT-style interpreted code execution. C++ on the other hand works predominantly from precompiled code. Mixing these would only cause complexities and latency.

As @fundamental explains, two very popular compiled C++ interfaces already exist for most all of the worlds' plugins. The two formats he's mentioned are vastly popular and cover most use-cases. Zyn-Fusion was written with LV2 and VST2 in mind. We would cover a much broader scope of plugins by simply coding to the standards.

users install their favorite plugins and plug them in to LMMS, thats how it should be IMO instead of embedding instruments.

Zyn is still embedded for historical reasons only. In regards to the rest of the plugins we embed, some of them are good candidates as dedicated LV2 projects but some of them should stay built-in... e.g. Most users expect a DAW to support samples and sound banks directly. @pgiblock took an initiative a few years back to start porting the instruments to LV2 and that's a good long-term goal. We'd appreciate any help in this area. 👍

[tresf]

What if we had an Atom Text Editor-esque plugin-handling system for free plugins?

I think I misunderstood this. You were talking generically about easy-installation of plugins. That's a much larger initiative and can scale to samples, presets and projects. @tobydox wrote a very early "online" sharing platform, documented in part here: https://github.com/LMMS/lmms/issues/661. Of course, executing binary code (i.e. a plugin) is much riskier than a sample or preset file, so any system that allows code execution is a risk to the project as well as its users, so a plugin system that supports LV2/VST would make sense as a stand-alone project. e.g. something that's reputation based, has built-in scanning for malicious code and something that any DAW can communicate with. Then we'd code to the API established by the plugin repo. Edit: Also be mindful that there are huge compatibility issues between platforms. e.g. macOS 10.8, 10.9, 10.10, 10.11, 10.12 and that doesn't even begin to cross into the Linuxes/Unixes, 32-bit versus 64-bit and the eventual ARM architecture support.

In short, we'll still be shipping with Zyn, just in a more standard plugin format.

[JohannesLorenz]

I'm indeed integrating zyn into LMMS and there will be a PR very soon. However, it won't be based on LV2 or anything similar, but on something new called "osc plugin".

IMO LV2 has more disadvantages than advantages. Maybe we should finally start a thread about arguing what's good and bad about it (in an objective way). For me, the decision whether I'll get fusion now with a protocol which does its job perfectly, or maybe in 2 or 3 years with a protocol which I don't consider good, is clear.

About the shipping: LMMS and zyn will be decoupled enough to make zyn a submodule. As zyn will not be compiled into LMMS anymore, it might even be possible to not submodule zynaddsubfx. For the latter point, I have no special opinion, and we don't need to decide it yet.

[tresf]

@JohannesLorenz thanks for the background information. I'm happy to tackle the packaging and building decisions once the time comes. Binary release would be a very nice option, but obtaining an application-wide license from @fundamental vs working with the upstream build scripts is going to take some research to decide. I'll contact @fundamental offline about binary licensing as it may be a necessary stop-gap, depending on the timing of things.

[Anonymouqs]

On the topic of adding ZynFusion, I believe we should keep ZynAddSub-Fx for backward compatibility and preserving the millions of precious presets. In short, there would be two Zyns:

• ZynFusion
• ZynAddSub-Fx

[Spekular]

Zyn Fusion is "only" a new UI for Zyn as far as I'm aware. I wouldn't think any of the other version changes should be breaking, but I shouldn't say anything about that since I don't know.

On Wed, Mar 7, 2018, 18:07 Orbital Ink notifications@github.com wrote:

On the topic of adding ZynFusion, I believe we should keep ZynAddSub-Fx for backward compatibility and preserving the millions of precious presets. In short, there would be two Zyns:

• ZynFusion
• ZynAddSub-Fx

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/4179#issuecomment-371209317, or mute the thread https://github.com/notifications/unsubscribe-auth/AIgVmn8aHEWx6_FYw_RYlukvEomoFq19ks5tcBPAgaJpZM4SMbAf .

[JohannesLorenz]

@Spekular is correct here. Fusion is just a new interface for exactly the same functionality. Old presets can be loaded as usual, no data loss.

[Luraktinus]

any news?

[Reflexe]

any news?

562 blocks this issue.

[famiu]

Since (afaik) LV2 is in master now, could we consider incorporating Zyn-Fusion now?

[Spekular]

Since (afaik) LV2 is in master now, could we consider incorporating Zyn-Fusion now?

Only the core and URID extension are in, so I don't think Zyn-Fusions requirements are met yet. You can see an overview of all the extensions to be implemented here: #4954

[JohannesLorenz]

There's still a lot to do (and strangely, UI is not even listed). You can easily check the requirements:

$ LMMS_LV2_DEBUG=1 install/bin/lmms
...
Lv2 plugin "ZynAddSubFX" (URI: http://zynaddsubfx.sourceforge.net ) can not be loaded:
  -  unknown port type for mandatory port : Events Input
  -  unknown port type for mandatory port : Events Output
  -  required feature not supported : http://lv2plug.in/ns/ext/options#options
  -  required feature not supported : http://lv2plug.in/ns/ext/worker#schedule