Do you need IN chnls different to OUT chnls in a reverb?
- KVRAF
- 4030 posts since 7 Sep, 2002
I'm currently working on implementing a more seamless multi-channel support in most Voxengo plug-ins. Currently used 'global setup' (e.g. in Pristine Space) scheme does not work well and usually causes headaches, esp. when switching between stereo and multi-channel configurations frequently.
The most simple way to do it is to bundle several DLL files with name suffixes like _1, _2, _4, _6, _8 (_1S, _2S - for side-chain capable plug-ins) which will denote number if input and output channels available. The only drawback of this is that you will be able to load presets using built-in preset manager only - the host wouldn't allow to share presets between different channel configs as each plug-in will have its own internal ID.
Another drawback: having different input and output number of channels may be problematic in this case.
That is why I'm running this poll. I have mentioned reverb plug-in because this is probably the only plug-in (apart from side-chain capable plug-ins) which may benefit from differing number of input and output channels.
Another thing to consider: due to numerous requests so far I'm also planning to change Voxengo plug-in naming scheme. I still plan to leave 'brand prefix', but would like to reduce it to 'Vox'. But most importantly, the name of the plug-in will be also minimized (I will try to keep it under 8 characters). For example, 'VoxPSpace.dll' instead of 'VoxengoPristineSpace.dll'. In case of 8 channels config it may look like 'VoxPSpace_8.dll'. If somebody against this naming scheme, please let me know.
The most simple way to do it is to bundle several DLL files with name suffixes like _1, _2, _4, _6, _8 (_1S, _2S - for side-chain capable plug-ins) which will denote number if input and output channels available. The only drawback of this is that you will be able to load presets using built-in preset manager only - the host wouldn't allow to share presets between different channel configs as each plug-in will have its own internal ID.
Another drawback: having different input and output number of channels may be problematic in this case.
That is why I'm running this poll. I have mentioned reverb plug-in because this is probably the only plug-in (apart from side-chain capable plug-ins) which may benefit from differing number of input and output channels.
Another thing to consider: due to numerous requests so far I'm also planning to change Voxengo plug-in naming scheme. I still plan to leave 'brand prefix', but would like to reduce it to 'Vox'. But most importantly, the name of the plug-in will be also minimized (I will try to keep it under 8 characters). For example, 'VoxPSpace.dll' instead of 'VoxengoPristineSpace.dll'. In case of 8 channels config it may look like 'VoxPSpace_8.dll'. If somebody against this naming scheme, please let me know.
-
- KVRian
- 1394 posts since 28 Mar, 2002 from Austria
I like the way it is at the moment.
Naming scheme to "Vox" is a good idea, but I disagree with the short version of the plugin. It's easier for the eyes to see the full name of the plugin. We are not on DOS/Windows3.11 anymore to have a problem with longer names.
I also vote for "VintageModulator" instead of "Vmod".
Maybe several dll-Files fixes some problems, but our plugin lists will get longer and longer. If you can fix this in another way, I will appreciate it.
Maybe there's a way to save the current used channels with the project/presets (Cubase different than Wavelab4), I don't know.
Naming scheme to "Vox" is a good idea, but I disagree with the short version of the plugin. It's easier for the eyes to see the full name of the plugin. We are not on DOS/Windows3.11 anymore to have a problem with longer names.
I also vote for "VintageModulator" instead of "Vmod".
Maybe several dll-Files fixes some problems, but our plugin lists will get longer and longer. If you can fix this in another way, I will appreciate it.
Maybe there's a way to save the current used channels with the project/presets (Cubase different than Wavelab4), I don't know.
-
- KVRer
- 21 posts since 21 Aug, 2004 from London, England
I would definitely say "YES" in large, capital letters to a different input/output count for a reverb plugin.
And let me explain why:
I do a lot of surround, and this invariably involves having to deal with both mono and stereo tracks that need to go into a surround reverb.
Having 2 in and 5 out here is a definite advantage.
As is 1 in and 5 out.
Also 5 in and 5 out -
it is my preference that a setting such as this should be user configurable. That way, if I have say a stereo drum track that I wish to apply a surround reverb to, not to put the actual drums into the surrounds, but just the reverb part for example, then stereo in and 5 channels out would be not only desirable but absolutely vital to me.
Using a surround panner often does not give the required flexibility, especially in the case of a tool such as PristineSpace, which is a convolution device that can have many impulses loaded.
Different I/O settings will also be a boon on other plugs too.
Finally - I don't much like the changing the DLL idea - I like it just fine the way it is.
And installing an updated version will then give 2 instances of the plugin too.
Housekeeping will be a mess.
And let me explain why:
I do a lot of surround, and this invariably involves having to deal with both mono and stereo tracks that need to go into a surround reverb.
Having 2 in and 5 out here is a definite advantage.
As is 1 in and 5 out.
Also 5 in and 5 out -
it is my preference that a setting such as this should be user configurable. That way, if I have say a stereo drum track that I wish to apply a surround reverb to, not to put the actual drums into the surrounds, but just the reverb part for example, then stereo in and 5 channels out would be not only desirable but absolutely vital to me.
Using a surround panner often does not give the required flexibility, especially in the case of a tool such as PristineSpace, which is a convolution device that can have many impulses loaded.
Different I/O settings will also be a boon on other plugs too.
Finally - I don't much like the changing the DLL idea - I like it just fine the way it is.
And installing an updated version will then give 2 instances of the plugin too.
Housekeeping will be a mess.
www.opusproductions.com
Multichannel Audio Specialists
Multichannel Audio Specialists
-
- KVRAF
- 4265 posts since 21 Oct, 2001 from my bolthole in the south pacific
Shorter names would be better in (for eg) Logic PC where plugin names are truncated to fit small boxes in the mixer. Same with Mackie/Logic Control.
Eg
Eg
- KVRAF
- Topic Starter
- 4030 posts since 7 Sep, 2002
Hmm.. Results are not as inspiring as I wished them to be.
First of all, latest Steinberg hosts do allow me to incorporate switchable IO support even without user interaction necessary, but older Steinberg and non-Steinberg VST hosts have troubles with this. I.e. according to the latest VST v2.3 (and the comments from the Steinberg developer) I may send the information to the host about the maximum number of IO channels plug-in supports, and then use any configurations within these bounds just by checking channel availability. But if I simply supply 8 for input and output, older hosts may refuse to work with such plug-in.
So this suggests me to create at least two versions of the same plug-in (i.e. older 2in 2out and dynamic up-to-8 channels). But this is not far from having several DLLs, and simply allowing/disallowing them during initial installation.
Neil, can you just use 8in/8out config all the time with Pristine Space? I think if you use the latest Nuendo and Cubase SX that should be compatible with all sound configurations - Pristine Space takes the connected IO channels into consideration.
Full-scale plug-in names do work good in most hosts, but in some cases they look totally unacceptable. For example, in Analogflux Suite I had to shorten file names. BTW, 'VoxengoVintageModulator' name could definitely cause problems to some users.
First of all, latest Steinberg hosts do allow me to incorporate switchable IO support even without user interaction necessary, but older Steinberg and non-Steinberg VST hosts have troubles with this. I.e. according to the latest VST v2.3 (and the comments from the Steinberg developer) I may send the information to the host about the maximum number of IO channels plug-in supports, and then use any configurations within these bounds just by checking channel availability. But if I simply supply 8 for input and output, older hosts may refuse to work with such plug-in.
So this suggests me to create at least two versions of the same plug-in (i.e. older 2in 2out and dynamic up-to-8 channels). But this is not far from having several DLLs, and simply allowing/disallowing them during initial installation.
Neil, can you just use 8in/8out config all the time with Pristine Space? I think if you use the latest Nuendo and Cubase SX that should be compatible with all sound configurations - Pristine Space takes the connected IO channels into consideration.
Full-scale plug-in names do work good in most hosts, but in some cases they look totally unacceptable. For example, in Analogflux Suite I had to shorten file names. BTW, 'VoxengoVintageModulator' name could definitely cause problems to some users.
-
- KVRer
- 21 posts since 21 Aug, 2004 from London, England
I should be able to.Aleksey Vaneev wrote:Hmm.. Results are not as inspiring as I wished them to be.
Neil, can you just use 8in/8out config all the time with Pristine Space? I think if you use the latest Nuendo and Cubase SX that should be compatible with all sound configurations - Pristine Space takes the connected IO channels into consideration.
One way to find out - but will having 8 in 8 out permanently configured not hit the CPU too hard?
The version I'm running now does the job - it's set to 2 in, 6 out.
Can be changed dynamically.
I'm always up for trying though.
www.opusproductions.com
Multichannel Audio Specialists
Multichannel Audio Specialists
- KVRAF
- Topic Starter
- 4030 posts since 7 Sep, 2002
Neil, having 8in/8out always should not usually consume more CPU power as not all channels maybe available and those won't be processed. So that should be safe.
I have probably found some solution for this multi-IO thing, but that should be approved by somebody at Steinberg (I've posted a question on a dev.mailing list - we'll see).
Question about plug-in names still persists. Maybe I'll just leave everything as is and watch out names like VoxengoAnalogfluxImpulse in the future - i.e. keep a limit of 20 chars.
I have probably found some solution for this multi-IO thing, but that should be approved by somebody at Steinberg (I've posted a question on a dev.mailing list - we'll see).
Question about plug-in names still persists. Maybe I'll just leave everything as is and watch out names like VoxengoAnalogfluxImpulse in the future - i.e. keep a limit of 20 chars.
-
- KVRer
- 1 posts since 2 Mar, 2005 from Piteå, Sweden
I've been playing around with Pristine Space for a while now and also for surround use as there are limited number or choises for that application. I set Pristine Space to 6in/6out and use surround panner in Nuendo send to send to C only and this way it works ok as 1in/6out with a 5ch surround impulse file. One sugestion would be a mixer in the plugin - exaple: in Pristine Space add an input that is MIX (mix of all inputs) and this way that signal could be used for the convolution input and the surround panner send can be set anywhere. Correct me If I missunderstod something but you would need 10 slots to do this right? Use input 1/2 and output 1/2/3/4/5/6 and two 5ch impulse files for a true stereo input / 5ch (no LFE) surround output. Right now you have to use two plugin instances right? This way you need two sends panned the same way.
/anders hannus
/anders hannus
-
- KVRAF
- 4265 posts since 21 Oct, 2001 from my bolthole in the south pacific
This usually does not work in my experience. VST hosts often don't seem to get the plugin name from the dll name - they must read a header inside the file. It is often difficult to keep a new beta version and an older version installed simultaneously.flex42 wrote:I think the names are fine. If anyone has problems with them he could always rename the dll...
- KVRist
- 95 posts since 17 Mar, 2003 from France
I have renamed quite a number of VSTi & FX dll's for better organisation, and I have found only very few plugins to cause problem with this. I use Cubase SX 2.2.039 and occasionally Tracktion as my hosts, also SAVIHost & VSTHost for standalone operation of plugs.egbert wrote:This usually does not work in my experience. VST hosts often don't seem to get the plugin name from the dll name - they must read a header inside the file. It is often difficult to keep a new beta version and an older version installed simultaneously.flex42 wrote:I think the names are fine. If anyone has problems with them he could always rename the dll...
As for having multiple I/O versions of the same plug, mhh, dunno. Pristine Space is just fine for me as it is now.
Regards
Raphael
-
- KVRAF
- 2135 posts since 12 Jul, 2004 from Brave New World
I need a few more inputs on my NanoVerb.

