setSpeakerArrangement - get

Audio Plugins
1

In a plugin i need to access the (VST-secific) speakerArranment, more specific: i need the “speakerIn/speakerOut” combination which was successfully set by the host, this is very important but i don’t want to hack juce source tree.
Could you simply implement attribute like speakerArrangementIn, speakerArrangementOut in AudioProcessor, Next to numInputChannels, numOutputChannels, sampleRate , blockSize.

To be more platform interdependent this could be a white-space separated string.

And this would be the translation function in the VSTWrapper (other PluginFormats could just give String::empty if its not supported)

String getSpeakerString(VstSpeakerArrangementType t)
	{
		switch (t)
		{
			case	kSpeakerArrMono:  			return	"M";
			case	kSpeakerArrStereo:			return  "L R";
			case	kSpeakerArrStereoSurround:	return  "Ls Rs";
			case	kSpeakerArrStereoCenter:	return  "Lc Rc";
			case	kSpeakerArrStereoSide:		return  "Sl Sr";
			case	kSpeakerArrStereoCLfe:		return  "C Lfe";
			case	kSpeakerArr30Cine:			return	"L R C";
			case	kSpeakerArr30Music:			return  "L R S";
			case	kSpeakerArr31Cine:			return  "L R C Lfe";
			case	kSpeakerArr31Music:			return  "L R Lfe S";
			case	kSpeakerArr40Cine:			return  "L R C S";
			case	kSpeakerArr40Music:			return  "L R Ls Rs";
			case	kSpeakerArr41Cine:			return	"L R C Lfe S";
			case	kSpeakerArr41Music:			return  "L R Lfe Ls Rs";
			case	kSpeakerArr50:				return  "L R C Ls Rs" ;
			case	kSpeakerArr51:				return  "L R C Lfe Ls Rs";
			case	kSpeakerArr60Cine:			return  "L R C Ls Rs Cs";
			case	kSpeakerArr60Music:			return  "L R Ls Rs Sl Sr ";
			case	kSpeakerArr61Cine:			return	"L R C Lfe Ls Rs Cs";
			case	kSpeakerArr61Music:			return  "L R Lfe Ls Rs Sl Sr";
			case	kSpeakerArr70Cine:			return  "L R C Ls Rs Lc Rc ";
			case	kSpeakerArr70Music:			return  "L R C Ls Rs Sl Sr";
			case	kSpeakerArr71Cine:			return  "L R C Lfe Ls Rs Lc Rc";
			case	kSpeakerArr71Music:			return  "L R C Lfe Ls Rs Sl Sr";
			case	kSpeakerArr80Cine:			return	"L R C Ls Rs Lc Rc Cs";
			case	kSpeakerArr80Music:			return  "L R C Ls Rs Cs Sl Sr";
			case	kSpeakerArr81Cine:			return  "L R C Lfe Ls Rs Lc Rc Cs";
			case	kSpeakerArr81Music:			return  "L R C Lfe Ls Rs Cs Sl Sr" ;
			case	kSpeakerArr102:				return  "L R C Lfe Ls Rs Tfl Tfc Tfr Trl Trr Lfe2";
		};
		return String::empty;
	}
2

Wouldn’t it be better to use bitwise-or of some flags rather than a string? Would be much easier and faster to check the results that way…

3

-anything which make it possible to read the speaker per channel would be cool.
Bitwise is a little bit too unclear, because you need the speakertype (which could be different from host to host) so a enum flag which can be extended in future versions would be better

Array<SpeakerType>  inputSpeaker;
Array<SpeakerType> outputSpeaker;

// enums-vals are like steinberg skd bit this is not mandantory

enum SpeakerType { unknown = -1, M = 0, ///< Mono (M) L, ///< Left (L) R, ///< Right (R) C, ///< Center (C) Lfe, ///< Subbass (Lfe) Ls, ///< Left Surround (Ls) Rs, ///< Right Surround (Rs) Lc, ///< Left of Center (Lc) Rc, ///< Right of Center (Rc) S, ///< Surround (S) // Cs = S, ///< Center of Surround (Cs) = Surround (S) Sl, ///< Side Left (Sl) Sr, ///< Side Right (Sr) Tm, ///< Top Middle (Tm) Tfl, ///< Top Front Left (Tfl) Tfc, ///< Top Front Center (Tfc) Tfr, ///< Top Front Right (Tfr) Trl, ///< Top Rear Left (Trl) Trc, ///< Top Rear Center (Trc) Trr, ///< Top Rear Right (Trr) Lfe2, ///< Subbass 2 (Lfe2) LAST };

4

?

Surely this is an ideal situation for a bitwise-or, because each speaker type can only be used once, and their order is unimportant, right? I can’t see the point in using an array.

5 
NO!!!!!!!!!  :wink: 
I want to know which channel contains which speaker, that's the most important information for me!
For example, if a plugin does special processing to the Lfe-Channel, it want to know which channel it is.

NO!!! :wink:
I want to know which channel contains which speaker, that’s the most important information for me!
For example, if a plugin does special processing to the Lfe-Channel, it want to know which channel it is.

6

Ah, I see! Sorry! Well in that case the original string idea does seem like the best plan!

7

cool

8

Hi Jules,

because i implement this functionality in my plugin right now, it would be nice to know, if you do it that way, to avoid unnecessary work…

9

I’ve checked some stuff in - let me know if it works ok for you.

10

Thanks, seems to work nice!