Creating and editing color palettes

I was hoping to see some answers to your questions, like you I seem to have some difficulties very much like yourself regarding colour and beam parameters.

Color and Beam palettes are record as global as a standard. So for example you create them with one fixture(type), then they are available for all other fixture(types).
As soon as you edit or merge some fixtures they will get more complex, you can see this when you open the palette.
So your way/idea of adding in per type/fixture is correct.
Please remember: If you store a palette only for color mixing and store later also some color wheel-infos into this palette they won´t be back-referenced in existing cues. (Andy this is your issue, I know)
About HS vx. CMY, i prefer HS, because it is more accurate and efx are easier to create. Also when talking to other departments like print or graphics, HS is a "global" language.
When dealing with LED with amber or white, I also stay in HS and create some more palettes including white/amber values and have white/amber always be part of my HS-Preset even if they are at 0%.
Maybe we get back the calibrated colors ony day or an option to calibrate fixtures ourself. Then the whole process would be easier, because the console knows the available colorrange of the fixtures and we would only need to change type and repatch

I am no sure this is so black or white...excuse the pun.

I have had auto coloured buttons changing colour completely, in the case of a fixture that had inverted RGB values, so my yellow palette went blue, the palette when selected gave yellow, but programming using yellow gave blue...... In that case making a copy of the fixture and fixing the values would have been a better choice of outcome, but I often wonder why programming using palettes, sometimes seems hit or miss.

Also and certainly using fixtures that might have a white or amber channel, but also fixtures with colour correction channels can be awkward. Often I make an edit, looks good on stage and then only to find when I have updated, merged the colour goes back to what it was. All combinations of editing seem to not give back what i just re-recorded.

I seem to have problems regarding Robe fixtures when using gobo rotation, as they seem to have fixed as gobo 1 and index/rotation as gobo 2, as I programmed with a fixture that has index/rotation on gobo one, I find even though I update gobo palettes and rotation palettes, the rotation never plays back although the programming is referencing the slow rotation palette.

We talked about this Marc I know, but I was less than happy arriving at a gig and having a Mac 500 do pink and not amber in programming, but being able to select amber from the palette, output window shows amber, the eye see's pink.

It seems to me and certainly when you have a show picking up whatever is at the gig that you need to do a CMY fixture, the a colour wheel fixture, then an RGB + W, + Amber, rather than doing programming with one type of fixture, which I have always managed on other console's.

I feel not in control sometimes, in my mind i expect a any programming using palettes to reference what is in the palette on an edit without question, blue is blue whatever the fixture type. I feel somewhere along the line I am missing the point of the current system and thus it causes a lot of problems, although I am learning a lot about editing fixtures... :-)

Thanks for the information. I believe I am tracking with you on this. Oh, and happy New Year by the way. Let me ask this:

When editing a color palette (which is where everything goes right down the tubes for me) can I select a type of fixture whether a single fixture or all of a particular type, modify a color (using the appropriate color model of course) and then press "RECORD" "PER TYPE" press the appropriate color palette in the directory "MERGE"? I have a tendency to do this to make quick updates to colors when I see something I don't like. Is there a better approach?

To clarify, almost every project I do is programmed in advance in pre-visualization. Once onsite I am then going over the entire set of cues (which could be in the thousands) with very limited time. So I often just start running through things I know I have to touch up quickly such as focuses, beam edges, strobe rates etc. and often times I am just doing that on the fly as I run cues and addressing the issues that come up. That is why I find myself editing random colors on the fly as opposed to simply going through the entire palette range with all fixtures.

On other notes, when you say that you have additional palettes for White and Amber, do you mean those values then can be "piled" on to your HS palettes? For example, if I have a WHITE palette in HS (0% saturation and any hue) for an RGBAW fixture, do you then have a second palette that has a white value of 100% an amber value of maybe somewhere between 50%-80% or so that you can add to the HS palette in your programming? Does that then cause the same problem as mixing color models in your programming?

