Switch caps to submodule

[tresf]

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 9b8e39f
ToneStackLT	ToneStack: Model 0, See comment f63ec84

Supercedes #3979

[tresf]

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.

[JohannesLorenz]

First of all thanks to @tresf for initial work on the effects.

The changes are immense. Here is what I can easily do:

• 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. 😜
• Doing it all immediately. Give me 1 or 2 months.

[JohannesLorenz]

@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

[tresf]

@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.

[zonkmachine]

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

[JohannesLorenz]

@tresf I think we have no other chance than finishing this PR 😃

I'll try to rebase this to master and try to get the code finished now.

[JohannesLorenz]

Marking as TODO: Master commit ea98ba4 needs to go into CAPS.

[JohannesLorenz]

@mrkline Can you please open a PR of your changes of ea98ba4 against moddevices/caps-lv2?

[JohannesLorenz]

sorry, accidentally closed

[LmmsBot]

🤖 Hey, I'm @LmmsBot from github.com/lmms/bot and I made downloads for this pull request, click me to make them magically appear! 🎩

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

• macOS : lmms-1.3.0-alpha.1.120%2Bg49eed332e-mac10.14.dmg (build link)

🤖

{"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"}

[tresf]

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).

[JohannesLorenz]

@mrkline I submitted the patch for you now.

[JohannesLorenz]

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 .

[zonkmachine]

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.

[Rossmaxx]

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.

[Rossmaxx]

Something minor i found at first glance.

[zonkmachine]

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:

lmms/plugins/LadspaEffect/caps/dsp/ToneStack.h

Line 214 in 32fe3e5

setparams (250000, 1000000, 25000, 56000, 0.25e-9, 20e-9, 20e-9);

Same as the first element for ToneStack:

lmms/plugins/LadspaEffect/caps/ToneStack.cc

Lines 44 to 46 in 32fe3e5

	/* { 250000, 1000000, 25000, 56000, 0.25e-9, 20e-9, 20e-9 }, DY */
	/* Fender */
	{250 k, 1 M, 25 k, 56 k, 250 pF, 20 nF, 20 nF}, /* 59 Bassman 5F6-A */

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.

[zonkmachine]

ToneStackLT upgrades to ToneStack:model 0 in f63ec84

[JohannesLorenz]

Thanks so far @zonkmachine . Just for my understanding, why did you force-push the first commit? ("Turn CAPS into submodule (#4027)")

[zonkmachine]

Thanks so far @zonkmachine . Just for my understanding, why did you force-push the first commit? ("Turn CAPS into submodule (#4027)")

I had rebased again on latest master.

[tresf]

CI says:

- /__w/lmms/lmms/plugins/LadspaEffect/caps/caps-lv2/dsp/v4f.h:40:26:
- error: SSE vector return without SSE enabled changes the ABI [-Werror=psabi]

[bratpeki]

@tresf Can your LMMS fork, under the "caps" branch, be used for reliably testing the 0.4-0.9 difference? If so, I'll get to work testing the missing plugins.

[tresf]

@tresf Can your LMMS fork, under the "caps" branch, be used for reliably testing the 0.4-0.9 difference? If so, I'll get to work testing the missing plugins.

I would assume so?

[bratpeki]

What I mean is: If I were to make two projects, one in master LMMS and one in your fork, such that they contain only one plugin on the master track, would the only difference be that plugin data? Has nothing else changed in the process?

[tresf]

What I mean is: If I were to make two projects, one in master LMMS and one in your fork, such that they contain only one plugin on the master track, would the only difference be that plugin data? Has nothing else changed in the process?

• The word "plugin" is a bit ambiguous here, CAPS exposes many plugins
• This PR should be fast-forwarded so that the baselines are identical

That said, I think what you're describing is correct. We haven't done any major plugin data restructuring as a result of this PR and any upgrade routines that this PR ads should only affect upgrades from older LMMS versions, not new projects, assuming no mistakes were made. 🍻

