(fix) Controller: clear mapping pointer when unloading a mapping

[ronso0]

With #13842 I noticed that the controller's pMapping still points to the previously loaded mapping when loading 'No mapping'.
Is there any reason for that?

[Swiftb0y]

just call setMapping with a nullptr directly.

[ronso0]

That was the first thing I tried.
Gives me this when selecting No mapping

DEBUG ASSERT: "pMapping.use_count() == 1" in function std::shared_ptr<_Tp> Controller::downcastAndTakeOwnership(std::shared_ptr<LegacyControllerMapping>&&) [with SpecificMappingType = LegacyMidiControllerMapping] at ./src/controllers/controller.h:89

[ronso0]

mixxx/src/controllers/controller.h

Lines 82 to 96 in 815219d

	std::shared_ptr<SpecificMappingType> downcastAndTakeOwnership(
	std::shared_ptr<LegacyControllerMapping>&& pMapping) {
	// Controller cannot take ownership if pMapping is referenced elsewhere because
	// the controller polling thread needs exclusive accesses to the non-thread safe
	// LegacyControllerMapping.
	// Trying to cast a std::shared_ptr to a std::unique_ptr is not worth the trouble.
	VERIFY_OR_DEBUG_ASSERT(pMapping.use_count() == 1) {
	return nullptr;
	}
	auto pDowncastedMapping = std::dynamic_pointer_cast<SpecificMappingType>(pMapping);
	VERIFY_OR_DEBUG_ASSERT(pDowncastedMapping) {
	return nullptr;
	}
	return pDowncastedMapping;
	}

[Swiftb0y]

right, that function does not take that usecase into account. Simply add a if (pMapping == nullptr) { return nullptr; } so it supports that usecase. Alternatively you can add the appropriate handling to the setMapping implementations.

[ronso0]

Okay. I only took a brief look at this and didn't want to touch it.
But yeah, that's a straight forward solution.
Thanks!

[Swiftb0y]

Is there any reason for that?

Not that I know of, possibly lost during refactoring?

[Swiftb0y]

conceptually LGTM. Thank you. Waiting for CI.