To me that is one serious issues with the Hog OS that I had hoped would have been resolved in the 4 series and that is color modeling. I have never understood why you can't move seamlessly between models. It has always seemed to me that if I entered a hue value of 0 and a saturation value of 100% and then decide to switch to CMY that the values should simply be C-0, M-100, Y-100 and vice versa. This is, of course not the case and is where a lot of color issues come into play with the desk. I, like you prefer the idea of HS mixing as effects are FAR more powerful and intuitive with a 2 parameter model then a three parameter model. Depending on the type of rig, there can be a lot of other potential benefits as well. I have found that, regardless of what the manual says, I get a lot of unwanted transitions in HS. When cross fading between saturated colors you are, in effect, simply changing the hue value so for example a blue to yellow cross fade will take you through a saturated green as opposed to cross fading between C/M and Y.

Any suggestions, tips etc. are appreciated. Perhaps my entire approach is incorrect.

Marc,
I re-read your post and I believe you are stating that you are adding white and amber (and as 128 mentioned, color correction) values to your HS parameters. I would like to do this as well but it seems that fixtures want to then insert CMY values instead. Are you successful with this?

I think I am struggling with the same or similar issues as 128. I have often just assumed in editing that I have inadvertently forgotten to use PER TYPE but I have no way to really know that. Perhaps that should be a record default preference? "Record all color palettes as ______". "Record all beam palettes as _________". That might solve everything.

From my perspective I just want to get back to where I was prior to the Hog 3 where I had a generic show that already had every fixture I normally used pre-programmed before I ever started on a show. The only time I ever created color or beam palettes was if I was using a new fixture...easy. This very simple programming process has become a huge time suck and source of frustration to me on an otherwise very elegant desk.

Andy, do you remember which fixtures caused this? Beacuse this would be a bug, never had seen this that inverted CMY/RGB caused this.

I agree that auto-update of colors sometimes did not work correct, i had this as well, but never find a good repro. Will try to figure that out. So that development could investigate.

Your problem with Gobo rotation is indeed the same thing like adding a colorwheel to a colormixing palette after creating the palette and already programmed cues with it.
The palette references to Gobo 1 and you are doing something wth gobo 2 which is different. So this is something which can be solved be editing the library. I agree as well like said in other posts, that other console provied the option that if I add infos to a palette like adding focus to a gobo palette or colorwheel to a cmy all programmed cues have this updated infos. It has two sides: what about if you have created some looks with a gobo, gobo 2, focus/zoom, iris in it... typical background pojection for example: Now you store a focus in the used gobo and gobo 2 palettes... How should the reference work? From palette gobo 1 or gobo 2? Also your look might get destroyed because of another focus value... So this might cause a lot of problems as well.
The safe way is what you are saying Andy, this is something what is going to the fact that we use real-world values. A CMY real world is something else than a colorwheel real world. I agree that the reference to the palette is something to thing about, but also keep the bad sides of this in mind (discribed above).
For you blue is blue, but for the console blue without colorwheel infos is something else the blue with color-wheel infos.
I know that you would like to see the auto-update of all cues when adding parameters to a palette. I see the advantages of it but also the dangers described above.

Scott

you dont need to do a per type for colors. The console does it for you.
Try this:
Patch some StudioColor, Cyberlights and Studiobeams

Create some CMY colors with a StudioColor.
They are now available also for the other types. (open the colors and you see that it is a global palette)

Now select the Cybers, change the values and merge them into the palettes
Open tha palettes, you should see all fixtures except cybers and cybers

Now the same thing for Studiobeams...
Same result. In Color and Beam the separation per type is automatically done by the console.

About HS, I have to check, I think so.... Was a while that i used rgbwa fixtures....
Hope that my memories are not wrong. If so, I´m sorry

See some screenshots here:
www.dropbox.com/sh/xa3tnh0utfzn9h5/Pgz-BUizBe

