View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000900||OpenMPT||Feature Request||public||2016-12-11 16:38||2022-10-14 11:32|
|Product Version||OpenMPT 1.?? (long term goals)|
|Target Version||OpenMPT 1.?? (long term goals)|
|Summary||0000900: Plugin chains with mixer support|
As per my chat with Saga_Musix:
I'm using Xlutop Chainer because I miss certain functionality inside OpenMPT. There are a few reasons I haven't said goodbye to Chainer. It'd be awesome if these can be implemented in OpenMPT at some point.
What I'd love to see (its slightly different than how chainer does it by default, but I make changes to follow this workflow) is the following:
Have 16 channels, each listening to a different midi channel. (actually this is not even necessary if I can somehow send any instrument's midi data directly to such channel.)
Have an overview of what comes out at the very bottom of the channel to a volume switch with VU meter.
Have the ability to save the entire channel with plugins and their settings into a file, so I can reopen that channel in its entirely and it works out of the box. (I dedicate a channel for an instrument with its settings and EQ and so forth, so when I reuse an instrument, I only need little tweaking to make it work in my current song.
The ability to insert an output somewhere during the chain to redirect the sound to a different chain with a dry/wet slider allowing the sound to also continue in the same channel.
The ability to control the chain itself using midi macros, such as volume and dry/wet ratios of a redirect to channel block.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
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...)
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.
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
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
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.
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
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.
|2016-12-11 16:38||LPChip||New Issue|
|2016-12-11 16:52||Saga Musix||Relationship added||child of 0000701|
|2016-12-12 08:58||harbinger||Note Added: 0002814|
|2016-12-12 14:54||Saga Musix||Note Added: 0002815|
|2022-10-13 21:13||Exhale||Note Added: 0005325|
|2022-10-13 21:16||Saga Musix||Note Added: 0005326|
|2022-10-14 11:31||LPChip||Note Added: 0005327|
|2022-10-14 11:32||LPChip||Note Added: 0005328|