Dry/Wet on instrument plugins; faulty I/O Type detection

[huvudläs]

What determines if a plugin (VST) is an effect or an instrument (generator)? Is there a way to trick OpenMPT into internally treating one as another?

The problem: I want to use Redux for effect routing (not to generate tones) but OpenMPT treats it differently from an ordinary effect plugin by greying out some of the options in the plugin Mix Settings and changes behavior in some other ways, namely crippling the dry/wet functionality for the plugin.

It of course makes sense that for instruments that only generate tones, letting the user adjust dry/wet doesn't make sense because the input is just MIDI. (This is just my assumption as to why it works like this, would be nice to get a confirmation though.)

The thing is, OpenMPT does let me feed audio to Redux - despite its I/O Type being detected as "No input, Stereo-Out" - like any typical effect plugin, and it goes through just fine, I just cannot adjust the dry signal from OpenMPT's interface (preferably muting it altogether so I could handle d/w inside Redux). So, because the functionality for feeding audio to any type of VST exists, it seems odd that dry is forced at 100% when it's an instrument plugin no matter what the Dry Mix slider is actually set to.

Simply allowing the default mix behavior for any plugin would satisfy my needs. Maybe via an option to manually set the I/O Type in case of misdetections like in Redux's case. Thanks.

[herodotas]

If you talk about Renoise Redux plugin, it is instrument not FX. To use it as FX you need modular plugin like MUX (I test with) or Bidule or any other. But use Redux in OpenMPT is a little bit perversion IMO 

[Saga Musix]

What determines if a plugin (VST) is an effect or an instrument (generator)? Is there a way to trick OpenMPT into internally treating one as another?

OpenMPT considers a plugin to be an instrument if either the "effFlagsIsSynth" flag is set or if the plugin doesn't have any inputs.
There is no direct way to change this, except for using wrappers like herodotas described.

The thing is, OpenMPT does let me feed audio to Redux - despite its I/O Type being detected as "No input, Stereo-Out" - like any typical effect plugin, and it goes through just fine

That sounds like things are working for you just out of sheer luck - OpenMPT always provides two inputs to any plugin, no matter what - but if the plugin declares that it has no inputs, it shouldn't have any business in accessing them (or it would crash with any host that doesn't provide the extra inputs).
I have a slightly outdated version of Redux installed here, though, and it declares to have stereo inputs, unlike your version. If you are also on an older version, I would suggest that you update it, to be on the safe side. If you are on the newest version already, I guess it might be regression.

Anyway, to address the actual elephant in the room: To be honest I also have no idea why the Dry/Wet handling is different for instrument plugins, it has been bugging me for a while already and I have considered to change it. It makes sense when the plugin has no inputs, but OpenMPT also handles the dry/wet ratio differently if there are inputs and it's just the effFlagsIsSynth flag being set. Maybe now would be a good time to think about changing this behaviour.

But use Redux in OpenMPT is a little bit perversion IMO 

This sort of comment really isn't necessary. Let people use what works best for them. And if that's a tracker within a tracker, even if it's just for FX processing, that's fine!

[herodotas]

This sort of comment really isn't necessary

Sorry, I'm from East Europe, my politcorrection level is low.

[huvudläs]

If you talk about Renoise Redux plugin, it is instrument not FX.

I know how "Redux as FX" sounds but it's what I had lying around and I've got it working. That is, OpenMPT sends a signal -> Redux gets #Line-In -> (FX chains) -> Output back to OpenMPT. I personally love Renoise's native effect package + routing system, and since Redux implements those it's handy for use in other DAWs. But I believe the actual problem is more general than that: there ought to be other plugins that too receive both audio signal and note input. Vocoders, maybe?

What determines if a plugin (VST) is an effect or an instrument (generator)? Is there a way to trick OpenMPT into internally treating one as another?

OpenMPT considers a plugin to be an instrument if either the "effFlagsIsSynth" flag is set...

I was thinking of editing the binary for a workaround. Is there a standardized location for the flag? Redux doesn't seem to mind me flipping random bits in the dll.

And yeah, Redux says I'm running the latest version. I might've actually confused Redux for some other instrument plugin that did indeed have no inputs and made a load of assumptions off that. It now correctly reads "I/O Type: Stereo-In, Stereo-Out". Sorry for the hassle.

As for another workaround I found, having one isolated FX chain within Redux to just invert the input and putting the real effect stuff on another chain with its own #Line-In can be used to cancel out dry signal and seems to work for all effects and combinations thereof. Interestingly, the chains must to be isolated from each other, as if they both branch out from a single #Line-In then certain effects (compression, stuff that mentions oversampling...) oddly bleed upstream in the send routing and ruin the inversion-cancellation, even when bypassed.

[Saga Musix]

No binary editing necessary (and potentially not even possible); I have something for you to try.

As of r20712 (v1.32.00.11), OpenMPT will treat instrument and FX plugins exactly the same when it comes to mix modes. For existing files made with older OpenMPT versions, the previous behaviour is emulated by a newly-added mix mode called "Instrument". You can change this to "Default" and make use of the new behaviour immediately. Newly added instruments will always use the "Default" mix mode. Consider the "Instrument" mix mode to be a legacy feature to support correct playback of older modules.

Note that this is still experimental as it hasn't been tested much; so be behaviour may change before the official release of OpenMPT 1.32 if a bug is found. But I doubt that will happen (apart from maybe hiding the "Instrument" mix mode for files that don't need/use it).

You can download an automated thest build of this new version soon (should be ready in a few hours); either by setting the update channel to "Development" in OpenMPT or by downloading a test build from https://builds.openmpt.org/builds/ as soon as it's there.

Let me know how this works for you.

[huvudläs]

Thanks, it works! I was on edge earlier about asking you to include this in the next nightly build, preferably with some hurry (happens to be a compo underway) . Glad to know you were also aware of the issue and on the ready to push a fix, if only after a nudge.

Aaaaand... resolved! Thanks a lot for the quick support, again.