Update controller mappings for Behringer DDM4000 & BCR2000 to 2.5

[git-developer]

This PR updates controller mappings for Behringer DDM4000 and BCR2000 to 2.5:

• Removal of references to lodash
• Removal of a quirk that was required before Qt6
• Replacement of var with const / let

Lodash's _.merge() function performing a deep merge has been replaced. Most locations could be refactored to use a shallow merge (Object.assign()). The only actual requirement for a deep merge is in Behringer-Extension-scripts.js (for component container definitions). It is replaced by a custom implementation.

The code was tested against 2.5 using Behringer controllers DDM4000 and BCR2000.

[JoergAtGithub]

Replacing the code, that calls code marked as deprecated, is a good thing. But we must not remove the deprecated code for compatibility reasons.
Backward compatibility to existing mapping scripts (this includes non-official mappings by our users) must be guranteed. Therefore please restore the deleted code in common-controller-scripts.js and midi-components-0.0.js.

[git-developer]

Thanks for looking into this PR so quickly.

I agree that in general, removal of code without deprecation (warning) is a no-go because it could break existing code. But I think the situation is different here.

The functions I remove here were introduced recently in 2.5. deepMerge() throws runtime errors as soon as it is called (because of a missing missing script. prefix on recursive call). That means it is actually never called. setLayer() was introduced in 2.5 as variant of applyLayer() without dependency on lodash. But applyLayer() was refactored to no longer rely on lodash, so it's no longer necessary.

I'd appreciate if @Swiftb0y and @christophehenry could add their opinion on keeping or removing these two functions. They know about this topic from #14197. I will then change the code accordingly.

Ok, than it seems indeed to be a special case here.

[christophehenry]

You can remove the isSimpleObject function above.

[git-developer]

Thanks! Done.

[Swiftb0y]

@JoergAtGithub, I agree with the assessment made by @git-developer. setLayer() has only been introduced recently, so the chance that mappings rely on them is very slim. deepMerge() seems to have been broken from the start and we have not received a report on this until now, I think that this is evidence that the number of affected mappings is negligible. Wdyt?

[JoergAtGithub]

Yes, if we just added it in 2.5.0 and it's not working as intended, then I think it's best to remove it immediately in 2.5.1.

[git-developer]

I think it's best to remove it immediately in 2.5.1

I agree, it's just that this PR is currently targeted at main. setLayer() does not exist in 2.5. I can open a second PR against 2.5 and cherry-pick the appliable changes there. Would that be OK?

[christophehenry]

I don't understand… You need a deep merging algorithm after all?

[git-developer]

Yes, 1 of 4 uses of lodash's _.merge() requires a deep merge, the other 3 uses are working with a shallow merge. The scope is within Behringer-Extension-scripts.js only. It is used to merge mapping definitions of the user with defaults from the user and defaults from the mapping. Most mapping definitions simply contain data, but the ShiftButton may also reference a JS object (the target that is shifted by the button). This may cause a circular reference in the mapping description that must be considered in the merge algorithm.

This is the only case I found requiring a deep merge. No commonly used location (like applyLayer()) is affected anymore. Due to the limited scope, verifying the behavior was feasible.

[git-developer]

I removed lodash from the XML file. Now the build fails:

warning [0x56179af74560] ControllerScriptHandlerBase:
"Uncaught exception: file:///home/runner/work/mixxx/mixxx/res/controllers/Behringer-DDM4000-scripts.js:6:
ReferenceError: behringer is not defined

Backtrace: %entry@file:///home/runner/work/mixxx/mixxx/res/controllers/Behringer-DDM4000-scripts.js:6"

The mapping works in 2.5. Does the test setup require special handling when scriptfiles are included?

[Swiftb0y]

not really. I suspect its because of the change from var to const. Try changing line 6 back to var in the DDM4000 script. Add a // eslint-next-line-disable no-var above in case eslint complains.

[christophehenry]

I would advise that you keep your changes to the Behringer scripts in a separate PR so that this one is kept atomic.

[git-developer]

OK, I'll fix the tests and then split the PR.

[git-developer]

This PR is now focused on updating the Behringer mappings to 2.5. Removal of deepMerge() and setLayer() has been moved to #14203 (2.5) and #14251 (main)

[git-developer]

May I ask a related question to @christophehenry: I noticed that Registering MIDI Input Handlers From Javascript was implemented in #12781. Do you know an example where a <script-binding /> element was refactored to Javascript?

The Behringer mappings heavily rely on ComponentsJS and contain hundred of lines of XML (DDM4000 / BCR2000) just to delegate to a single input dispatcher function. It would be great if this could be simplified using JS.

[Swiftb0y]

Almost LGTM. I assume you have done a smoke test with the DDM or BCR?

[christophehenry]

Do you know an example where a element was refactored to Javascript?

Not yet. I am working on a Denon DN-S3700 controller that will use it at some point. When I'm done, I'll propose for official inclusion.

[git-developer]

I assume you have done a smoke test with the DDM or BCR?

Thanks for the reminder. I did, but not after that latest changes. All global objects require var. I changed that accordingly and made a test after the latest change, using both DDM4000 and BCR2000.

[Swiftb0y]

LGTM. Thank you raising the original issue and adressing it. Thank you also @christophehenry for being so responsive and brainstorming possible solutions as well. Thank you both.