Debugging OSC trigger misses

[pinmode]

Video demo of bug: https://youtu.be/y7HnZSreFQc

I don't want to blame MMV for this yet but I'm having a problem verifying that an OSC message was received by MMV. The terminal window in this video is showing a python script that sends OSC messages on the beat. There are intermittent, random misses (see video). I can't think of a reason why the python script would fail to send the messages. I'm assuming that it was sent ok based on the terminal output line because that's when the OSC msg goes out.

On the MMV side, the OSC source does not do anything when the skipped message occurs. I'm wondering if there's a debug mode or logging that I could check to see what happened? Is there any known reason why it might receive an OSC message and not be able to act on it?

Update: I've done a test using the OSC server in this project: https://github.com/bearstech/osc-tools. I'm not seeing any misses. So this makes me suspect MMV a little bit more. Here's the test: https://www.youtube.com/watch?v=0wLMSE3IPmk

[Magic]

In your video, you show the /beat command as being a source for a Global, but then it's unclear as to how this Global is being used in your scene. To help me diagnose the issue, can you provide a screenshot of the module where the Global is actually being used?

[pinmode]

Thanks for your response! Here's the scene.

In this screenshot I'm using JpegFolder to switch still images. In the video it's switching HAP videos using an InputSelector. Just pointing out that there's no difference in behavior.

If you want a longer video to get a bigger sample for what it's doing, let me know and I can post that to YouTube.

[Magic]

Ok thanks. I can't say for sure what's going on, but a user did have a similar issue a while ago, although I can't seem to find that post.

I think what *might* be happening is that you're sending out a 1 and then a 0 very quickly. Magic will only "catch" this if the 0 happens at least one frame after the 1. Otherwise, Magic will just see that the value remains at 0. I suggest you delay sending out the 0 for at least 30 or 40 milliseconds after the 1.

Try that, and if it doesn't work I might have some other ideas.

[pinmode]

Yes - that's how the event works. I've tried a couple "reset" times already and shouldn't have left that info out of the description.

I've tried values of 0.05 (50ms) and 0.15 (150ms) for the time.sleep() in the following python code:

Code: Select all

                # Send OSC messages.
                self.osc_client.send(1)
                def beat_reset():
                     time.sleep(0.15)
                     self.osc_client.send(0)

                thread.start_new_thread( beat_reset, (), )

[Magic]

If you have full control over the Python code, why not just send out an incrementing integer? Then, in Magic, you wouldn't even need to use a Trigger modifier with your JpegFolder's Index parameter; you could just link the parameter directly to the incoming OSC value. Even if you don't like this idea, it might still be a useful test for debugging.

[pinmode]

Yes, that's a better design and might even fix 1/2 of the instances even if it's not the root cause.

[pinmode]

Ok, I've removed that bit of complexity and only send 1 message per beat. Unfortunately, the issue remains. I haven't measured to see whether the miss rate went down yet. At first glance, it's possible that it didn't change.

[Magic]

Ok. I'm not sure what else I could do except try your python script, but that might not be feasible.

It should be pretty easy for me to add some basic console output to log every OSC message, so I will go ahead and do that for the next release.

[pinmode]

Thanks! That would help.

I'm somewhat confident that I've ruled out my python OSC client by counting the misses over the course of 5 minutes using the two versions of that code and also by switching out the server side with the test server mentioned above. Turns out there are zero misses when using the debug server.

optimized client side code (9) - thanks for the suggestion
1:45
2:30
3:03
3:22
4:07
4:27
4:30
4:37
4:45

not optimized client side code (16) - with 2x the OSC messages, the misses increase almost as much
0:08
0:25
0:35
1:25
1:30
1:52
2:04
2:29
2:40
2:50
2:58
4:24
4:37
4:39
4:52

OSC debug server (0) - no misses

Let me know if you want the videos of the tests. My upstream internet connection is terrible right now or I'd put them on YT.

[Magic]

Thanks. I think I *may* have identified a potential bug here. I'll let you know when I have a new version for you to test.

[pinmode]

Whoo! Sounds like a good lead. I'm looking forward to testing that out.

[Magic]

Update: The latest Beta (2.12) should at least improve and hopefully fix this problem, lemme know how it goes...

[pinmode]

I'm no longer noticing this issue in the new version! Have not done a formal test but I've been mixing on a project for days and haven't noticed any skipped OSC signals. Will post again if I collect some data.

THANK YOU SO MUCH! There are things I can do with MMV that can't be done with anything else.