VST3 MIDI Output bug (REAPER-specific) [addressed in v7pre]

[sockmonkey72]

Hi, I just stumbled across some weird VST3 behavior, which I believe is REAPER-specific. Here's the setup:

* VST3 MIDI plugin (can process incoming MIDI messages, build in iPlug2)
* MIDI Output set to the default (replaces MIDI bus)
* track with a single Bank Select/Program Change message (so 3 msgs: CC32, CC0, PC)

When I send the messages to the plugin, and the plugin does not output anything in response, the Bank Select/PC messages are not passed through. Everything is filtered out.

When I send the messages to the plugin, and the plugin outputs anything (any MIDI message), REAPER merges the incoming Bank Select/PC messages with the plugin output.

If the plugin passes the Bank Select messages through (or modifies them), this behavior results in doubled output of the CC messages (which _can_ be handled by a VST3 plugin), plus the merged output of the PC message (which cannot be handled).

Also, a Bank Select/PC group is supposed to be sent in a specific order: "The transmitter must transmit the MSB and LSB as a pair, and the Program Change must be sent immediately after the Bank Select pair. If their [sic] is any delay between these messages and they are passed through a merging device (which may insert another message) the message may be interpreted incorrectly." (MIDI 1.0 spec, page 13), and this behavior creates an ordering problem:


(the top 3 messages are merged with the VST3 output by REAPER, the bottom 2 messages are being processed by the plugin)

Depending on the receiver, this might break the message, which is why I bring this up.

If the plugin attempts to filter the Bank Select messages, thinking that REAPER is going to send them anyway, there's no output (REAPER doesn't send them, in fact).

Ideal behavior would be to, when sending Bank Select/PC messages) look at the plugin output, and if the input and the output match (MSB/LSB are sent), don't add the CC messages (to avoid doubled output) and place the PC at the end, where it's supposed to go. You're clearly looking at the plugin output to determine whether to send or not, so this should be possible, right?

If the plugin ignores the input (no output), and the merging described above is in place, the existing behavior of not sending the Bank Select/PC messages seems appropriate.

Anyway, this behavior completely confused me for the last 12 hours in a debugger. Thanks for considering a cleanup.

[mschnell]

