View Single Post
Old April 23rd, 2013   #7
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Unfortunately, RDM will probably never provide enough information to eliminate the need for console personality libraries, especially for something as complex as a media server. Conceptually, it's the same problem as trying to define a universal library format: How do you define one data model that can describe every conceivable kind of control data in a way that is meaningful to both the controller, and the responder?

Since consoles will still have personality libraries, you may want to extend the library data for your controller to include information on how to recognize each kind of fixture via RDM. You're unlikely to find one library matching technique that will work for all cases. As you suggested, using Model ID is probably the best case provided that the responder implements it this way. When the responder has different behavior, you may have to resort to string matching within the various _DESCRIPTION PIDs in combination with other techniques.

As a last resort for poorly implemented responders, there's always the option to present the user with a "I've found a Type X media server with 6 layers. Please choose a library for each layer" message. Giving the user 4 or 5 layer types to pick from is still better than having to manually patch everything from scratch that you have to do without RDM. Sadly, this is already required for some responders. For example, some models of the SeaChanger use the same model ID for the CMY+Green version and the CMY+Fader version, so there's no way to differentiate between them in software. It's always a bit of a shock the first time you try to dim a fixture and it goes bright green...

Last edited by ericthegeek; April 23rd, 2013 at 01:55 PM. Reason: Spelling Correction
ericthegeek is offline   Reply With Quote