[bratpeki]

The word "plugin" is in reference to the specific CAPS plugin placed on the given mixer track, for any mention of the word, you can be sure I meant it as such.

Regarding the answer, that sounds great, I'll download your fork and build it, and get to testing!

[bratpeki]

ChorusI

The input port has been moved from the first to the second-to-last position.
This means that all the port values are offset by one port position.

Reordering the ports fixes the issue.

The relevant part of the diff is:

 PortInfo
 ChorusI::port_info [] =
 {
+       { "in", INPUT | AUDIO },
+
        { "t (ms)", CTRL_IN, {LOG | DEFAULT_MID, 2.5, 40} },
        { "width (ms)", CTRL_IN, {DEFAULT_LOW, .5, 10} },

@@ -109,7 +111,6 @@ ChorusI::port_info [] =
        { "feedforward", CTRL_IN, {DEFAULT_LOW, 0, 1} },
        { "feedback", CTRL_IN, {DEFAULT_LOW, 0, 1} },

-       { "in", INPUT | AUDIO },
        { "out", OUTPUT | AUDIO }
 };

I'll do more testing and confirm.

@tresf What do we do about the missing ChorusII? Are we dropping it?

[tresf]

@tresf What do we do about the missing ChorusII? Are we dropping it?

@JohannesLorenz asked a similar question, quoting:

@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

I just created a test project to check for audible differences between ChrorusI and ChorusII and they're quite different. Since the ports should be a 1:1 map, I'm fine with mapping these over, but it won't sound right, so we would want to issue some type of soft warning if we do (e.g. "C* ChorusII" plugin is no longer available, "C* ChorusI" was used instead).

My best guess is that ChorusII just didn't sound good enough to the author of CAPS plugins to justify keeping around. That's not to say people didn't take advantage of it in projects and those projects won't sound right after this upgrade. In my opinion, ChorusII makes instruments sound "tinny" with more high-pitched feedback added. ChorusI in my opinion sounds more "full", it seems to add a feedback effect in a fuller frequency range.

Replacing a plugin with one that sounds different is likely to attract some strong opinions. I'm fine with either the decision to remove or replace. In both cases, the project won't sound right.

[bratpeki]

I'm fine with either the decision to remove or replace.

I feel like replacing could be possible if we make our own fork, but shouldn't be done.

My argument is mainly that the maintainer of it felt that it wasn't necessary, and there's little reason to doubt such a decision. Also, it alleviates our headache and makes 1.3 happen sooner.

So I'm all for dropping it, the user is gonna get a message that the plugin has not been found anyway, and we'll list the dropped plugins in the 1.3 changelog.

[bratpeki]

so we would want to issue some type of soft warning if we do (e.g. "C* ChorusII" plugin is no longer available, "C* ChorusI" was used instead)

That also sounds nice, but I wouldn't keep it around for longer than 1.3.x.

[tresf]

That also sounds nice, but I wouldn't keep it around for longer than 1.3.x.

Just note that all upgrade routines live essentially forever. Unless there's a justification to remove a routine, there's not much cost to keep it around.

[bratpeki]

Alright, I'll then move on to the other plugins, to wrap it up.

[JohannesLorenz]

There are also some other possibilities:

1. Ask the author why they removed the mentioned effects and especially how they imagine a DAW should handle if a user still has presets for those. I just sent out a mail and will wait for reply.
2. We could port those removed effects into our fork, so they still exist there.
3. Another proposal: We deliver both 0.4 and 0.9 libraries with LMMS (but hide 0.4 for new projects). That way, users can finally use the new libraries, but the old projects will load without change. A disadvantage is the doubled compile time, it would be interesting if someone can give the compile times on a typical desktop for both 0.4 (LMMS master) and a version with 0.4 and 0.9, and compare the compile times.

[bratpeki]

Now that we see that this isn't as easy as thought in 2017, maybe a re-vote would be in order?

I think we should just move this to v2.0, since we can then break compat without any worry.