I did not use iPlug2, so I only can comment from my experience with JSFX and JUCE (VST2 and VST3):
I suppose that when a Midi Event is not actively digested by the plugin, it is forwarded to downstream.
Then the plugin creates a Midi event, it needs to specify a an "offset" (riming in samples after the start of the current sample block.
Then the same offset is specified for multiple events, the sequence of those events (to be executed downstream) is random, and not guaranteed to follow the sequence of creation.

[sockmonkey72]

mschnell, would you please stop posting on bug reports threads about which you have no concrete information? Your vague musings, hunches, Bauchgefühl, whatever, are not useful here, and simply distract from the report, which is a specific report of a specific behavior.

This seems to be your thing, though, so I'd appreciate it if you would please just steer clear of my reports, which I go to the trouble to file because I'd love to see them addressed, not because I'm looking for unfounded speculation.

[schwa]

Do you have, or can you point us to, a sample plugin that shows this behavior?

[sockmonkey72]

Originally Posted by schwa

Do you have, or can you point us to, a sample plugin that shows this behavior?

Thanks schwa,

Here's a freshly built IPlugInstrument from the tip of iPlug2's Github. It will cause the behavior I'm describing if you stick in on a track with a Bank Select/Program Change event (because it passes CCs through).

Let me know if you need more to work with, and thanks again for taking a look.

[schwa]

It's unusual for a plugin to output MIDI CC, which is why this hasn't come up before afaik.

If the plugin's MIDI output is not the same as the MIDI input, which is the case here since the plugin is not passing through the PC message, then the plugin MIDI output is merged with the non-note MIDI input. The easiest way to handle this would probably be to keep everything as-is, but make sure the PC message is sent after the (doubled) CC bank select messages. Would that work for your situation? It would be a big pain to add support for merging or replacing MIDI CC...

[nofish]

Originally Posted by schwa

It's unusual for a plugin to output MIDI CC, which is why this hasn't come up before afaik.

FWIW e.g. another one:
https://xferrecords.com/products/lfo-tool

[sockmonkey72]

Originally Posted by schwa

It's unusual for a plugin to output MIDI CC, which is why this hasn't come up before afaik.

If the plugin's MIDI output is not the same as the MIDI input, which is the case here since the plugin is not passing through the PC message, then the plugin MIDI output is merged with the non-note MIDI input. The easiest way to handle this would probably be to keep everything as-is, but make sure the PC message is sent after the (doubled) CC bank select messages. Would that work for your situation? It would be a big pain to add support for merging or replacing MIDI CC...

And here's the rub: VST3 doesn't support incoming Program Change messages - they are filtered out of the incoming data stream. So I never see that message.

I might be able to hack the Iplug2 source code to spoof some hidden parameter and transport the PC behind the scenes, but this may come up with other plugins, as well.

EDIT: on second thought, I don't think that hackery will work, but I'll think about it some more tomorrow.

[schwa]

I meant we could change it on the REAPER side so that the re-merged PC message is added after the doubled CC bank/select messages.

[EvilDragon]

Originally Posted by sockmonkey72

And here's the rub: VST3 doesn't support incoming Program Change messages - they are filtered out of the incoming data stream. So I never see that message.

I might be able to hack the Iplug2 source code to spoof some hidden parameter and transport the PC behind the scenes, but this may come up with other plugins, as well.

EDIT: on second thought, I don't think that hackery will work, but I'll think about it some more tomorrow.

The way to go about this is to create a fake program list with 16x128 programs so that you can at least do something on incoming PC messages. This is what Kontakt 7 implemented in order to support receiving PC messages with VST3.

[sockmonkey72]

Originally Posted by schwa

I meant we could change it on the REAPER side so that the re-merged PC message is added after the doubled CC bank/select messages.

I see, yes, that would be fine, as long as it's guaranteed that any CCs sent by the plugin come after the merged REAPER CC output. Thank you!

[mschnell]

Originally Posted by sockmonkey72

please just steer clear of my reports,.

Its a pity, if you are not interested in technical background that might help to pinpoint a problem and to try to find a solution, but only in complaining about a dedicated problem that might or might not be solvable by modification to the DAW in question.

(I don't see why you think my contribution could hamper the proceeding.)

[sockmonkey72]

Originally Posted by mschnell

Its a pity, if you are not interested in technical background that might help to pinpoint a problem and to try to find a solution, but only in complaining about a dedicated problem that might or might not be solvable by modification to the DAW in question.

(I don't see why you think my contribution could hamper the proceeding.)

This is what my 8-year old daughter does when she wants to get a rise out of me. I asked nicely.

I don't want to get into a technical background/experience pissing contest with you. Based on your "contributions" to date, I think I'm good, thanks.

You'll note that I generally reserve my bug reports for DAW behaviors which are unavoidable or cannot be easily dealt with (or for which the workarounds are complex and/or undiscoverable to intermediate users and/or seem to say 'no' to the user). I don't get involved, for the most part, with problems which represent disagreements about proper usage.

You'll note that this report, in fact, referred to actual REAPER-specific VST3 output behavior which causes specification-related problems, and which is unfixable without assistance from the devs. Your post made it apparent that you neither really read the report, nor did you understand what was happening, nor why any VST3 developer might consider it important. Hint: I wasn't asking for help writing plugins.

So from my perspective, your post wasn't helpful and merely serves to muddy the waters. Luckily, schwa (one of the two people for which this post was written) did read it and understood it, and it sounds like he has an idea for how it could be fixed.

Please don't use my posts to tout your credentials (JSFX/JUCE use != useful information), post irrelevant factoids (MIDI event timestamping is not a revelation), nor to fill the forum with more vague suppositions about how real software works, maybe, possibly, with some hand-waving. Thank you.

[sockmonkey72]

Originally Posted by EvilDragon

The way to go about this is to create a fake program list with 16x128 programs so that you can at least do something on incoming PC messages. This is what Kontakt 7 implemented in order to support receiving PC messages with VST3.

Now this is useful information, thanks ED. I'll definitely try this out when I have a sec.

[mschnell]

Originally Posted by sockmonkey72

(MIDI event timestamping is not a revelation)

???

Originally Posted by sockmonkey72

Also, a Bank Select/PC group is supposed to be sent in a specific order...

This is why I tried to help by reporting the experience that the order of Midi events received by a plugin's user software is only depending on the time stamps and not on the order of them being sent by another plugin if they feature the same time stamp. Which in this case might be the cause of a problem. (I don't know if random reordering might have been due to the DAW, due to the sending plugin's Midi library, or due to the receiving plugin's Midi library.)

[EvilDragon]

Originally Posted by mschnell

(I don't know if random reordering might have been due to the DAW, due to the sending plugin's Midi library, or due to the receiving plugin's Midi library.)

The random ordering is due to VST3 being shit and separating different MIDI message types into separate streams that know nothing about each other, breaking the serial nature of MIDI.

[sockmonkey72]

Originally Posted by EvilDragon

The random ordering is due to VST3 being shit and separating different MIDI message types into separate streams that know nothing about each other, breaking the serial nature of MIDI.

You kind of have to admire the stubbornness of the VST3 design team, who haven't budged after 10 years of seething criticism. I guess that the legacy MIDI output API is decent.

ED, I tried your preset trick and it works. Thanks again. If I use that technique and generate a PC in response, I get _all_ of the input doubled at output, not just the Bank Select CCs. That's with the improvement in 7pre14.

I'm not going to push my luck with schwa, though. 🤣

[EvilDragon]

Yeah it's amazing how stupid it is. "VST3 is an audio processing API, it shouldn't know about MIDI" and "MIDI should be abstracted, will be easier to move to MIDI 2.0 when we have to". Sure, but why is it so problematic to just add another event stream that would listen to and produce raw MIDI?

You know... like CLAP does?

[Tale]

Originally Posted by EvilDragon

The random ordering is due to VST3 being shit and separating different MIDI message types into separate streams that know nothing about each other, breaking the serial nature of MIDI.

Right! Do note that this shouldn't happen for Program Change and Bank Select/CC though, because both these MIDI message types are added to the same stream.

BTW, "random" reordering of events which happen at exactly the same offset could also happen if the underlying queue implementation doesn't explicitly preserve the order (e.g. for efficiency reasons). But then you should probably just use another queue implementation...

[mschnell]

Originally Posted by EvilDragon

The random ordering is due to VST3 being shit and separating different MIDI message types into separate streams that know nothing about each other, breaking the serial nature of MIDI.

JUCE hides that complexity and just provides a Midi stream (partly randomly ordered).
Looking forward to see what I get with the RustAudio crate .

[EvilDragon]

JUCE hides the complexity but doesn't fix the problem, yeah.