"Duct tape is like the force. It has a light side, a dark side, and it holds the universe together...." -Carl Zwanzig
- KVRAF
- Topic Starter
- 4030 posts since 7 Sep, 2002
-
- KVRAF
- 4265 posts since 21 Oct, 2001 from my bolthole in the south pacific
When you look at the name your host assigns to the plugin you have renamed it is always the original name.funkster1 wrote:I have renamed quite a number of VSTi & FX dll's for better organisation, and I have found only very few plugins to cause problem with this.
-
- KVRAF
- 8705 posts since 24 May, 2002 from Tutukaka, New Zealand
In/out variations on reverb are probably only a consideration to anyone using surround...and there's probably not that many here that do. I can use surround in my host, but never touch it.
And in terms of simple stereo work, there's almost no benefit from using front/rear outs etc. I have an older h/w reverb unit that has 4in/4out capability. I can use it as 2 discrete stereo in/out processors, or 4 mono in/out processors, or a single 2 in/4out processor (or other variations). And while it is nice to have the facility, I found myself never once actually using the 4out option, even for the huge reverb algorithms that used both processors inside it. Without using a surround speaker setup, it's difficult to get the image of the front/rear to be noticeable in a full mix.
So, the option is nice, but I don't do surround stuff for DVD, so I'd never actually practically use anything other than stereo in/out - probably the majority work that way still.
Sidechaining - that's another matter entirely, but not much use in reverb.
And in terms of simple stereo work, there's almost no benefit from using front/rear outs etc. I have an older h/w reverb unit that has 4in/4out capability. I can use it as 2 discrete stereo in/out processors, or 4 mono in/out processors, or a single 2 in/4out processor (or other variations). And while it is nice to have the facility, I found myself never once actually using the 4out option, even for the huge reverb algorithms that used both processors inside it. Without using a surround speaker setup, it's difficult to get the image of the front/rear to be noticeable in a full mix.
So, the option is nice, but I don't do surround stuff for DVD, so I'd never actually practically use anything other than stereo in/out - probably the majority work that way still.
Sidechaining - that's another matter entirely, but not much use in reverb.
