Creating and editing color palettes

I am a little embarrassed to have to ask this, but I need help developing a reasonable strategy for dealing with color palettes on the Hog 4 platform.

My goal is to get to a point where I always start with a custom generic show file so I am not constantly recreating color and beam plaettes, views, custom effects, etc. As a point of reference, in the Hog2 days it was simple enough to select a single fixture of each fixture type to create palettes that would be recognized by any number of those same fixtures. I realize that the GLOBAL, PER TYPE and PER FIXTURE options are far more powerful but somewhere along the line I get fouled up. This problem is exacerbated when I have to start editing those palettes which I have to do all the time.

My plan would be to start with one instance of as many different fixtures as possible to create my standard color palettes. I would assume all of these palettes would be recorded PER TYPE. Whenever I start a new event, I would then merge whatever new fixtures might be necessary to my standard show file before moving on to actual prgramming thereby increasing the number of fixtures in that generic file. I am again assuming I would merge these palettes using PER TYPE.

By the way, I am aware that the HOG OS more or less requires one to stay in a single color model per fixture type. I like the idea of the HS model as it certainly makes the effects engine and detailed programming far more powerful. I am not convinced, however, that HS is truly the best model choice. I am also not entirely sure if using white and/or amber LED's with the HS model constitutes mixing color models.

Since moving into Hog 3 and now Hog 4, I have constantly run into issues with colors that will not update or that just play back incorrectly. I am fairly certain that some problems may occur due to my potentially forgetting to choose PER TYPE when recording. There have been times that the only way I can "repair" a specific color might be to use the "PER FIXTURE" option.

As I mentioned in another thread, I would like to have more than one standard color palette so that I can switch back and forth between them based on current usage. I want to make certain, before I invest any time in the process of creating a standard show file, that I am doing things in a way that will work. To some extent I have the same problem with beam parameters. It does not seem like this should be that difficult but it has been driving me nuts. Any thoughts?
Parents
  • [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.
Reply
  • [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.
Children
No Data