Since we need it here in Sound Radix, we've added side-chain support to JUCE, in addition to some foundation for adding multi-out support in the future.
- Side chain support was added for AU, RTAS, AAX, VST3 effects. An "Accepts Side Chain" configuration option was added to audio plugins in Introjucer.
- AudioProcessor now has a concept of multiple input and output elements (or busses), each with a specified number of channels.
- The plugin wrappers use AudioProcessor's support for multiple input elements to configure it with a side chain, when one is connected in the host.
- processBlock prototype remains the same, it gets a single AudioSampleBuffer which contains a flat list of all channels of all input elements on function entry, and should return a flat list of all channels of all output elements on function return. The processor can be queried to find out the elements/channels configuration.
A squashed commit with all changes made so far is here:https://github.com/soundradix/JUCE/commit/7fa7ad7c815d1835293e6b6b61185861f06d5fd5
I went ahead and pulled your fork and am taking a look at it. I really appreciate that you've released this for the community.
We have a plug-in with 4 inputs (2 normal, 2 sidechain) and 4 outputs (2 normal, 2 aux), or basic mono (1 in 1 out no sidechain). In Introjucer, how would you recommend setting up the the channel configurations?
I see the "Plug-in Accepts Sidechain" tickbox. Would I then specify channels as {1, 1}, {2, 4}?
Overall, it looks good! Would have been nice to have seen you follow JUCE's coding style to make this an even easier task of putting the code in, though. (e.g.: [url=https://github.com/soundradix/JUCE/commit/7fa7ad7c815d1835293e6b6b61185861f06d5fd5#diff-a9b0326a9270852f135d6caaa689b532R135]Not always using allman style braces[/url], [url=https://github.com/soundradix/JUCE/commit/7fa7ad7c815d1835293e6b6b61185861f06d5fd5#diff-a9b0326a9270852f135d6caaa689b532R839]not consistently using spaces between function name and parantheses containing parameters[/url])
The only thing that's a bit strange is the fact that you split the setting of I/O speaker arrangements in an AudioProcessor. I can't see any reason why someone would call setInputSpeakerArrangement() and setOutputSpeakerArrangement() separately. In doing it the way you've implemented, there's a risk someone could call only one, when it would be important to set both!
While AudioProcessor now has general support for an arbitrary number of input elements, I've only integrated support in the rest of JUCE (Introjucer+wrappers) for a *single* input side-chain, which has the same number of channels as the main normal input element. So if what you're looking for is a main stereo input element + a side-chain stereo input element, you can do that. But if you're looking for 4 seperate elements (each of which may be mono or stereo), that's not supported yet.
Similarly, while AudioProcessor does now have support for multiple output elements, the rest of JUCE still doesn't integrate this support.
Regarding channel configurations in the Introjucer, each channel configuration is still just two numbers - the first one for the number of channels in each input element, and the second for the number of channels in each output element. The only exception is that even when specifying 2 channels for input elements, some plugin formats only support a mono side-chain, so that's what you are going to get.
There is currently no need (or support) for adding a channel configuration for the input side-chain which is different from the one for the main input.
I mean we bought Juce 3 just to have legal way to have up to date Juce code to apply patches for adding VST\AAX\AU plugins aux outputs and such
We do not use any newer functionality - just same old skinned sliders and buttons as 99 percents of audio plugins out there
After that I though that may be you, after all these years, finaly have any plans for adding these essetial things to plugin wrappers as it is a majotr PITAS to merge older code patches by hands to every new Juce update (as updates have some OS compatibility fixes)
Maybe you misunderstood me.. I meant that bumping the thread won't make any difference because this is already a high priority feature that we'll definitely do!
I've bought JUCE 3 (after buying JUCE 2) just to have legal access to updated VST/AU/AAX polugin wrappers with new features, and never used it (since obviously there were no updates)
and now it looks like I will have to pay for JUCE 4
Sorry to bring this up again but I agree with the majority of developers here, that the sidechain feature is lingering in the limbo of the "contributed code" since too many _years_ now, and every time one has to do a major update of JUCE (me, now), that code always causes confilcts and merge issues.
+1 for having it added soonish, despite the amazing, cool, cutting-edge things waiting to be released in JUCE 4. I know this is a boring task compared to that, but still, out here there are a lot of developers needing just that for now.
Definitely not forgotten, we had code contributed but it needs a lot of work before it can become part of the library, and we've been juggling the priorities of lots of tasks and it just hasn't been possible yet. My most honest answer is that it'll probably be task number 1 on our list of post-V4-launch things to do.
