Jump to content


Photo

Signal follower routings & multicore processing


  • Please log in to reply
2 replies to this topic

#1 OopsIFly

OopsIFly

    Guruh Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPip
  • 950 posts
  • Gender:Male
  • Interests:...daydreams... -VS- ...propaganda...

Posted 07 November 2017 - 17:07

Hi!

 

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).



#2 ffx

ffx

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2987 posts
  • Gender:Not Telling
  • Interests:macOS fanboying

Posted 07 November 2017 - 17:22

Does it change, if you route all target tracks to a bus and then modulate the bus only? AFAIK multicore processing and data exchange can be quite difficult. Surely there is a good reason for this.


MacOS 10.12.6 Retina, Renoise 3.1 64 bit   -   Tuned Shortcuts | Multi-Jump From/To Send | Quick Template | Insert Native DSP Menu (incl. deprecated)


#3 OopsIFly

OopsIFly

    Guruh Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPip
  • 950 posts
  • Gender:Male
  • Interests:...daydreams... -VS- ...propaganda...

Posted 07 November 2017 - 17:56

To a bus? you mean a send channel?

 

THANK YOU, that seems to restore parallelism! Now I have my realtime sidechain back! It is a bit clumsy workaround (as are many in renoise...), but for my first test it seems to work.

 

I put the sidechain effects (the gainers, filters, eqs that are modulated by the signal follower) into extra send channels, and sent the signal from track to there, and from there to my pre master.  Bang, glichy 78% cpu back to the expected 42%. Putting just a single modulated effect back to the track will push up the CPU load again, as if using a direct side chain forces the connected instruments to be processed in the same thread serially. The extra send channels seem to seperate the instrument audio generation, and the sidechain action that happens after the generation. It seems to be no problem to trigger each track's sidechain effect to a different send with different parameters, no need to merge them, which is what I wanted.

 

Yes multicore processing is not trivial, you need a graph to keep track what defines parameters nedded to calculate other steps, and you cannot compute things in parallel if one depends on the result of another. Seems like for renoise the splitting of graph nodes is done on track level, not per dsp.