OSC messages applied out of order

  • I've got a setup where MA3 is receiving OSC commands to press and unpress buttons and I'm running into an issue where it appears that incoming commands aren't being applied in the right order. For example, in the attached image you can see a number of Press commands and then the corresponding Unpress commands. However, executor 197 is still on even though the command line shows it should have been turned off. Has anyone else come across this/anyone from MA know how to prevent this from happening? Thank!

  • I have not seen this happen before, but I have not done anything of note with OSC yet. However take a look at the More > System Monitor Window Since it has times and you may see an error or something else that might point you in the right direction.

  • Good idea. Here are the timings from the System Monitor. The first key press down and then up worked fine and in the system monitor they appear in the order:

    1. OSCReceiver - Press

    2. MainTask - Press

    3. OSCReceiver - Unpress

    4. MainTask - Press

    It doesn't work when the order is:

    1. OSCReceiver - Press

    2. OSCReceiver - Unpress

    3. MainTask - Press

    4. MainTask - Unpress

    So maybe this is a bug when two OSC commands relating to the same object arrive before the first one can be processed?

  • Honestly, this is the method I'm using as it's the one I've been able to get working! I've not been able to work out how to see a schema for the OSC addresses on the desk and I can't find docs online so I'm just using /cmd from the example on the OSC doc page. Very open to changing though. The advantage of using Press over directly targeting a function is that way I can reassign the function just like all the other executors so other than not being able to type commands and hit the button (eg. Store <hit the button you want to assign the sequence to>) it acts just like another xkey. If it were possible to do something like "/Page2/Key291,s,Press" that I'm just not aware of then that would be neat.

  • Yeah, that's exactly it - thanks! That's nice that it's not going to spam the command line with messages. It's still doing things in the wrong order if the two messages are received within about 0.03-0.04 seconds of each other though.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!