When Will We Be Getting Sidechaining?

I was just wondering if there are any huge technical issues inherent in implementing sidechining… as far as I can tell, all that’s really needed is a peak-listening metadevice, and a metadata-send device… I was really kinda shocked, considering how useful it would be, and how seemingly simple it would be to code, that it didn’t make it for 2.0 beta. Any big reasons why? … and when can we expect it, if at all, in the future?

Geez, front the $80 for the plug-ins already:

http://www.db-audioware.com/sidechaincompressor.htm
http://www.db-audioware.com/sidechaingate.htm

Honestly, why is this even a discussion anymore? There’s a solution, it’s not the free one you want but “sidechaining” is a big fail when compared to more flexible features like modular routing which would probably also include sidechaining as a small inconsequential artifact of the whole.

My guess is 5 years.

I’m still waiting for the Cher effect!

See above plug-ins.

If what you state is true, then this is a wonderful business opportunity for someone from the community to provide similar plug-ins for a cheaper price and make a few dollars, or become an open source hero by giving it away.

Your choice.

It’s a fair question. Only taktik can answer this in detail, but yes, there is a technical problem (not unsolvable, but quite some restructuring and hard work I guess). The technical way the trackstructure and how the audio engine work with tracks, there is a problem to make the tracks interact with each other on an audio<->Parameter signal level.
If this was very easy to do you could bet this would already be there.

I’m open for modular routing as well. I just want the ability to sidechain ANY parameter to the amplitude of a track. I will definitely check out those plugs for ducking and keying though.

From what I can tell, it’s impossible to feed metadata back into Renoise from a VST plugin, otherwise I would have done this already. I need to be able to control any parameter with audio peak data… not just compress/gate.

Thanks Pysj… I figured there must be a technical issue, but I figured I’d ask just to be sure. At bare minimum I would have liked a peak-monitoring metadevice that just sends to effect params on the track it’s sitting on… but if the audio engine and the parameters are that far removed from one and other, I guess I’m outa luck.

My guess is when bamboos flower. :D

I’ll also be pleased beyond measure to see native side-chaining available.

To be more specific, though I might remember this completely wrong, but I think there is a problem how renoise calculate audio in first track, then goes on to the next track and so on. This way there will for instance be a ‘problem’ if the audio signal on the last track will change something on the first track etc. Right now there is no foundation in renoise to make different tracks freely interact with each other like that.

so? make it go only left to right then, it would still rock so much!

sidekickv3 is free and works pretty well.

AFAIK Sidekick sends the output of a track to a virtual channel which you can only use to duck/key the volume of another track. But is it all side-chaining is about?

What if the user wants to control the amount of distortion by another track’s output? or any other parameter of any other dsp?

So chances are there’s no issue with creating an audio peak metadevice that doesn’t interact with other tracks? Because this would be very useful as well :)

I think this is also the reason that send tracks’ output cannot be routed to a previous send track. A side-chaining meta-device could also behave the same, affecting next tracks only.

I’ve just tried out Klanglabs Microgater, it’s much simpler to operate than Sidekick (with the proper note<>fx routing in Renoise2 :) )

Edit:working link

Thanks for sharing. Tiny and cool :)

i agree byte smasher more than ever :)

This is a problem every audio application has. If you allow this, you can no longer process audio in blocks (multiple samples at “once”) but have to calc the whole audio graph sample by sample to reduce the possibly introduced delay to a sample. Processing only a single sample is slow like hell and definitely no option for us.
But we could do this as we do it with the sends, only allow routing in a defined order…

Beside of this problem that, side-chaining is not THAT hard but also not easily done. We’ll get it some when, hopefully, as soon as we know how to integrate it properly - GUI wise. You all know my problem: There are 1000 other useful features and improvements in the queue… There are tools/VST to get sidechaining effects, so its not really that big problem, isn’t it?