• Date
    TJ Cornish
  • Date
  • Replies 1 reply
  • Subscribers 66 subscribers
  • Views 2568 views
  • Users 0 members are here

Palette recording problem with ML software 3.0.2.9.0.43

I just updated to the above version yesterday and since then am having trouble with the color palette respecting the values I'm trying to save.

I'm using Chauvet SlimPar Pro RGBA fixtures in 10-channel control mode via a user personality I created. Layout is as follows:

1: intensity

2: Red

3: Green

4: Blue

5: Amber

6-10 - other non-color settings.

The device works fine in Device Parameter mode- the hue/sat faders perform normally, and factory saved palettes recall correctly.

The problem I'm having is that when I re-save a palette color, the values that are stored are not exactly what I've set.  It seems that all color channels are saved having a minimum value of at least 1 - not zero.  For example:  If I try to save a straight Red - 100,0,0,0, when recalled, that palette color lights all of the lights of the fixture slightly - appears to recall as 100,1,1,1.  I haven't figured out how to read the value on the console that is stored in the palette, but it appears to be around 1.

 

My procedure is as follows: 

1: Select devices

2: Go to Devices Param 1 page

3: Set desired color with Hue/Sat, then fine tune with encoders

4: Press Record Pal/Group

5: Press Color

6: Press desired palette button.

 

I then recall a different color to reset the fixture, then recall the color I just saved.  The color that is recalled is not the same as what I programmed - all channels are on slightly.  The color is sort of close to what I saved, but not exactly.  This is clearly visible with colors that don't use all of the fixture elements.

I did not have trouble with this in earlier versions of the console software.

Is this a bug?  Some kind of rounding error between CMY and RGBA?

 

Thanks,

TJ

Parents

  • I talked with ETC support, and they mentioned that this problem was created in 3.02 to solve a problem created in earlier versions - the need to have a "don't care" state for a parameter. 

     

    DMX allows values of 0-255, all of which the fixture receives and interprets.  The board needed another value to indicate that the paramter should be ignored, or not stored.  They chose "0" to represent this state.

    Unfortunately this means that the smallest value that can be stored for parameters is "1".  This doesn't seem like a big deal, but it actually is - in my case turning on the other LED channels makes a noticable color shift.  I suspect this has other consequences as well - moving lights where the "0" value is important in some function, etc.

    My suggestion was to steal 255 and then reinterpret 254 as full output.  Hopefully this will be fixed soon.

     

Reply

  • I talked with ETC support, and they mentioned that this problem was created in 3.02 to solve a problem created in earlier versions - the need to have a "don't care" state for a parameter. 

     

    DMX allows values of 0-255, all of which the fixture receives and interprets.  The board needed another value to indicate that the paramter should be ignored, or not stored.  They chose "0" to represent this state.

    Unfortunately this means that the smallest value that can be stored for parameters is "1".  This doesn't seem like a big deal, but it actually is - in my case turning on the other LED channels makes a noticable color shift.  I suspect this has other consequences as well - moving lights where the "0" value is important in some function, etc.

    My suggestion was to steal 255 and then reinterpret 254 as full output.  Hopefully this will be fixed soon.

     

Children
No Data
Related

www.etcconnect.com