MIDI Out module not working in Live 12

[xones2358]

Hello fellow people.

Not sure what is the problem, but I can't seem to get any Midi Signal arriving in Ableton Live 12.

Stream of cables indicates signals being sent but on the other end of Ableton nothing arrives.

I can swear it has been different in the past (differnt Live version or VM version...)

anybod who use the two together care to check if it works for them?

much thanks

[ColinP]

I don't have any specific experience with Ableton Live 12 but I just happened to be looking at MIDI transport control today and came across a problem. It's not related to the MIDI Out module but seems to indicate there's something not quite right with MIDI I/O. TBH I've had similar mysterious problems with MIDI in VM before. It works absolutely fine about 99% of the time but sometimes for no particular reason it seems to fall over, then just as mysteriously recovers after a reboot.

The following simple patch should start the Song Control sequencer when the top-left button is pressed, but it didn't work. I double-checked and used my in-house MIDI Watcher module and CA's Sync to MIDI Clock module was indeed outputting a MIDI start but my Song Control module wasn't receiving it.

I scratched my head, rebooted VM and rebuilt the patch exactly the same and then it's worked fine since.

MIDITest.png (212.56 KiB) Viewed 819 times

[xones2358]

Hey Colin!
Thanks for your reply. You may remember me as a friendly beta tester who retired

I contacted the support and they suggested me to try out if I could send MIDI from the FX version of the VM plugin and much to my surprise this worked.

100% the same test patch...

Rebooting did not solve the issue for me.
I guess there really went something wrong with a newer version of VM or the VM instrument plugin so to say which causes trouble in some scenarios (like mine lol) as I am 99,9% sure I did use MIDI out into the DAW a while back.

I think in the meantime I can just use the FX version without much downsides.. well one downside.. a bit more of routing to get MIDI *INTO* the FX plugin than it would be with the Instrument one.

slowly diving back into VM
I hope you are well
S.

[Steve W]

Over the years I have also had mysterious oddities with midi data and Voltage Modular and no matter how much I tried to pinpoint a consistent cause, I could not pin it down. But I was curious about Colin's test and so I duplicated it but with my own midi monitor tool and using one button for start and a second button for stop.

From the get go, I got FA and FC where I expected to see them. But I did them one at a time with pauses. So I started going crazy pressing the buttons. I "pressed" them manually (that is, with mouse clicks) rather than using an automated process.

Since they are one-byte commands, they should not have been routed to any of the 16 output ports. But every so often an FA or an FC byte was directed to a specific midi output.

At present this module is super simple: the source channel determines the output port.

It seemed that as long as I pressed the Start/Stop buttons at a non-aggressive pace, I got no anomalies, but once I started going crazy with rapid button presses, something got out of whack.

Right now all my debugging is done manually relying on my eyes, ears, brain, etc. A number of ideas for automated and semi-automatic diagnostics are in pencil and paper form. So, I am at a loss to explain the errant data, but I have also seen it.

[Steve W]

Could be coincidence, but whenever the FA went to an output and whenever the FC went to an output, they were directed to the Ath (11th) and the Cth (13th) port respectively. It is almost as if the lower half of the command became the channel. The errant FA only showed up at the 11th [10 + 1] port and the errant FC only showed up at the 13th [12+1] port.

I don't have Ableton either, but I thought I'd share these instances of what looks like errant data in case it might provide any clues to the midi mysteries a number of us have seen.

Oh, in case it's not clear I used some micro bursts as an attempt to see if sending midi data too fast increases the rate at which VM mishandled the midi data.

[ColinP]

You may remember me as a friendly beta tester who retired

Hi S, I thought it was you! I hope you are well.

I was a bit vague about rebooting. I should have said exiting VM and reloading VM. But in the example I mentioned this didn't cure the problem anyway, I had to actually begin a new project and rebuild the exact same patch. Which then did work. It's like some corruption was baked into the saved preset data.

For me the problems don't seem to be related to whether one uses the regular plugin or the FX plugin as the problems happen when running VM standalone. Also it's unrelated to any of my own modules like Song Control. Just using CA's MIDI Out module sometimes doesn't work. But in the case I mentioned earlier the issue of missing MIDI messages seemingly can arise even with purely internal routing (without using the MIDI Out module).

It's frustrating because as Steve says it's so far been impossible to get a situation that is reproducable (I wish I'd saved the .voltagepreset file this last time, but I wasn't in full-on debugging mindset at the time).

It seems to just randomly not work once in a blue moon. Fortunately these problems are extremely rare. I'm not even sure if it's got anything directly to do with VM. It could be some weird Java, WIndows 10 or JUCE issue.

