Implement SPA support (enabling zyn-fusion) #4662
Conversation
|
@JohannesLorenz I can't drop OSC models to existing automation patterns because it's not implemented yet. Are you going to implement it? |
|
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. |
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)
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.
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
For travis, I think it should suffice to add the changes to |
There's a CMake alternative of it, |
|
Some more issues I've found so far:
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
|
For your most recent comment:
|
|
@PhysSong Concerning the CI, I'd rather not use |
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
Commit f288137 extended the MIDI range, but the DataFile upgrade did not handle spainstruments (because they are not on master). This commit fixes this.
This enables files for checking against the [LMMS coding conventions](https://github.com/LMMS/lmms/wiki/Coding-conventions). There is no strategy for automatic testing yet.
|
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).
|
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...).
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...).
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...).
They were never used. Possibly they were just in the code because the code originated from #4662 (where the virtuals would also be omittable...).
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...).
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...).
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:
keep the F1 key pressed, in contrast to LMMS, where it's the control
key)
What still needs to be done:
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:
SPA are a few hundred LOC, LV2 comes with a whole folder plus the DPF lib)
What to do with this?
itself) if it will ever be merged.
adopt a plugin API that's only supported by a small number of plugins
different, requiring at least some kind of converter
Thanks to...
... everyone helping with this. Especially: