Purge lmms/zynaddsubfx

[tresf]

The lmms/ZynAddSubFX repo was originally created as a way to use git submodule to isolate the Zyn integration code with lmms' own code.

The repository has not been updated since December 2014 as there is little incentive to... We don't currently use git submodule in our repository, due to some initial complaints by developers when it was originally implemented so we end up making any patches directly to the bundled version, like the rest of our plugins.

The plugin version of this has had quite a few minor changes ranging from 2014 to 2017 and stands as our best version of th Zyn 2.4 integrated code.

Several efforts to migrate to Zyn 2.5 were performed. It was close, but no attempts were 100% successful. More information on that effort here: LMMS/lmms#1860

As an artifact of that effort, the best version of Zyn 2.5 integration dosn't live in lmms/zynaddsubfx but rather lives in @curlymorphic's fork of lmms/lmms, last updated in 2015.

Since then, Zyn 3.0 has been released with a brand new UI which is partly non-free. I'm not sure how this shapes the future of Zyn integration into LMMS.

Future versions/integration efforts should eventually move back to a git submodule or perhaps git subtree as proposed here by @lukas-w: LMMS/lmms#296.

Anyway, I think we can safely delete the existing ZynAddSubFX fork and leave it inlmms/plugins for now. Any objections, please speak up.

[lukas-w]

May be worth keeping. It looks like there are still commits that haven't been merged into lmms/plugins.

If we're going to move back to using git submodule anyway, we might as well do it now and re-integrate the repo.

[mikobuntu]

Zyn-fusion will eventually become free/open source afaik. I will ask @fundamental to make sure.

[tresf]

I think you're right, the time to do git submodule or git subtree is now, but I really don't think Zyn is the plugin to start doing it with.

I think swh is a better candidate, since our code is always synced to upstream.

[tresf]

Zyn-fusion will eventually become free/open source afaik. I will ask @fundamental to make sure.

Thanks @mikobuntu but I'd rather we keep this discussion about our fork, not necessarily the future of Zyn. That conversation is probably better suited for LMMS/lmms#1860.

[fundamental]

Since I've been summoned, I'll point to https://sourceforge.net/p/zynaddsubfx/mailman/message/35921306/ where I state that the source should be fully opened around mid-December.

[mikobuntu]

@tresf ah yeah sorry for side tracking the original subject. I have no objections in removing this mostly redundant repo.

[JohannesLorenz]

We don't currently use git submodule in our repository, due to some initial complaints by developers

It was one of the biggest mistakes to make zyn a non-submodule/subtree. It would have been obvious that syncing zyn with LMMS would be much more overhead than learning submodules for those complaining developers. I recall patches I've seen in the LMMS tree (related to namespace and lookup) that I had to do in zyn again. Obviously, not using any synchronization to zyn's repo is a very bad idea.

So you could use subtrees or submodules now, but if you add every single program that LMMS might communicate, the source will get too big. You also don't integrate JACK or the glibc though many linux users need it for running LMMS.

I think there's a much better approach. There are three ways to let zynaddsubfx run via an interface, so you only need to implement the interface:

• LV2 via Carla. Already working, but hard to install, and circumstantial in use from what I've seen.
• LV2 directly. From how fast development currently is, I don't expect that it will be finished too soon, and who wants to wait one or two years for the new zyn with all the new features?
• I have a(n uncommitted) fork of LMMS that defines an interface for general OSC plugins. It runs nicely with zyn, switching the UI is much more performant, and it has a DnD-like mechanism for almost all knobs. The code is already there, it's just that I don't have much time to test it and improve some issues.

[tresf]

It was one of the biggest mistakes to make zyn a non-submodule/subtree. It would have been obvious that syncing zyn with LMMS would be much more overhead than learning submodules for those complaining developers.

"Biggest mistakes" seems like an overstatement.

I recall patches I've seen in the LMMS tree (related to namespace and lookup) that I had to do in zyn again.

The Engine conflicts? Specific references would help the argument but I'm still not sure it helps us right now since we're on an unsupported branch.

So you could use subtrees or submodules now, but if you add every single program that LMMS might communicate, the source will get too big.

