Oh i'm all for this! But I would have thought that would have been well under way if it was easy to implement...

The main reason I use Chainer is for side-chaining, esp. compression. So if somehow we can get this down without Chainer, AND if the interface were simple enough, I would jump right into it.

One of the other things I like with Chainer is that I can access all the presets from that window, but with MPT's plugin window not all the presets are evident. Usually this applies to VSTi's that have an internal list of presets or different banks. (I can check to see which ones I had problems with...)

One of the other things I like with Chainer is that I can access all the presets from that window, but with MPT's plugin window not all the presets are evident. Usually this applies to VSTi's that have an internal list of presets or different banks. (I can check to see which ones I had problems with...)

A plugin either exposes its presets to the host or it doesn't. There's no way Chainer can show the presets but OpenMPT can't.

Oh i'm all for this! But I would have thought that would have been well under way if it was easy to implement...

Or someone would have had to think about it before. I asked LPChip to submit his reasons for clinging to Chainer because people seem to use this crash-prone and old plugin but never tell us WHY.

Just adding my own experience to this pool here. I use chainer plugins specifically because of these
1 - it cannot be overstated how helpful a visual way to chain the plugins you use can be
2 - getting any effect to run parallel on an effect chain seems to be natively impossible in ompt, maybe because there is no visual way to dissect our chains I am completely wrong here, but frankly every chain I make seems very much in series, even plugins set to master very much have a linear system and take what is output from the previous master and add the effects to that.

I really think a dedicated vst tab that contains chains which can hopefully be randomly dragged and linked in as many ways as possible will solve the second issue because that is the major failing of ompt vst implementation in my personal opinion.

for example, right now, I have just finished downloading Xlutop chainer again and I am presently browsing my search results in my basic search engine for hopefully new chainers.

If a whole new tab for chaining vsts is not an option, then how about a vst like tool that would be in every ompt download that grabs all the vsts from ompt and gives you an interface something like vst-forx which is another one I have used for years

If a whole new tab for chaining vsts is not an option, then how about a vst like tool that would be in every ompt download that grabs all the vsts from ompt and gives you an interface something like vst-forx which is another one I have used for years

Believe me, adding the tab isn't the complicated part. And turning the functionality itself into a plugin isn't making it any easier, either. If there were easy shortcuts, they would have already been taken.

I'm a BitWig user now although there are still moments where I come back to good old OpenMPT. Because most of my projects are now with BitWig now, I don't really use chainer myself anymore except for opening old projects that used it.

But back on topic. You'll understand the above footnote? headernote? prenote? note? yeah note. You'll understand the above note in a second.

OpenMPT does not do parallel processing. There is the wet/dry slider which allows you to apply only a bit of an effect to the sound, but the next plugin in the chain still uses that output, never the source.
With parallel processing you would copy the main signal multiple times, apply wet/dry to it and mix the result to the output.

Now, one could say, oh, but just supply another parameter in the plugin page that specifies what you want to use for input, so you copy that signal instead of whatever is currently outputting to it, but that could lead to a feedback loop.

It could be possible to specify more than just one outputs on the plugin page, and that probably would allow you to do parallel processing in OpenMPT, upto a degree.

But maybe its a good idea to use the good old: get inspiration from other developers. Let me tell you how Bitwig solved this problem. Natively Bitwig does not do parallel processing either. In its core, its very much similar to how OpenMPT works, except there are no limits.

You have a track. You assign a VSTi to it, and it has an output. You can assign a VST to it, and again it has an output, and you build your chain there.

There is also the ability to send to an FX channel, similarly how you can send multiple instances of different instruments to the same plugin slot later in the list.

So, what did BitWig do to add support for Parallel processing? They essentially added a chainer effect you can add. They call this effect: FX Layer. You insert an FX Layer and you get an empty stack. When you add a VST to the stack, the input of the FX Layer is copied to that VST, the gain parameter is used to control its volume and the VST itself changes the sound. If you have just one VST in the FX Layer, the sound is as if the FX layer wasn't there. If you add a new layer to the FX Layer, but leave it empty, you copy the dry sound and now you can use the volume on either instances to mix the effect or the dry signal in as much as you want. Every FX Layer can have multiple outputs in sequence.

So what OpenMPT could do, is create a special FX Layer effect that you can add which has a settings page of some sort where you get an empty list with a button to add new entries. Adding an entry creates a dropdown list, listing all the available pluginslots that are in the song, starting from the number the plugin itself is in, +1. This prevents a feedback loop. In addition, the fx layer also has an output like every plugin. Either for now, we fix that to always be master, or we build in a mechanism that it can only be the highest output number used in the fx layer +1. When inserting the FX Layer, a new output buss is added: FXLayer# out, which replaces the Master out. This is automatically applied for all effects between the slot in FXLayer and whatever it outputs to. In addition, only outputs between these numbers are available, not higher numbers. So if FXLayer occupies slot 31 and outputs to 33, you can only add an entry for 32, and its output can only be fx layer out.

Actually it may be easier if it doesn't output to existing plugin slots, but create a new list only available for the fxlayer itself. That would solve a lot of things.

Anyway... So lets say,

FX01: Synth1, output to FX02
FX02: FX Layer, output to FX08 -> outputs, 3@50%, 5@20%
FX03: EQ with hipass filter so there is only bass, outputs to FX04
FX04: Stereo to mono effect, outputs to FXLayer out
FX05: EQ with lopass filter, so there is only high frequencies, outputs to FX06
FX06: stereo widening effect, outputs to FX07
FX07: Compressor, outputs to FXLayer out (only option)
FX08: some plugin that we want on everything. Otherwise FX02 would output to master.

Also, I never used Xlutop Chainer much for its parallel processing options, for me it was the ability to have all the mixer sliders in one screen so mixing was much quicker than how you do it in OpenMPT.