Sidechain Compression? Possible with VST?

[SJ_Digriz]

These are band news. Hope they won't go this route as they already have everything needed for side-chaining. The only thing that's missing is a modern routing capabilities within Cubase.

I'm not a developer but I messed with the SDK just to figure out what was actually taking place. I have just been following the VST conversations since then. It is possible that I am confused about what they are saying will be done. But it sounds to me like there are going to be both VST call and Host changes to support sidechaining.

If there are changes on the VST side to take advantage of the new configurations then I "assumed" that rewrites are in order. I could be VERY wrong there.

[kritikon]

You don't even need SX3 for sidechaining. I can verify it works well within SX2.2 also. Use a quadro group and what SJ Digriz said.

It's a little bit long-winded to setup, but it doesn't take a PhD in computing either.

[citizenchunk]

It will require every developer to write the feature into each plug.

These are band news. Hope they won't go this route as they already have everything needed for side-chaining. The only thing that's missing is a modern routing capabilities within Cubase.

i suppose that's one way to look at it. true, the capability exists (we've both done it), but it is clumsy in most hosts. in a more "progressive" host, like Tracktion, making a sidechain connection is as easy as drawing a wire. same goes for Reason, only that is a closed system.

still, i can't see the harm in adding "official" sidechaining to the spec.

== chunk

[SJ_Digriz]

still, i can't see the harm in adding "official" sidechaining to the spec.

You misunderstand Aleksey's post. He is saying the there is already the required plumbing in the vst spec. You can already declare the number of audio channels and route the data accordingly. Aleksey knows about 4 million times more than I do about VST so I would not argue with him directly.

BUT, <DISCLAIMER> I am not a competent dev, so I could totally have this wrong</DISCLAIMER> What the VST spec does NOT contain is direct access to other tracks. You have to write a 2 piece VST and send audio to yourself in the background without Cubase/Nuendo knowing that it is taking place. My limited understanding is that you will be able to access the downhill track array directly. I have NFC how that is being presented in the spec. Again, that is just an overview I took from reading a combination of about 400 summary e-mails for the SDK news.

[PeterL]

Side-Chaining in SX (here we are again):
http://www.kvraudio.com/forum/viewtopic.php?t=72851

[citizenchunk]

still, i can't see the harm in adding "official" sidechaining to the spec.

You misunderstand Aleksey's post. He is saying the there is already the required plumbing in the vst spec. You can already declare the number of audio channels and route the data accordingly...

actually, i think you are misunderstanding my post. as i wrote before, i realize that sidechaining IS entirely possible with the current spec. i know this because i have done it, and i am using this 4-input method in a plugin. we also both agree that the current SDK could sustain a more comprehensive sidechain implementation IF the current version of Cubase (and other established hosts) offered more flexible routing. on these 2 points, we agree.

the above quoted statement was merely an answer to this statement:

...[This is] [bad] news. Hope they won't go this route...

because, personally, i don't really mind them changing the spec, and i don't think it could hurt. Whether one uses the 4-input method or the (rumored) sidechain protocol is up to the individual.

== chunk

[Blue Cat Audio]

If you do not need real-time, you can use our Digital Peak Meter Pro to do some post-processing side chaining (not only compression, can be applied to any parameter of any effect):

http://software.bluecatonline.org/

It should work with any VST host that supports automation copy/paste.

BTW I agree with the general statement that most hosts do not support all configurations they should support. But isn't it due to the fact that VST specification is a bit unclear? Maybe using 'profiles' would have helped: it seems that many functionalities are not 'mandatory', many uses are 'optional. It's really tricky to have a plug-in using 'advanced' functionalities that works on more than one host!