Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement SPA support (enabling zyn-fusion) #4662

Draft
wants to merge 143 commits into
base: master
Choose a base branch
from

Conversation

JohannesLorenz
Copy link
Contributor

@JohannesLorenz JohannesLorenz commented Oct 13, 2018

What's this?

This is an inofficial LMMS branch which provides zynaddsubfx 3.x support. There's an installer linked below (see "How to run") for installing this LMMS branch, coupled with a zynaddsubfx 3.0.3 plugin.

LMMS and zyn are connected by using a new, simple plugin API ("spa"). spa is like an abstraction of LADSPA, allowing ports to be not just operating on floats, but anything represented as a class, e.g. integers, booleans, or even ringbuffers. This makes it easy to add OSC ports.

What can it do?

What should work:

  • load and save files
  • preview XMZ files from 'My Presets' (left sidebar in LMMS)
  • drag-drop XMZ files from 'My Presets' over songs
  • drag-drop the zyn instrument on tracks from old zyn to convert them
  • drag-drop zyn widgets on automation patterns (you must
    keep the F1 key pressed, in contrast to LMMS, where it's the control
    key)
  • drag-drop zyn widgets (keep F1 pressed) on the controller rack's controllers
  • remove controller connections by dragging them on the controller rack in an area where no controller is (keep F1 pressed)
  • exporting songs, e.g. to WAV

What still needs to be done:

  • LMMS can crash if project loading time takes more than 10 seconds
  • reviews for
    • the spa concept in general
    • the LMMS implementation
    • the zyn implementation

How to run?

There are two ways to install from source, both require cloning from the lmms-zyn-fusion-test repo and following the README.

Currently, there are no binaries.

Bug reports

Please not in this PR, please submit at lmms-zyn-fusion-test repo instead.

Why another plugin API if we can have LV2?

There may be reasons for both APIs. From the spa FAQ.md:

  • Possible advantages of LV2 over SPA:
    • Currently a way larger user base, both plugins and hosts
    • Does not depend on C++11 (and less on the ABI)
    • LV2 is stable for years, SPA is still very experimental
  • Possible advantages of SPA over LV2
    • (Simple) C++ only, you don't need to learn anything else
    • Easy to implement hosts
    • Quick and easy to implement plugins (compare the zyn SPA and LV2 plugins:
      SPA are a few hundred LOC, LV2 comes with a whole folder plus the DPF lib)

What to do with this?

  • Don't merge! Reviews are required (also for the zyn plugin and the API
    itself) if it will ever be merged.
  • If it won't be merged, I'm really not sad:
    • It may not be an easy decision to
      adopt a plugin API that's only supported by a small number of plugins
    • There won't be a conflict to future LV2 implementations, but the savefiles for spa and LV2 will look
      different, requiring at least some kind of converter

Thanks to...

... everyone helping with this. Especially:

  • @fundamental for support with zyn, zest and general music advice
  • @tresf and @PhysSong for helping with merging some of the branche's features to main
  • @Bleuzen for alpha testing

include/PluginFactory.h Outdated Show resolved Hide resolved
include/SpaOscModel.h Outdated Show resolved Hide resolved
include/StringPairDrag.h Outdated Show resolved Hide resolved
src/core/PluginFactory.cpp Outdated Show resolved Hide resolved
src/core/spa/SpaInstrument.cpp Outdated Show resolved Hide resolved
@PhysSong
Copy link
Member

@JohannesLorenz I can't drop OSC models to existing automation patterns because it's not implemented yet. Are you going to implement it?

@PhysSong
Copy link
Member

I also think we should eventually integrate the build script into the LMMS repository prior to merging this, though it has less priority for now.

PhysSong and others added 4 commits October 22, 2018 10:53
This is solely code moving, no functional changes.
The reason is explained by the following commit.
This enables DnD from internal and spa knobs on

* Controller views (from the controller rack)
* Existing Automation Patterns
* Automation Editors
* Implement connecting automatable model to controller by
  dragging its widget onto a controller in the controller rack
* Implement saving of automatable models with controller
  connections when their names must be quoted
* Let Engine::getAutomatableModel() return existing osc connections, too
  (in order to overwrite them)
@JohannesLorenz
Copy link
Contributor Author

@JohannesLorenz I can't drop OSC models to existing automation patterns because it's not implemented yet. Are you going to implement it?

Yep, it's implemented now in 7e7044d. Also implemented: Drag-dropping on the controller rack (da9fcfc) to be able to connect to controllers.

No functional changes at all!
No functional changes at all!
The changes in Enginge.cpp are also just refactoring.
@JohannesLorenz
Copy link
Contributor Author

I also think we should eventually integrate the build script into the LMMS repository prior to merging this, though it has less priority for now.

The build script compiles zyn and mruby-zest, too, so I think we don't need the full script. It should be enough to change the travis/circle files, such that they

  • clone SPA
  • compile and install it
  • use PKG_CONFIG_PATH=... in front of the LMMS cmake call

