Martin Mac 101 Profile issues on ION

Software version 2.1 / 2.1.1 Has changed the functionality of the profile of the Martin Mac 101 RGB fixture on the color end. On the color wheel, it created boundaries for the color wheel, as well as affecting the functionality of the hue / saturation controls. I checked the other modes of the profiles, and see the same issues between those. 

I can still operate the fixtures just fine with the red/green/blue encoders, but I used to use the hue / saturation controls exclusively. I use the Martin Mac 101 RGB RAW profile as my mode of choice. If the bounding boxes and the hue / saturation functionality can return to how it was, matching up with a standard RGB fixture color controls, I would greatly appreciate it. Or if someone could walk me through editing a profile (which I've had an amazing ability to screw up in the past), that would also be great. Thanks!

http://martinpro.com/service/downloadfile.asp?name=UM_MAC101_EN_G.pdf&cat=65

 

Parents
  • Hi there,

    The gamut line is new for this fixture in v2.1.0. When it appears, this means we have definitive color data from a real-life fixture, and the line illustrates the most saturated color possible on that fixture. In this, it isn't necessarily limiting the colors as much as it is showing you the colors it can actually go to. Color matching data is added to fixtures as time goes on, as it's a little more time intensive to get a physical fixture for testing. 

    It isn't possible to edit this out of the profile, as it's buried a bit deeper in the fixture profile. In checking, it seems that the Mac 101 Raw and RGB modes have this color gamut data, while the Basic, CLD, CT, and WRM did not have this applied.

    We can look at generating an alternate version of the profile if needed -- let me know.

    Thanks!

    Hans

  • Having a custom profile built would be good. I run the fixtures in RAW mode for maximum brightness and capability. 

    I'm a little confused on how accurate the gamut wheel is - according to the new restrictions, I'm cut off from generating pure colors - wouldn't logically an RGB fixture be capable of generating pure colors? The restrictions are pretty far from the actual red, green, and blue colors on the color wheel, so me thinking logically questions who generated this data and if they did something wrong. comparatively, it's like I'm looking at the gamut restrictions for a discharge fixture with poor CMY flags, not an RGB color mixing fixture. Until I see a fixture that generates a greener green than, well, green, I question the logic here. 

  • The gamut does not restrict anything. It is informational.

    RGB mixing fixtures that use LEDs are incapable of covering the visible spectrum. So their greenest green isn't the greenest green possible.

  • That's not true - If it were informational, it wouldn't affect the console's ability to program. I know that LED's are not able to recreate true colors, but to the human eye, they can appear pure, but this gamut measurement tying to the color wheel changes the user's ability to program effectively. 
    It's frustrating because the gamut affects the usage of all color controls. Rotating a single click on my encoder at certain hues will make the RGB values jump by large percentages, and change the colors significantly (ie, going from yellow to green). If I've dialed up the colors using hue / saturation or the color wheel, then this also screws up the crossfading between cues, as some colors will approach and go by much quicker than others, making the visual crossfades appear rough. The values of RGB commands being sent out will follow the curve of the gamut restrictions, which appear to change speed visually onstage. It no longer visually appears to go from Color A to Color B smoothly, but jaggedly as it follows the gamut restrictions. I can no longer tell my console 'Hue 120' and get a pure green output - the gamut changes have messed that up. I used to know the hue values so I could quickly call out colors, but now all of those colors are wrong. I can still work in the red, green, and blue encoders, but it's a giant time suck to work those fixtures now. 
    I guess the original problem is that the gamut spectrum measurements you input, despite good intentions, forces the RGB color mixing system to follow it's curves and affect the functionality desirable when using hue / saturation controls and the seamless crossfading between colors. While I used to program these particular fixtures using the hue / saturation encoders and color wheel, I've been forced to abandon them, which is costing me time. 
    I hope what I've written here makes sense. 
  • I think what you're seeing is colour fades taking place in the "Hue/Saturation" colour space.
    - This type of colour fade goes around the colour picker (Hue) and radially in/out (Sat)

    You want the fades to be in the "Native" (eg RGB) colour space instead.

    There is a setting in [Displays] [Setup] [Show] {Show Settings} called "Allow HS Fades". Turn that off to disable Hue Sat colour fades.

    Further options:

    When Allow HS Fades is on, the type of colour fade you get depends on whether the values are recorded as "Hue/Sat" or "Native" (eg RGB).
    Use the softkey {Color Format} to swap between these.

    Also, if you turn off the setting "Create Virtual HSB" then you will always record in "Native".

    (The above settings obviously don't apply to a fixture that's natively Hue/Sat.)

  • Richard,

       Super appreciate the help on that HS fade stuff. That'll help how my team programs quite a bit. 

  •   I'm not at my console right now - where is the "Create Virtual HSB" setting?  Is that in show settings as well?  I'd like to keep HS fades enabled for colour effects, but I'm constantly using the Colour Format button to swap into RGB or CMY, and having it record there first would be a preferable default.

     

    Heather

  • Is there any progress on custom creating a Mac 101 profile?? 

Reply Children
No Data
Related