E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   IDENTIFY_ORIENTATION (http://www.rdmprotocol.org/forums/showthread.php?t=1114)

owaits September 14th, 2011 01:21 PM

I am not quite sure how you go about requesting new things to be added to RDM so I am posting here with the hope that someone will point me in the right direction.

Walking around PLASA this year and thinking about possibilities for RDM it has ocurred to me that as well as an identify command we also need an identify orientation command.

If you asked a fixture to identify its orientation then it would go into a state which would show the user which way around the device was hung. So for a moving head fixture it would tilt to 45% instead of streat down to show where the front of the fixture is. For an LED batten it would set the left most cell to red and the right most cell to green. A media server indicate the left section of the screen with red and right with green. An intensity fixture could use different intensities.

Obviously not all fixtures would support this but it has many applications.

- you can check whether all your fixtures are hung correctly, any that are wrong might need tilt inverting.
- setting up LED mapping on a media server can use it to set the angle of the fixture.
- see whether the image on a projector needs flipping.
- use it to see how fixtures in a rig you are not familiar with are hung.

I would imagine that it would either be an extra command or add a type to the identify packet.

Whilst thinking of types of identify I also thought that you may want an identify stealth. This would identify a fixture in a way that an audience is not likely to notice. So for a moving head it may nod or blink the settings screen or a dimmer pack might blink the channel LED. This would allow a tech to identify a fixture in the rig during a performance un-noticed by the audience.

sblair September 14th, 2011 03:27 PM

The formal way to request a new message be added is when there is a draft revision in Public Review. That being said, this is generally the best place to discuss it as there are numerous Task Group members here for the RDM standard.

Your request for the "Identify Stealth" mode has already been done. The E1.37-1 document that adds additional RDM PID's includes an IDENTIFY_MODE command which basically lets you set the IDENTIFY command to operate in "loud" or "silent" mode.

The identify orientation is an interesting one that hasn't come up before. For moving lights I'm not sure I see a huge need for it, as you already have an existing PAN/TILT INVERT and SWAP via RDM, as well as just patching the device and seeing the orientation. With moving fixtures it is generally just as easy to see that the physical orientation they are physically hung in.

With LED battens, tiles, strips it can be a bit more messy and less obvious. There is likely going to be another round of new PID's geared towards LED and video devices. This may be a good place to do something to address that issue.

owaits September 14th, 2011 03:50 PM

When will it next be going into public review? I might have forgotten about it by then :)

I think it is applicable to moving lights. I often turn up to rigs once the fixtures have been hung and have to go through the fixtures to work out which ones need channels inverting because they have hung them the wrong way around. You might say to get better crew that hang the lights the right way but I don't always have this luxury. If the crew could identify which fixtures are hung the wrong way (with RDM tools) and invert them before I arrive with the lighting console it saves valuable time.

You could possibly work out in software what channels to change to identify this but it is difficult as every light would require different channel values to see the orientation.

Great to see the stealth mode is already in the next version! I have not purchased this yet.

P.S. You mention additional PIDs for video. My list for this is building up and I will prob post them here soon as well.

sblair September 14th, 2011 04:05 PM

That's exactly why I said this is probably the most practical place to request it :) The 2010 revision of E1.20 was just recently released so it won't be out again for a couple years most likely. That being said we are dealing with adding new PID's as new documents so that we aren't re-opening the core document. E1.37-1 with the IDENTIFY_MODE command is in the final publication stages now so it is done with all it's Public Review cycles. It would have been the best place to have requested the new PID be considered. E1.37-2 has not even been written yet. It is still just a glimmer in my eye, but it will likely be the one primarily focusing on LED and video devices which means we may be able to address some of this in that when it gets written. Please post feel free to start a new thread on that topic and post your entire wish list there. This is the best time to get them in as it is much easier to try and incorporate them when the document is being written than it is afterwards.

All the threads in the forums here do get routinely reviewed by the Task Group in looking at issues we need to address.


All times are GMT -6. The time now is 11:25 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.