Add support for stem in the engine

[acolombier]

This PR refactors the engine to prepare for stem mixing.

Currently, all stems are mixed at the deck level, and continue into the mixer and affect manager as a stereo channel.

Future work will allow the deck to embedded its own effect manager so it can be applied to stem individually.

Depends on #13044

[daschuer]

Does it make sense to allocate new memory if a STEM track is loaded and discard it if another track is loaded and than allocate it again if a new STEM track is loaded?

[acolombier]

I guess it depends.
In the one hand, I guess we could always allocate memory assuming that maximum number of supported channel, but in the other hand, it feels like a waste to always allocate this max, while many user will probably not use STEM in the early days of the new feature.

Perhaps a good middle ground would be to allocate stereo, them if a STEM gets loaded, re-allocate memory to support stem and keep it as is going forward?

[daschuer]

Yes, you are probably right. Than let's stick with the dynamic allocation. This is beneficial if we think to 64 Sampler skins.

[acolombier]

That is not a question IMHO, because mono Rubberband destroys the stereo effect and makes no compatibility.

Isn't it a problem we accepted to go with anyway in #13143 and with the user prompt about it? My thoughts was, if the benchmark shows better result, have mono processing for both stereo and stem track when "multi threaded RB" is on, only stereo processing on stem otherwise.

[daschuer]

Isn't it a problem we accepted to go with anyway in #13143 and with the user prompt about it?

Yes.

My thoughts was, if the benchmark shows better result,

I am pretty sure benchmarks will show better results, especially on high number of cores, but since the quality is worse and the user expects the best quality when using Rubberband, the default should be stereo processing with four threads in case of stems. The rest can be optional, along with explanations.

[acolombier]

I have added the multi threaded rubberband logic:

• If Multi threaded is off, stereo channel will be treated together
• If on, stereo and stem decks will be treated in mono

I have also added more logic to try and optimise the channel per worker depending of the core, as no every setup would have a 8 cores or more

[daschuer]

Here some comments

[daschuer]

Thank you. Just left some final comments. We have also a conflict.

[daschuer]

LGTM, thank you.

[ronso0]

@acolombier Why was this change necessary?
Thing is, with #12194, Apply will reapply the soundconfig unexpectedly for no obvious reason which causes a playback pause.

[acolombier]

This was necessary to update the dual threading components, but I guess it could have been in loadSettings