Is there need for a generic personality system?

[numberwrong]

We've all been there, personality is written wrong or it doesn't exist

 

Wouldn't it be better if there was some standard lighting personality format with the absolute works, DMX, Gobos, Colours, Pictures CAD drawings manuals, flying weights, power consumption the lot.

 

This way the manufactures could write the file and all desks/CADs could use it. The desk manufactures could create a program to run the 'standard' personality through using that files info to create a usable personality for that console. In time consoles would except the 'standard' format with no modification.

 

What do ya think? totally pointless or a good idea?http://www.blue-room.org.uk/public/style_emoticons/default/huh.gif

[Stuart91]

Something similar to what you are after already within the audio world, in the form of the "Common Loudspeaker Format", more information here.

 

Whilst there might be some technical challenges, I suspect the real issue is finding agreement between the various manufacturers. When you consider that they can't even agree on 5 or 3 pin connectors for DMX, it's hard to hold out much hope for an agreement on something much more complicated.

[jonhole]

There is a VERY basic form of this available via RDM which is a start, but nowhere near detailed enough to completely replace a library

[alexanderjoseph]

As far as I know there are two companies supplying the libraries for most of the lighting desk manufacturers.

 

Atlabase

Carallon

Something similar to what you are after already within the audio world, in the form of the "Common Loudspeaker Format", more information here.

 

Whilst there might be some technical challenges, I suspect the real issue is finding agreement between the various manufacturers. When you consider that they can't even agree on 5 or 3 pin connectors for DMX, it's hard to hold out much hope for an agreement on something much more complicated.

 

ANSI E1.11 defines that DMX has to use 5 pin XLR. If it is not 5 pin it is not DMX.

[lightsource]

 

When you consider that they can't even agree on 5 or 3 pin connectors for DMX, it's hard to hold out much hope for an agreement on something much more complicated.

 

ANSI E1.11 defines that DMX has to use 5 pin XLR. If it is not 5 pin it is not DMX.

 

And some manufactures even swap pin 2 and pin 3 around on a 3 pin DMX fixture ;)

[Stuart91]

ANSI E1.11 defines that DMX has to use 5 pin XLR. If it is not 5 pin it is not DMX.

 

That reinforces my earlier point - a sensible standard was established, and some manufacturers chose to ignore it, presumably so they could save a few pennies per connector by using the cheaper 3 pin XLRs.

 

Getting agreement on a common personality format will be tricky enough, but making sure all manufacturers stick to it will be the real challenge.

[indyld]

http://www.onstagelighting.co.uk/intelligent-lighting/fixture-personality-files/

End of article and check the comments from people in the personality and control world.

I've been going on about this since I don't know when.

Carrallon etc. produce files that still have to be imported, say, into ETC format. A lot of this comes down to how different desks use the personality and no one really having must interest in standards. I discussed the above with people involved via a meeting on a stand at PLASA some years ago but the response was very much "lovely idea, not gonna happen."

There are issues with such a standard restricting fixture development, even more so at the current pace of innovation and variety in functionality.

 

Edit to add: Of course, if desk makers all decide to farm out the personality spadework to, say, Carallon, then there will be a standard. It just won't be open.

[niclights]

Usually the reason personalities are wrong or don't exist is because the fixture manufacturers have provided poor/incorrect or no documentation. In fact very few manage to document channel mappings in a useful way for personality authors. Even if you did get some to produce files I think the chances are there would be more errors than there are now.

 

Beyond that there are some things that are currently console specific that could not be implemented or interpreted from a generic file. For example a console personality author might try to ensure that, from a UI level, a low iris value is closed and a high value is open. Or conditional systems such as 'if gobo ch = x then gobo rot ch = index, if gobo ch = y then gobo rot ch = spin'. If we want to be able to keep control nice and simple for the operator then things like ranges would have to be standardised and conditions have to be dropped and replaced with either reduced resolution control or more discreet channels.

 

Currently where a fixture manufacturer does not provide documentation a personality author might rely on information from a single third party which is risky. Similarly, if a personality is faulty or believed to be so then there might only be a single bug report. This is difficult to administrate, often complicated by translation issues and is probably impossible to prove either way.

 

I would suggest that a better solution is to provide an open resource for channel mappings. The latter would be something along the lines of Wiki where anyone can edit or contribute, theoretically ending up with an accurate result. Such a resource could then be referenced by console manufacturers or end users when creating or modifying a personality.

[paulears]

Great idea, but look how tricky it was to get everyone to conform to the MIDI spec, back in the 80s. At least they did get the connector screwed down 100% though.

[MrBoomal]

Great idea, but look how tricky it was to get everyone to conform to the MIDI spec, back in the 80s. At least they did get the connector screwed down 100% though.

 

 

Indeed. There was a chance it was going to be a standard 3 pin XLR. Which is what Octave electronics used on there Voyetra 8 synthesizer.

[kitlane]

Is this not what the DDL (Device Description Language) in ACN (Architecture for Control Networks) is for?

 

Yes...*sigh*... I know what you're going to say ......

[Wernlund]

While this may seem like a fairly straightforward and trivial task at first glance, I can assure you it is far from, and the reasons why are so many I wouldn't even know where to start. Here's a few:

 

- The vast variety of different technology out there that needs to be 'standardized' (to some level)

- Differences in terminology and interpretation

- Widely varying levels of understanding among engineers at both ends (lamp makers vs console developers)

- Sheer volume (we have 7000 fixtures in AtlaBase now,.. spend one hour on each and you've got some 3-4 years of work there..)

- Product documentation with gaps, errors, conflicts and various mismatches

- Differences in infrastructure and needs among consoles, as well as visualizers

- Infrastructural editing and documentation needs (database/storage/synchronization etc)

 

As a partner in AtlaBase I know that these can all be addressed, but from my experience you need to invest quite a lot of hours to reach the level of quality needed by console and visualizer manufacturers. In the end the consumers are commercial entities and most of the people that would be willing to participate in a crowd-sourcing solution wouldn't really be interested in working beyond what would be required to solve their immediate and personal needs.

 

Cheers,

Lars