I'm not sure what this is describing. We already do add every single program we use, and the developers have been actively discussing how we plan on moving from that both on Discord and on GitHub. I'm not sure how a dated fork of an unsupported repo changes our current situation. What you're describing would be much more effective in a simple pull request. I think swh is the best example since we're synced 100%. We've been really good about submitting patches upstream, and then we could close LMMS/lmms#3489. But this all seems rather off topic to the question about purging the branch.

I think there's a much better approach. There are three ways to let zynaddsubfx run via an interface, so you only need to implement the interface:

Agreed although this discussion is better left in LMMS/lmms#1860.

who wants to wait one or two years for the new zyn with all the new features?

My initial response is to come to the team's defense here. This seems unnecessarily hostile, but I'd prefer if we don't bait this conversation with the 2 years... argument. The LV2 point is a valid one and one we discussed on Discord today. We too find it valid, regardless of how long it takes a volunteer to write it.

[JohannesLorenz]

"Biggest mistakes" seems like an overstatement.

How are you going to continue? You have done changes that were useful for zynaddsubfx (the namespacing at least, idk what you did aside from that), but you did not commit to the zynaddsubfx repo, and these commits are useless to the zynaddsubfx devs. Now, you have no other choice than merging the original zynaddsubfx repo into the one from LMMS by hand, solving all merge conflicts and stuff. This will take a lot of time. Config management can not be worse, and so "Biggest mistakes" is not an overstatement.

It's not the idea of open source that you work on a repo and keep the changes privately for you. Of course, your changes are still accessible for the zynaddsubfx devs, but they are of no use, since they

• affect old versions
• are not communicated
• are not under zyn's version control

If someone from another project (another DAW or even just zynaddsubfx) comes to you and says "I could need that feature, too", you're saying "I don't care".

The same mistake has been done with ladspa, btw. There are repos for swh, tap and zam on github. You're doing changes to your copied ladspa files, but no one ever outside of LMMS will benefit from them.

The Engine conflicts?

Probably. It mentions adding namespaces. Zyn has them now aswell.

[tresf]

It's"we", not "you", and this thread is in jeopardy of going terribly off topic.

Specific action is and will be taken to improve our upstream contributions, but as previously pointed out, this zyn repo simply isn't serving that purpose. swh is in excellent shape and that is our best test bed for submodule today. We have submitted EVERYTHING upstream, we just need to make it easier. PRs welcome.

[JohannesLorenz]

Let it be OT. Anyways, maybe the new OSC plugin I wrote will be a better alternative for the next 1 or 2 years than setting up a submodule? It's already working...

I'm not sure about the pros and cons, but it enables you to automate almost all knobs/sliders. If it helps I could make a commit the next days that would show the advantages and disadvantages.

[tresf]

@JohannesLorenz there's interest. Here was @Wallacoloo's attempt: LMMS/lmms#2311

And of course @curlymorphic's zynwin branch: LMMS/lmms@stable-1.2...curlymorphic:zynwin

In regards to the lingering zyn repo that this topic is about, it seems we should do our diligence and make sure we aren't losing anything along the way. I could certainly use some help with this task (e.g. @PhysSong or @lukas-w).

I've looked at upstream and there's a branch called 2.4.4-fixes which is the closest I can see as a home if we were to take the time to submodule this. My instinct is that it's more work than it's worth and keeping our code snapshot is the best approach until one of the above (e.g. LV2, OSC) ideas is implemented.

[tresf]

So in regards to the differences between these copies... here they are:

What LMMS had but never made it to zyn:
LMMS/zynaddsubfx@a89086e

What zyn had that never made it to LMMS:
LMMS/lmms@2ca9e19

What @jasp00 did incorrectly and has been reverted:
LMMS/lmms@fda557f

So the statements that @JohannesLorenz made about our fixes not making it back, there was really just one, the #define patch that made it into the codebase for OpenBSD. The other change was our website URL which was only cosmetic.

Anyway, they're identical, so we can submodule or subtree it if it makes people happy. I'm closing this out because I've lost energy to argue. :)

lmms/zynaddsubfx will live to see another day.