I took the auto palette red (step 1)
Merged some other values step 2-5 (always took all fixtures, but works also of you just take one fixture)
Only merging, NO per type option selected

In Step 6 I edited one single fixture, here I took the per fixture option to be sure that it wont change for the whole type.

[QUOTE=Tnsquint1;72303]
On other notes, when you say that you have additional palettes for White and Amber, do you mean those values then can be "piled" on to your HS palettes? For example, if I have a WHITE palette in HS (0% saturation and any hue) for an RGBAW fixture, do you then have a second palette that has a white value of 100% an amber value of maybe somewhere between 50%-80% or so that you can add to the HS palette in your programming? Does that then cause the same problem as mixing color models in your programming?



Yes, I have a user kind that gives me seperated color parameters for HS, amber and white.:
www.dropbox.com/s/6htemxy4rq16xs0/Screenshot%202014-01-02%2013.58.06.png

So I create first my HS Colors and then some amber/white palettes to add on top of it.

See screenshot:
www.dropbox.com/s/mkjlea50ouofk8c/Screenshot%202014-01-02%2013.45.12.png
Color 81 is a HS color, Color 82 is an amber/white color

Also when working with this userkind you can create HSAW palettes, color 86 was created using this userkind, HS stays active even if you bring in white and/or amber:
www.dropbox.com/s/w80iikk6hkyy3s7/Screenshot%202014-01-02%2013.55.33.png

[QUOTE=MLorenz;72305]Andy, do you remember which fixtures caused this? Beacuse this would be a bug, never had seen this that inverted CMY/RGB caused this.

I agree that auto-update of colors sometimes did not work correct, i had this as well, but never find a good repro. Will try to figure that out. So that development could investigate.

Your problem with Gobo rotation is indeed the same thing like adding a colorwheel to a colormixing palette after creating the palette and already programmed cues with it.
The palette references to Gobo 1 and you are doing something wth gobo 2 which is different. So this is something which can be solved be editing the library. I agree as well like said in other posts, that other console provied the option that if I add infos to a palette like adding focus to a gobo palette or colorwheel to a cmy all programmed cues have this updated infos. It has two sides: what about if you have created some looks with a gobo, gobo 2, focus/zoom, iris in it... typical background pojection for example: Now you store a focus in the used gobo and gobo 2 palettes... How should the reference work? From palette gobo 1 or gobo 2? Also your look might get destroyed because of another focus value... So this might cause a lot of problems as well.
The safe way is what you are saying Andy, this is something what is going to the fact that we use real-world values. A CMY real world is something else than a colorwheel real world. I agree that the reference to the palette is something to thing about, but also keep the bad sides of this in mind (discribed above).
For you blue is blue, but for the console blue without colorwheel infos is something else the blue with color-wheel infos.
I know that you would like to see the auto-update of all cues when adding parameters to a palette. I see the advantages of it but also the dangers described above.

I agree Marc with much of what you say, how cue information interacts from palette information is more complex here due to real world values, while it helps a lot of fixture swapping, speeding up many aspects of taking hold of a show with different fixtures, it does on the same token slow other things down to the point of not getting it to do what you want or spending time editing fixture files.

We talked about finding a fixture to program with that has everything so to speak, so it has two rotating gobo wheels, or its a CMY fixture with 2 colour wheels. Perhaps my need to have a core show which is never used in real life, a show that gets cut to the bone or I need to replicate fixtures, swap fixtures to the degree of making an RBG par can be a VL3500 wash in todays show etc is a tough one, certainly my last console was better at this by a long way, however in other ways its not anywhere near as good as the Hog.

I have to re-program this show anyway, but still wondering the best way to do this. I have the problem with the colour wheel one not allowing the encoder to select colour in the current show and I have found a few fixtures where the colour slot info is out, so thats another fixture file edit to correct that. Now i found a way to have the encoder function for colour and still merge stuff from the original show i am keen to start again, but still thinking of the best way to do this and not have so many problems.