Thanks to @Hshevitz and another user, I could fix the issue now. The problem was indeed caused by a change I made in version 3.4.1.
TomC I’d be very interested to know what the problem is.
Caution, this will get technical 😉. Stage Traxx uses a low level audio framework from Apple called AVAudioEngine. In this framework you build a graph of interconnected audio nodes that each perform a specific function. The graph Stage Traxx uses has up to around 50 nodes. For multitrack playback for example ST3 needs 6 audio player and 6 eq nodes for a single song. To be able to crossfade you need the same number for the second song playing in parallel. And then there are lots of additional utility nodes, gain staging nodes, mixing nodes, time shift nodes and so on.
Now to preserve system resources (cpu & memory) and therefore prolong battery life, ST3 tries to only load what is necessary. So if you only play a single track, there will only be about a dozen or so nodes active. But this also means that parts of the graph needs to be rebuilt. This is also necessary when switching from one audio format to another (like mono -> stereo or 44.1kHz -> 48kHz). Now up to version 3.4.0 a part of the graph was rebuild every time you changed to a new song even if the audio format did not change.
In 3.4.1 I tried to make this more intelligent and will only rebuild the graph when the audio format changes. Another optimization I made was that the nodes have not been completely detached from the audio engine, but only disconnected, reconfigured and reconnected.
And here I suppose a bug in the AVAudioEngine framework prevents switching between mono and stereo in the time shifting node while staying attached to the audio engine. Other nodes have no problem with this and the time shifting node also has no problems with all other format changes.
So the fix is to not only disconnect this node when the audio format changes, but also detach it from the audio engine and immediately reattach it. This seems dumb and it is dumb but it works. But I will submit a bug report to Apple and maybe sometime in the future I can change this to the more streamlined approach. In the meantime we are wasting a couple of cpu cycles but have a solid workaround.