SOLVED Clips not recording or passing MIDI data to plugins (not a Waveform issue)

[Watchful]

This is a relatively recent problem that seems to have hit since the last official Waveform 11 update. I'm on Windows 10, by the way.

There are two issues, both related to hardware:

1. On a hardware keyboard, Waveform is no longer recording pitch bends or mod wheels. It's just not there anymore.

2. On a hardware controller, Waveform *is* recording MIDI controller instructions but not passing them through to the plug in. Here's the test we ran:

- Assigned controllers 96 to ProgChUp and 97 to ProgChDn.
- Recording a MIDI clip shows these button pushed are recorded.
- Playback does NOT pass these commands through to the plug in. The program does not change.
- The plugin (Arturia Pigments) has a standalone version. Running this outside of Waveform works perfectly: the programs change up or down with each button push as expected.
- Our conclusion is that Waveform records the button pushes, assigns them as 96 and 97 correctly, but is not sending this to the plugin.

In a brief chat with Peter Widdecomb (who's awesome, by the way), he suggested checking MPE status. I've experienced weirdness like this when MPE is on for non-MPE hardware back under T7.

Indeed, I thought of that during our tests, and noticed the following:

- Both problems occur whether MPE is on or off.
- If I turn off MPE and re-record the clip, Waveform turns MPE back on for that clip. It seems like I can no longer turn off MPE and have it stay off.

Again, this started earlier this year with the latest official release of Waveform. Any thoughts?

[Peter Widdicombe]

Put MIDI Monitor on the output section, just before the VST. Is data making it "past the track data" as expected? Any possibility Pigments expects control to be on another MIDI channel ?

Does it work normally for Note on/off events, and only skips controller changes ?

[Watchful]

Thanks, Peter. First issue is solved.

I clicked on the hardware input, and "Record MPE to Note Expression" has rechecked itself since the last update. Note sure why that would default, but it did. Unchecking it has helped.

Great suggestion on the MIDI monitor; will try this and report back.

Again, thanks for your help. You're an asset to KVR.

[Watchful]

Second issue does not seem to be a Waveform problem. Peter's recommendation to put the MIDI Monitor before Pigments shows the data is being passed to the plugin.

4OSC did not lend itself well to this test, alas, so we tried a different approach: we went through a lengthy list of controller knobs, dials, sliders, and buttons and discovered...

...the standalone version of Pigments responds to pretty much everything you throw at it. But the plug in version has a few gaps, and doesn't seem to understand what the standalone version does. In other words, if we mapped a knob in the standalone version to change the cutoff, it works in the plug in version fine. If we mapped the DataIncrement button in the standalone version, it does NOT work in the plug in version. There were a small number of controls that get ignored.

Just to make sure this wasn't a Waveform issue, we tried the Korg Triton plug in, and it worked fine (both standalone and plugin). So it just seems to be a Pigments misalignment.

Thanks to Peter for his guidance--he saved us a ton of time.

[Peter Widdicombe]

Midimonitor is a really useful tool to have "when you're pulling your hair out" and nothing makes sense.

I used to rely on "MidiOX" externally for this functionality; but as you've seen what the CONTROLLER does and what the VST will do may both need a monitoring method.