Troubleshooting OSC
Last updated
Was this helpful?
Last updated
Was this helpful?
OSC Input triggers are very powerful and easy to use, but can be incredibly frustrating when you can't get the triggers to work. This page should walk you through the steps you can try if your Input Triggers are not working.
Make sure you are using the latest version of Spikemark.
Make sure OSC Input is enabled:
Make sure you have your IP addresses set to be compatible.
Make sure you are outputting on the correct port on your device that you are sending the OSC Message from.
Make sure you are listening on that same port in Spikemark.
If you are still having an Issue, try a different port.
Make sure your firewall on both computers are not blocking the port you are sending messages on.
You can even choose to turn off both firewalls for troubleshooting. It is a good choice to make sure you are not connected to the internet when you turn off the firewall.
Lastly, try using a second computer running Spikemark with an OSC Output Stagehand to see if Spikemark can send Spikemark the OSC command. If Spikemark can send Spikemark the commands, but your software can't, we may need to change how you are writing the OSC message.
In some situation, you may use a software that doesn't supply 4-byte null padding as part of their message. In these situations, you may need to adjust how you send the command. Let's walk through an example on how you may make this modification. Let's Say you are trying to send and OSC command to Spikemark. We want to run cue 12 playback 1. We tell you to write an OSC message that looks like this:
However, you find that this command will work properly if you send it from Spikemark, but won't work properly if you send it from your specific software. The reason, is that Spikemark sends this command using a 4-byte null padding format. This means that Spikemark is actually sending a message on the network that looks like:
However, if you wanted to run cue 1234 playback 1, the message would look like this:
OSC operates on a pattern of 4 byte "DWORDS" so different parts of the message have to align with those 4 byte boundaries. The comma indicates the DWORDs before it represented the address, and the data after the comma represents parameter data. The comma is also part of a DWORD, so it has to be padded with null bytes as well. In Low Level Communicator, the convention for sending hexadecimal representation of null bytes is !00 so you would use this to "fill up" any missing bytes to make the DWORD alignment work.
