I am experiencing problems with renoise's multicore capabilities and sidechaining work done with the signal follower.
To make it short: when a signal follower with its target, or following routings via hydras, span multiple channels, it seems to disrupt parallel multicore action, forcing the load of the corresponding channels to be processed on a single core - thus lowering the load that I can put on renoise. Projects with heavy DSP will seem to easily run on my machine first, but as soon as a sidechain is set up they overload the cpu capabilities and glich out, making it impossible to work on with them.
For example in my current working tune I have only three instruments yet, but each having pretty complex/demanding processings inside the inst.fx. It is a pure native dsp project. All audio is routed to a "pre master" send with sends in the respective channels, so I have a primitive mastering/rough mix chain but still can monitor stuff totally dry. Normally the thing eats like 60% cpu with all three instruments going. As soon as I install hydras on the drum instrument's sidechain dc track, and link it to gainers of the other instruments channels, or their ambience output channels, tune rises up in cpu usage massively leading to dropouts. If I disable something in the Sidechain setup it is still the same. However if I delete modules from the dc chain, the hydra spreading the signal, or signal followers themselves, so no chain is set up anymore, the cpu usage falls down to the expected again. Sometimes multicore seems to be evaluated differently also, for example I set up a sidechain as a test last night, and the tune was high in cpu but barely glitching, after loading it tody it wouldn't work without much heavier dropouts any more until I broke the chain again.
This is very unfortunate. I'll try to finish the tune anyways, shifting the sidechain work to a second module with rendered tracks audio, hopefully this traditional approach will be light enough on the cpu. Not being experienced yet I fear the idea not being able to adjust instruments parameters in realtime to make the sidechain action even snappier.
Any takes/opinions on this? I could imagine the workload thread handler being rather conservative on breaking parallelism whenever there is any connection - though in this case the load could still be split, calculating the heavy instrument fx in parallel and then processing the much lighter track dsp in series afterwards. I don't know if what I'm trying to do is just stupid, but for me as a beginner in the art it feels easiest, most natural to me to do it this way (realtime dsp mixing/sidechaining instead of rendering stems and then mixing).