But because it is so intermittent and impossible to reproduce I suspect it's a thread safety issue. And VM seems quite vulnerable to thread safety issues. For instance I'm usually very cautious about editing patches for the first few minutes after running VM if my machine is connected to the internet as it seems this can cause problems including complete crashes where VM just closes down for no apparent reason Nothing shows up in the log files when this happens so I haven't a clue why things crash. VM 2.9.2 seems worse for this than VM 2.7.0 but that's just an impression rather than a hard fact. I suspect there are potential clashes when VM does its catalog update checks as I've never had any problems when offline. And maybe as CA have apparently tinkered with the code here VM 2.9.2 really is more vulnerable than VM 2.7.0?

It may be the case that the mysterious MIDI problems never occur when offline, this is something I've not been able to pin down as the problems are so rare.

[SpaceDog]

Hey Colin!
Thanks for your reply. You may remember me as a friendly beta tester who retired

I contacted the support and they suggested me to try out if I could send MIDI from the FX version of the VM plugin and much to my surprise this worked.

100% the same test patch...

Rebooting did not solve the issue for me.
I guess there really went something wrong with a newer version of VM or the VM instrument plugin so to say which causes trouble in some scenarios (like mine lol) as I am 99,9% sure I did use MIDI out into the DAW a while back.

I think in the meantime I can just use the FX version without much downsides.. well one downside.. a bit more of routing to get MIDI *INTO* the FX plugin than it would be with the Instrument one.

At least one update ago something instantly changed and I was unable to get MIDI OUT working at all. Previously it had just worked 100% of the ime - this was quite irrtating for me as I built my sequencers inside VM, converted all of the clever CV and Gate stuff going on to MIDI (including a lot of modulated CCs) and then sent it out to another VST all within Reaper. No fuss, it just worked seamlessly.

Like you, I contacted Support (albeit after a LOT of isolating everything for testing and checking with MIDI monitors all over the place) and they suggested using the FX version. The fact that it worked and that they responded so quickly with such a definitive answer told me that this wasn't a new issue and I wasn't alone. I haven't tested it for a while, maybe I should.

My point...? For most people it just seems to work perfactly and within different DAWs, but something killed it dead for me and only switching to the FX version made it work again. I stopped caring why it worked just that it did

[ColinP]

Could be coincidence, but whenever the FA went to an output and whenever the FC went to an output, they were directed to the Ath (11th) and the Cth (13th) port respectively. It is almost as if the lower half of the command became the channel. The errant FA only showed up at the 11th [10 + 1] port and the errant FC only showed up at the 13th [12+1] port.

Interesting. It could just be a bug in your code but if not you may have discovered something important.

MIDI Start and Stop are system real-time messages that take up one byte so in both cases the first nibble is F and the second nibble is either A or C as you say.

So in binary start is 11111010 and stop is 11111100

But channel voice messages take three bytes - so for instance note on in binary is 1001nnnn 0kkkkkkk 0vvvvvvv where nnnn is the channel number minus 1 kkkkkkk is the note number and vvvvvvvv is the velocity.

So if a MIDI start or stop message was somehow messed up with the first byte of a channel voice message then nnnn would be 1010 or 1100 which would be interpreted as channel 11 or channel 13. Exactly the result you are seeing.

So I completely agree with your diagnosis, you just need to double-check it's not caused by a bug in your interpretation code.

[ColinP]

Ah! IIRC the MIDI standard actually allows system real-time messages to interrupt other messages.

So a start message (for instance) could occur between the first and second or second and third bytes of a channel voice message.

I think this might be what's causing the problem. Or at least part of the problem!

Although if only a stream of one-byte messages is being transmitted this shouldn't cause any problems, imagine what would happen if these were interleaved with things like note on and note off messages and the high-bit filtering wasn't managed properly.

--- Edited to add...

I can confirm that system real-time messages can indeed interrput other messages, so if this isn't handled properly by VM then things like start, stop, active sensing and especially MIDI clock could cause havoc.

To help ensure accurate timing, System Real Time messages are given priority over other messages, and these single-byte messages may occur anywhere in the data stream (a Real Time message may appear between the status byte and data byte of some other MIDI message).

https://midi.org/about-midi-part-3midi-messages

[utdgrant]

I'm sceptical about system real-time messages interrupting the individual bytes of a MIDI channel message within the VM environment.

All MIDI messages in the VM Java environment are represented by an object of the Java ShortMessage Class. Each complete message is bundled into a self-contained ShortMessage 'packet', regardless of the form it takes on a hardware serial MIDI cable. These 'packets' contain the Command byte, and any associated parameter bytes, without any concept of breaking it down into a serial stream of bytes.

When you transfer a MIDI message from one VM module to another, via a MIDI Cable / MIDI Jack connection, you are sending complete ShortMessage 'packets' rather than a stream of individual serial bytes. It's possible that ShortMessage objects get pushed to the head of the list if they are System Real-Time messages. However, it seems absurd (to me) that there would be a situation whereby a single ShortMessage would, or even could, be treated as non-atomic.