lmms
lmms copied to clipboard
LMMS
Switch caps to submodule
The CAPS LADSPA plugins -- or more commonly known in LMMS as "C*" -- are authored by Tim Goetze and they have changed considerably over the years. The current version as of writing this is 0.9.26.
No upstream VCS exists, but moddevices keeps a viable clone of CAPS that we can safely use as an LADSPA mirror (and eventually for LV2, when we add support).
Since this involves testing presets and projects, help is needed. To compare the mapping of a plugin, export a project as .mmp (without the z) and compare the ladspa sections.
Compatibility
| 0.4 | 0.9 | coded | tested |
|---|---|---|---|
| AmpIII | -- | ||
| AmpIV | -- | ||
| AmpV | -- | ||
| AmpVTS | AmpVTS | ||
| AutoWah | AutoFilter 💡 | ||
| CabinetI | -- | ||
| CabinetII | -- | ||
| CabinetIII | |||
| CabinetIV | |||
| ChorusI | ChorusI | ||
| ChorusII | -- | ||
| Clip | Saturate 🗯Upgrade broken, see notes 0e14f39 | ||
| Compress | Compress | ||
| CompressX2 | -- | -- | |
| Eq | Eq10 ✅ 5bee27c | ||
| Eq2x2 | Eq10x2 | ||
| Eq4p | -- | -- | |
| EqFA4p | -- | -- | |
| Narrower | Narrower | ||
| Noisegate | -- | -- | |
| PhaserI | -- | ||
| PhaserII | PhaserII | ||
| Plate2x2 | PlateX2 ✅ 5bee27c | ||
| Spice | -- | -- | |
| SpiceX2 | -- | -- | |
| PreampIII | -- | ||
| PreampIV | -- | ||
| SweepVFI | -- | ||
| SweepVFII | -- | ||
| ToneStack | ToneStack, model positions switched 9b8e39ff8700fc162b369102b34961677c888a46 | ||
| ToneStackLT | ToneStack: Model 0, See comment f63ec84d698fad297cfe58c8052d1b13c3e8942c |
Supercedes #3979
FYI, Travis-CI checks are slightly misleading. It's passing for LMMS, but failing for tresf. https://travis-ci.org/LMMS/lmms/builds/366253352. It's just the exprtk submodule on my fork being behind, nothing to worry about.
First of all thanks to @tresf for initial work on the effects.
The changes are immense. Here is what I can easily do:
- [x] Change the effect names, such that for all effects, equivalent effects can be found (according to the table above)
- [ ] Map those parameters that still exist (~50-70%) to their new values (port numbers changed)
- [ ] Fix bad minimal and maximal values
What I may not want to do:
- Fix parameters due to changed algorithms/scales. The algorithms changed a lot, and IMO it would take too much effort to think about correct remappings. In order to avoid clipping, I'd rather suggest doing tests than digging into the large algorithm changes. If anyone really feels fit enough to do that however, this can still be done after my commits, but I recommend to not do it. :stuck_out_tongue_winking_eye:
- Doing it all immediately. Give me 1 or 2 months.
@tresf The compatibility table tells us which effects are planned to map. What, however, about the following?
- AmpIII, AmpIV, AmpV -> AmpVTS
- CabinetI, CabinetII -> CabinettIV
- ChorusII -> ChorusI
- PhaserI -> PhaserII
- ToneStackLT -> ToneStack
@JohannesLorenz we either drop them or do our best to map them. Sorry I realize re-reading the original description that this is not obvious.
Ideally, we'd try to maintain some form of compatibility if possible. Feel free to edit as needed.
The current version as of writing this is 0.9.24.
And as of today caps latest release reads Version 0.9.26 · October 2018
I believe Eq10x2 is to Eq2x2 what Eq10 is to Eq. So...
| 0.4 | 0.9 |
|---|---|
| Eq | Eq10 ✅ 5bee27c |
| Eq2x2 | Eq10x2 |
@tresf I think we have no other chance than finishing this PR :smiley:
I'll try to rebase this to master and try to get the code finished now.
Marking as TODO: Master commit ea98ba4daefd4055ca98f05d31dbdd3522792a01 needs to go into CAPS.
:robot: Hey, I'm @LmmsBot from github.com/lmms/bot and I made downloads for this pull request, click me to make them magically appear! :tophat:
Linux
- Linux (AppImage):
lmms-1.3.0-alpha.1.120%2Bg49eed33-linux-x86_64.AppImage(build link)
Windows
- Windows 64-bit:
lmms-1.3.0-alpha.1.120%2Bg49eed332e-mingw-win64.exe(build link) - Windows 32-bit:
lmms-1.3.0-alpha-msvc2017-win32.exe(build link) - Windows 64-bit:
lmms-1.3.0-alpha-msvc2017-win64.exe(build link)
macOS
:robot:
{"platform_name_to_artifacts": {"Linux": [{"artifact": {"title": {"title": "(AppImage)", "platform_name": "Linux"}, "link": {"link": "https://13638-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.120%2Bg49eed33-linux-x86_64.AppImage"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/13638?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}], "Windows": [{"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://13637-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.120%2Bg49eed332e-mingw-win64.exe"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/13637?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}, {"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/29d85jm07u474gsq/artifacts/build/lmms-1.3.0-alpha-msvc2017-win32.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/38849977"}, {"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/wfqelsgs72la7smi/artifacts/build/lmms-1.3.0-alpha-msvc2017-win64.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/38849977"}], "macOS": [{"artifact": {"title": {"title": "", "platform_name": "macOS"}, "link": {"link": "https://13639-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.120%2Bg49eed332e-mac10.14.dmg"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/13639?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}]}, "commit_sha": "da9e6b1401a974781af6a2e28b0e8db71fbe8aac"}
I'll try to rebase this to master and try to get the code finished now.
Thanks. Note, at some point we'll need to merge unfinished and just handle the upgrade issues as "I'm sorry" in support/Discord. Thanks for putting some time to this. I'm sure it's obvious, but I'm no longer actively maintaining my branches and PRs so please do as you need (push, close, clone, etc).
I propose to find out the knob mappings by testing (as it's too complicated to analyze from the code). This is now handled in a new sub issue #5680 .
I propose to find out the port mappings by testing (as it's too complicated to analyze from the code).
Could we first ask the developer via the Contact information on this page if they happen to know how the ports have changed? (Assuming no one has done this yet). If they do, that would save a lot of effort.
The CAPS Version Query section also seems relevant.
Could we first ask the developer via the Contact information
OK, I sent and e-mail now. The project seemed pretty dead to me, but let's still try.
The project seemed pretty dead to me, but let's still try.
Which project? Tim Goetze -- the author -- has always replied to my emails in the past. Quoting one from 2017:
Tres wrote: As we prepared our application for the latest CAPS version, we're hitting some upgrade issues from previous versions [...] is "Clip", now "Saturate" ?
Tim wrote: [Yes ...] "clip" mode the Saturate plugin is identical to the old Clip plugin, save for a small change in output volume. [...] you'll probably also have to turn off the DC-blocking filter and set the bias control to zero to achieve identical operation.
He replied in 1 day.
Of course, we don't use his source code directly from tarball but instead use a submodule managed by the moddevices team, but that shouldn't necessarily influence how "dead" the project is perceived.
In regards to submitting patches upstream, this is what Tim says:
[I'm] definitely interested [in patches], and unified diff preferred (although so far, such changes have been sparse and small enough for manual management; after all, caps is quite a small project).
His email is tim<at>quitte.de
@tresf I was under that impression CAPS was mostly dead because we had submitted CAPS PRs (small ones that were really important) which took around 1 year to get merged.
Anyways, Tim also replied to a mail I wrote to him. He said there's nothing like a mapping, it would be too complicated to find out a good mapping that fits the complex algorithm changes. When I asked how Ardour would have done it, he did not know exactly, but was thinking they don't have such a mapping. Which could mean this PR is more luxury than most users might expect (which does not mean that I dislike the idea of this PR).
this PR is more luxury than most users might expect (which does not mean that I dislike the idea of this PR).
I agree with this statement wholeheartedly but what I think we'll find as a result of merging this is the fact that the CAPS we ship is the CAPS our users use. This means that projects have no upgrade path to the latest LMMS without performing surgery on the LMMS installation. As a CAPS user myself, this means that I'll likely downgrade LMMS to open old projects. This isn't isolated to CAPS (we introduce a lot of breaking changes) but it'll be something we'll be seeing more and more in #support on Discord once the new builds go up.
My vote is to just merge this and watch people complain, tackle as needed however you also have a separate issue you created "Find out CAPS port mappings by testing #5680" to help fix the long list of plugins affected so is it OK if I leave this decision up to you @JohannesLorenz?
you also have a separate issue you created "Find out CAPS port mappings by testing #5680" to help fix the long list of plugins affected
I once again asked in #testing in discord, and there is no interest to test anything now.
My vote is to just merge this and watch people complain, tackle as needed
Agreed that we can hope that it works good enough and fix things later if required. If someone complains, at least we can ask them to test the switches.
What should we do now? Should we send this PR into a testing phase (as most PRs do), or just merge now?
What should we do now? Should we send this PR into a testing phase (as most PRs do), or just merge now?
I'm fine with either. You and I tested this quite a bit so we know it works. Most of the code is just upgrade routines anyway. It also appears the master branch of the submodule hasn't changed, so we don't have to fast-forward that either.
If someone discovers issues during testing, they will need to analyze what's wrong. Which was why I opened that "Find out CAPS port mappings by testing #5680" issue, which no one wanted to work on. So if we only discover issues that no one wants to fix, I'm for merging this without testing :smiley: If that makes sense.
I'm for merging this without testing 😃 If that makes sense.
Ok. I just realized that @zonkmachine had pointed out the following:
I believe Eq10x2 is to Eq2x2 what Eq10 is to Eq. So...
0.4 0.9 Eq Eq10 ✅ 5bee27c Eq2x2 Eq10x2
I've updated the table to reflect this (sorry for the delay), and the mapping is probably very similar to the Eq commit, but I'm not sure whether or not this task is worth holding the entire PR up. I could probably tackle it in a few hours, but I'm not sure it's worth the time.
Note that the register keyword should be removed in CAPS for C++17 support, as in #6133.
Note that the
registerkeyword should be removed in CAPS for C++17 support, as in #6133.
Thanks for the info. I mailed the CAPS author (Tim Goetze) and asked him to remove it in the next CAPS version.
The current version as of writing this is 0.9.24.
The current version is now 0.9.26 though the latest release if more of a nudge of 0.9.25 Maybe we just provide upgrade routines where we easily can and then simply leave the user with a dummy effect.
Since this PR contains lots of fixes, would it make sense to merge untested and fix issues as they come by.
Or we can just fix using the demo projects as reference. If everything loads, merge.
ToneStackLT
0.4 ToneStackLT is pretty much (se release note from caps 0.9.1 below) the same as 0.4 ToneStack with Model value:0 . Same controls. The values are hard coded here: https://github.com/LMMS/lmms/blob/32fe3e50e7d951a456764dc1692b83f812bb2a87/plugins/LadspaEffect/caps/dsp/ToneStack.h#L214 Same as the first element for ToneStack: https://github.com/LMMS/lmms/blob/32fe3e50e7d951a456764dc1692b83f812bb2a87/plugins/LadspaEffect/caps/ToneStack.cc#L44-L46
ToneStack wasn't removed until after 0.9 was released.
https://github.com/moddevices/caps-lv2/blob/master/CHANGES 0.9.24 * dropped 44.1 kHz ToneStackLT 0.9.1 * ToneStackLT rolled into ToneStack and eliminated
Finally the modpeople have something to add https://pedalboards.moddevices.com/plugins/aHR0cDovL21vZGRldmljZXMuY29tL3BsdWdpbnMvY2Fwcy9Ub25lU3RhY2s=
The "5F6-A LT" model is using the lattice filter implementation mentioned in [yeh06], operating on
precomputed simulation data for 44.1 kHz.
So, apart from the similar data there may also be a different method used for this setting and it seem to have been baked into the 0.9.1 version of ToneStack . Apparently it's hard coded for 44.1 kHz. Edit:I did a quick test with a drum loop and it looks like 0.4 ToneStackLT does really change output depending on export frequency, while ToneStack Model 0 does not.
ToneStackLT upgrades to ToneStack:model 0 in f63ec84d698fad297cfe58c8052d1b13c3e8942c
Thanks so far @zonkmachine . Just for my understanding, why did you force-push the first commit? ("Turn CAPS into submodule (#4027)")