COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :
Old 02-26-2012, 05:45 AM   #1
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default Thoughts on IPlug Channel Configs

I have been looking at improving the way IPlug deals with IO configurations. The current PLUG_CHANNEL_IO definitions work fine for VST2, which has no concept of side-chains or buses (grouping of outputs/inputs), but Audiounits, VST3 and RTAS do have these concepts and I think that the current PLUG_CHANNEL_IO string is not adequate for dealing with all possible situations. It gets more complicated for surround plugins because these formats also determine speaker layouts for buses and a 5.1 or a 6.0 bus, for instance has the same number of channels. Also some formats have limitations, like RTAS, which will only allow a mono side-chain input.

Here is a list of possible channel IO situations, including basic ones that are used often, and less common ones. Plugins will sometimes support multiple configurations.

----------------------------------
- mono to mono effect
- mono to mono effect + mono aux input
- mono to mono effect + stereo aux input

- mono to stereo effect
- mono to stereo effect + mono aux input
- mono to stereo effect + stereo aux input

- stereo to stereo effect
- stereo to stereo effect + mono aux input
- stereo to stereo effect + stereo aux input

- n to n effect - for instance a filter that should be able to process on a mono-mono track or an 8-8 channel track (for example), or anything in between where the number of inputs matches the number of outputs

- n to m effect - for instance a panner plugin that takes a mono source and pans to a 5.1 bus

- instrument with mono output
- instrument with stereo output
- instrument with a multichannel bus output (e.g. 5.1)
- instrument with multiple output buses (e.g. multi-timbral synth or drum synth). Those buses could be mono or stereo.
----------------------------------

I think this can hopefully be dealt with by extending the PLUG_CHANNEL_IO string to explicitly specify side-chain inputs and possibly output buses. I want to add a method like GetIOConfig() that can replace the current situation where you have to check individual connections, and instead just give you an index to determine which IO config out of the list in PLUG_CHANNEL_IO is currently set up.

for instance this would specify a mono/stereo effect with an optional mono/stereo side-chain (wouldn't work for VST2 since there is no way to identify the sidechain input, but it probably would for the other formats).

#define PLUG_CHANNEL_IO "1-1+0 1-1+1 1-1+2 2-2+0 2-2+1 2-2+2"

for a drumsynth with four stereo output buses, which may or may not be connected, perhaps something like:

#define PLUG_CHANNEL_IO "0-2 0-2.2 0-2.2.2 0-2.2.2.2"

Anyway i thought I would post this just in-case anyone has any bright ideas or thoughts about the best way to deal with this. For my purposes I am not too concerned about supporting a huge number of cinema oriented surround formats, but I would like to get side-chains and multi output buses working nicely.

oli
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Old 06-20-2012, 01:19 PM   #2
sstillwell
Human being with feelings
 
Join Date: Jul 2006
Location: Cowtown
Posts: 1,562
Default

At one point I had my personal repo set up to use almost exactly the type of I/O string you specified in your first example... 1-1+1 being mono in, mono out, mono sidechain/aux input. It worked in VST2 because I made sure to add the number of sidechain inputs to the total number of inputs when parsing the string. You obviously have to keep track of the number of allowed and connected sidechain channels and expose that information to the plugin so that you can tell the difference between 1-1+1 and 2-1...I think that was where my model started to break down.

The latter example I have no opinion on...none of my stuff to date has required multiple buses.

Do any of these I/O string variations cause issues with AUs? Those strings get reported to the host (unless we reformat/sanitize them)...hosts won't understand our variations, will they?

I would like this to go forward as well...thanks for the good writeup.

Scott
__________________
https://www.stillwellaudio.com/
sstillwell is offline   Reply With Quote
Old 06-20-2012, 01:43 PM   #3
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

Quote:
Originally Posted by sstillwell View Post
Do any of these I/O string variations cause issues with AUs? Those strings get reported to the host (unless we reformat/sanitize them)...hosts won't understand our variations, will they?
They don't get reported directly, even though they are similar to what you see in auval... the string is parsed in IPlugBase::IPlugBase() and in IPlugAU::IPlugAU() a BusChannels struct is set for each input and output bus. The host queries the kAudioUnitProperty_StreamFormat property which reports the audio stream format for the specified bus. It's not quite that simple though, Schwa seems to have worked out how audiounits work under the hood, and bypassed a lot of the Apple base classes...which makes it quite hard to understand because even if you use the apple base classes the documentation is pretty weak on this stuff.

I think a channel IO string where dots delimitate buses might be OK, like

"1-1 1.1-1 2-2 2.2-2" = mono - mono (+ optional mono sc) or stereo - stereo (+ optional stereo sidechain)
"0-2 0-2.2 0-2.2.2 0-2.2.2.2" = up to 4 stereo output buses
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook

Last edited by olilarkin; 06-20-2012 at 02:21 PM.
olilarkin is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:44 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.