integer Display_count=2; // number of displays you want to track.
DEFINE_VARIABLE
volatile integer Current_Source[Display_count]
// set or read these cells of the integer array to set/read the current source.
Current_Sourc[1] is the integer id for display one
Current_Sourc[2] is the integer id for display two
If its a switcher like DVX with feedback I like to track when an output switches to an input, then I enter that information to an StatusOutput array. This way no matter if from an input switch from code, manually on the front of the display or from the web gui its actually what the display is selected to.
OK, but how do I get the RMSVirtualDeviceMonitor module to send tracking data for more than one device, and show those source selections separately in a room in RMS? I can remove the MutEx designation, but then I get multiple selections active at the same time for one device, not mutually exclusive selection tracking for 2 different devices.
OK, but how do I get the RMSVirtualDeviceMonitor module to send tracking data for more than one device, and show those source selections separately in a room in RMS? I can remove the MutEx designation, but then I get multiple selections active at the same time for one device, not mutually exclusive selection tracking for 2 different devices.
Oooooh... RMS...
that's the danger of browsing the forum the way I do. I didn't pay attention to which section the post was posted. Sorry about that. I thought the question was odd. But, it was just me being odd.
If you're using the AMX SDK, you'll need to create a tracking module for each display output. The best advice on the AMX SDK is to remember that they almost never take into account that there may be more than one of a thing. They just don't do arrays. Their solution is to simply burn up another huge chunk of resources to do the same simple task again.
The under-the-hood truth about the SDK is that it's basically converting everything down to a set of commands that get sent to and from RMS. The RMS commands are easier to understand (IMHO) than the SDK. The commands are all built within a framework that you can easily construct your own using arrays and so forth. It's actually pretty "programming bloat free" As I've said, I built my own RMS interface. It's one module and covers everything with no regard to how many devices you want to use, what features/monitoring/etc... per device with no regard to device type.
If you've ever worked with SQL databases before, I highly encourage you to ditch the SDK and roll your own interface. You'll spend most of your development time in the back 20 pages of the SDK's manual, not combing through the front 80.
I feel like I've make fairly quick progress getting the results I want using the SDK so far. But yeah, this "One Of" issue drives me nuts sometimes. Considering I've already rolled my own one-off for tracking lamp hours and a few other things, I'm pretty sure I could code my own communications with RMS, and it would be lighter and tighter than the SDK stuff. But my time is so limited...
I think in the short term I'll just cut functionality that the SDK can't handle, then in the longer term, the reality is that I'll never have time to write my own code and update systems. So whatever I do now, under time pressure, we're stuck with indefinitely.
Comments
integer Display_count=2; // number of displays you want to track.
DEFINE_VARIABLE
volatile integer Current_Source[Display_count]
// set or read these cells of the integer array to set/read the current source.
Current_Sourc[1] is the integer id for display one
Current_Sourc[2] is the integer id for display two
Oooooh... RMS...
that's the danger of browsing the forum the way I do. I didn't pay attention to which section the post was posted. Sorry about that. I thought the question was odd. But, it was just me being odd.
If you're using the AMX SDK, you'll need to create a tracking module for each display output. The best advice on the AMX SDK is to remember that they almost never take into account that there may be more than one of a thing. They just don't do arrays. Their solution is to simply burn up another huge chunk of resources to do the same simple task again.
The under-the-hood truth about the SDK is that it's basically converting everything down to a set of commands that get sent to and from RMS. The RMS commands are easier to understand (IMHO) than the SDK. The commands are all built within a framework that you can easily construct your own using arrays and so forth. It's actually pretty "programming bloat free" As I've said, I built my own RMS interface. It's one module and covers everything with no regard to how many devices you want to use, what features/monitoring/etc... per device with no regard to device type.
If you've ever worked with SQL databases before, I highly encourage you to ditch the SDK and roll your own interface. You'll spend most of your development time in the back 20 pages of the SDK's manual, not combing through the front 80.
I think in the short term I'll just cut functionality that the SDK can't handle, then in the longer term, the reality is that I'll never have time to write my own code and update systems. So whatever I do now, under time pressure, we're stuck with indefinitely.
I hate it when all the choices basically suck.