Revert "Samplers: don't create unneeded empty samplers during startup"

[ronso0]

This reverts the core commit of #12657

Besides the Numark Mixtrack Pro3 #12808 other mappings slipped through in #12769.
I'm at it but I can't guarantuee to fix all of them in time.
Also, user mappings may be broken, too.

Let's push #12657 to 2.4.1

To summarize: the mapping control error can still occur if

• samplers.xml doesn't exist / is broken
• loading a mapping that needs N samplers
• before loading a skin that provides N samplers

[ronso0]

I think in order to not require users to create expected decks and samplers explicitly in script files this could be done where control existence is checked in ControllerScriptInterfaceLegacy:

• if control refers to a deck/sampler > current deck/sampler count
  • if control exists for deck/sampler 1 which is always created
    • create deck/sampler, map control
  • else throw error

[ronso0]

ping

Let's merge this in order to not release 2.4 with an annoying regression (primarily for user mappings, since I'm confident I fixed all built-in mappings in #12810).

[daschuer]

Oh, I am sorry this topic has put extra workload stress on you.

I am not sure if merging this is a good idea. Do we hunt one regression (now only in custom mappings) with another, the performance regression and the reason we have created dedicated sampler skins?

What is the effect when a mapping requests missing samplers? I think using a sampler without a GUI is unlikely. The assertion about the missing control is easy to fix. Probably more easy than a latency increase.

After merging this, we have hard time to identify the not updated mappings.

In general it is probably also questionable if mappings should be allowed to control samplers without a GUI.

[ronso0]

Oh, I am sorry this topic has put extra workload stress on you.

Never mind, it was my mistake to not do a smoke test with my regular setup. I'd have noticed right away.

Tbh I didn't measure the performance implication of 64 unneeded samplers. Should be about more memory being used, not really CPU load (no sampler loaded --> no caching reader work, no engine buffer work IIUC).
And no one noticed or cared about for years, so I think this is no big deal for now.

What is the effect when a mapping requests missing samplers? I think using a sampler without a GUI is unlikely.

The GUI samplers are created after the mapping has been loaded, that's the issue.
That's the sample deck reation order:

• CoreServices::initialize triggers creation of the default samplers (4 currently) here, line 309
• a bit later, same function, samplers.xml is read here, line 431
  for example: 64 samplers, tracks in samplers 1-12, = 12 samplers are created
• (MixxxMainWindow is initialized)
• main.cpp triggers controller setup here, mappings are loaded
• skin is loaded, skin manifest requests 16 samplers in LegacySkinParser::parseSkin

The assertion about the missing control is easy to fix.

Not sure what you have in mind. Something like I expressed above #12809 (comment)

In general it is probably also questionable if mappings should be allowed to control samplers without a GUI.

Hmm, not sure about this.
Also, that can not be detected reliably: we know if a mapping conatins a direct xml mapping for a deck/sampler control, or tries to make a connection to one, but such a control also be in a mapping function and IIUC we would only know about this when the function is executed because that's when it's evaluated.

Bottom line:
I recommend to merge this and work on a fix for 2.4.1 or 2.5

[daschuer]

OK, than lets merge it. Thank you for explaining.