Thank you for this thread! It’s gotten me much farther than I was able to get on my own.
I now have ProP7 and the ATEM talking via MIDI, but there’s a weird - but consistent - stuttering issue when running my macro on the ATEM. It works fine triggering from the ATEM, it works fine triggering from Companion, but when I trigger ProPresenter, it stutters. I made a brief video showing that the connections are working but something is happening when triggering from ProPresenter.
Any thoughts?
Open the module log for the MIDI module (the “>_” icon beside the module name in Companion) and look at what the messages are that are incoming and outgoing.
My guess is that there’s the NoteOn as expected, but maybe a NoteOff or some other message coming in that’s stopping the macro.
The module log will show you all the incoming and outgoing MIDI messages.
Also, having the MIDI IN and MIDI OUT button presets on Companion can be very handy as it will let you know if there’s additional MIDI messages coming in or out that weren’t expected, as the button will flash when MIDI date is received or sent.
Thank you! I tried the debug but it looks “clean” other than the note I hit in the macro from ProPresenter. 
Is there any other connections between pro presenter and the ATEM?
Not specifically (other than the physical network).
I really appreciate your time and thoughts on this. I don’t have a second person locally who could help me with this! 
I don’t know anything about the ATEM or Pro Presenter, but perhaps it’s an issue with loopMIDI? I know that back in the day when I used it, it would do some weird things if I tried to have a single loopMIDI port that did both send and receive, so I would have to create 2 loopMIDI virtual ports, one for send and one for receive. Don’t know if that has anything to do with your issue, but something to maybe check.
I found that out when using loopMIDI with one of my other pieces of software, YammieQ.
https://discourse.checkcheckonetwo.com/t/yammieq-instructions-windows
I’m not sure it’s loopMIDI as the test triggers from Companion work perfectly. I did create an IN and OUT port to segregate the traffic, but that did not affect the result.
I submitted a support ticket with ProPresenter, as there is something seemingly wrong with the connection or how it’s sending MIDI commands. I linked them to this post for review 
Again, thank you for your assistance and offering a forum to ask these questions. I will update this thread if I come across a solution or if ProPresenter has any feedback.
Just following up to see if you figured the problem out yet?
No I have not. I was working with Renewed Vision back and forth for about a week and then the support dried up. I just abandoned the issue for now because I don’t have time to deal with it. The issue till persists exactly as before.
I finally got a chance to do more testing today and realized that it’s more of an issue of the MIDI note being received correctly. When I emulated a MIDI note pressed by a Stream Deck, the same issue happened when the same note was triggered by ProPresenter. You can see the video here: https://youtu.be/6-ch8KN4z5Q
Logs created during this video, along with the Companion configuration file, can be found here: Attachments
Any thoughts? Could loopMIDI be causing some kind of issue? Can MIDI commands “feedback” like analog audio and cause problems? If so, how do you mitigate it?
I’m stumped.
I can’t download the logs, as they are on some Sharepoint site.
My bad. Forgot to change the permissions:
TY. Yeah, so great troubleshooting to get it to this point.
It looks like if you run the action directly from Companion, it works properly. If it receives a MIDI message via LoopMIDI, there’s a problem.
But, what is it that’s actually STOPPING the action on the ATEM? I almost think that somehow a “Note Off” message is being received or something, but dunno where that’s originating from.
Couple things to try:
Thank you for your continued responses!
The TRIGGER functionality works with the ATEM from Companion. Still, if I send a MIDI command via Companion (i.e.–hitting the button to trigger noteon_2_1_1 or any other note), it hiccups all the same.
So it DOES seem like loopMIDI may be the logjam here.
Unfortunately, I’m not the world’s best regarding MIDI. I’ve done some virtual instruments in Reaper but nothing where MIDI controls something else.
I’ll work through your items over the next week or so as I have time. Unfortunately, from what I can tell, Windows is fairly limited regarding MIDI software. I’ll keep looking!
Also, unfortunately, we do not have a Mac on-site to test with.
DING, DONG! THE WITCH IS DEAD!
There were a lot of steps to get to this point so I’ll try to just to the TL;DR here.
loopMIDI was overwhelmed by the ATEM software which was set to “allow MIDI control.” For some reason, the ATEM blasted a NOTE OFF command on every channel MULTIPLE TIMES PER SECOND.
I switched to LoopBe1 (and turned off the MIDI control pref in the ATEM software). Then I reconfigured Companion and ProPresenter to send/receive through LoopBe1, and voila!
Here’s a video of the outcome: https://youtu.be/MzJTCAcCTpQ
Now the flow is:
This way, the operator doesn’t have to worry about clicking “go” on the video and messing with the video switcher simultaneously. With a barebones crew, taking one thing off their plate is a big deal!
Thank you so much for your time with me to offer suggestions and help troubleshoot. I truly appreciate the help!
Congratulations on figuring this out!
It sounds though like the key to this is turning off MIDI control on the ATEM software. I don’t think LoopBe1 would work any differently than loopMIDI.
Perhaps. If I feel industrious I will double-check to see if loopMIDI works with the ATEM preferences corrected If I am able to get to it, I will update my findings here!