For travis, I think it should suffice to add the changes to .travis/script.rb. Do the non-linux builds all support the PKG_CONFIG_PATH?
For circle, I must check how this will work.

@PhysSong
Copy link
Member

PhysSong commented Nov 3, 2018

It should be enough to change the travis/circle files, such that they

  • clone SPA
  • compile and install it
  • use PKG_CONFIG_PATH=... in front of the LMMS cmake call

There's a CMake alternative of it, ExternalProject_Add.

@PhysSong
Copy link
Member

PhysSong commented Nov 3, 2018

Some more issues I've found so far:

  • InstrumentTrackWindow::dropEvent needs some changes to fix compiler warnings and memory leaks, see PhysSong@e81f9b0
  • SPA fails to build on Mac and for Windows, due to linking errors on building examples(after making CMake accept any compilers)
  • SPA is a hard dependency of LMMS now due to unchecked #includes.

We should either bundle SPA or soften the dependency to fix the build.

* Add a -DWANT_SPA to control inclusion of SPA
* Remove compiler errors about missing assert
@JohannesLorenz
Copy link
Contributor Author

For your most recent comment:

  • I merged your patch in, thanks for that.
  • The hard dependencies should now all be removed in 2a4ad86.
  • I can't reproduce it, since I have no Windows or Mac. Can you please provide some logs showing what went wrong when building SPA (and maybe the mentioned CMake fixes)?

@JohannesLorenz
Copy link
Contributor Author

@PhysSong Concerning the CI, I'd rather not use ExternalProject_Add, since it means building LMMS twice (and building zyn and mruby zest unnecessarily). I'd suggest to compile all CI tests with SPA support, but first, I'd like to get your Windows issues solved.

@PhysSong
Copy link
Member

PhysSong commented Nov 7, 2018

I'd rather not use ExternalProject_Add, since it means building LMMS twice

Can you elaborate it? I meant building SPA using it.

@JohannesLorenz
Copy link
Contributor Author

Can you elaborate it? I meant building SPA using it.

Oh, I think I got you completely wrong. That sounds reasonable, I'll try it out.

! Don't read the code diff, it's just refactoring, no features or fixes. !

This takes the code from SpaInstrument and refactors those code parts out
that will be common for SpaInstrument and the new SpaEffect in the next commit.
As LMMS effects are split into plugin and controls, we abstrahize into two
classes.

The description should be enough to not need/want to read the code changes.
* Turn the core-coded SPA plugin into an LMMS plugin with sub plugins for
the individual SPA effects. This removes *tons* of spa code from the core
* Like for LADSPA, a SPA manager is added.
* The list of AutomatableModels for OSC and the ability of a network port is
  abstrahized and put into Plugin (`Plugin::modelAtPort`, `Plugin::net_port`)
* Fix SPA nodeName in XML savefiles

Functional changes

* Use SPA's delete functions rather then deleting at the host
@RiedleroD
Copy link

Do the advantages / disadvantages in the PR description still apply or has the situation changed since 2018? After all, it's been almost 4 years, and some software changes quickly (usually for the better).

@JohannesLorenz
Copy link
Contributor Author

Do the advantages / disadvantages in the PR description still apply or has the situation changed since 2018? After all, it's been almost 4 years, and some software changes quickly (usually for the better).

I think they still apply.

The main use case for this PR is to have the new zynaddsubfx in LMMS. This is still not possible without this PR* - It will be possible when LMMS has Lv2 UI support, including modulation of knobs. In this case, this PR might get useless (and it might not be useful to write plugins that work with this PR).

  • You could use the new zyn without Gui in Lv2, but it's probably painfull.

JohannesLorenz added a commit to JohannesLorenz/lmms that referenced this pull request Jun 4, 2022
They were never used. Possibly they were just in the code because the
code originated from LMMS#4662 (where the virtuals would also be
omittable...).
JohannesLorenz added a commit to JohannesLorenz/lmms that referenced this pull request Dec 1, 2022
They were never used. Possibly they were just in the code because the
code originated from LMMS#4662 (where the virtuals would also be
omittable...).
JohannesLorenz added a commit to JohannesLorenz/lmms that referenced this pull request Feb 4, 2023
They were never used. Possibly they were just in the code because the
code originated from LMMS#4662 (where the virtuals would also be
omittable...).
JohannesLorenz added a commit that referenced this pull request Feb 21, 2023
They were never used. Possibly they were just in the code because the
code originated from #4662 (where the virtuals would also be
omittable...).
sakertooth pushed a commit to sakertooth/lmms that referenced this pull request May 30, 2023
They were never used. Possibly they were just in the code because the
code originated from LMMS#4662 (where the virtuals would also be
omittable...).
sakertooth pushed a commit to sakertooth/lmms that referenced this pull request May 30, 2023
They were never used. Possibly they were just in the code because the
code originated from LMMS#4662 (where the virtuals would also be
omittable...).
@JohannesLorenz JohannesLorenz self-assigned this Jun 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants