Hog III Novice

cormacjackcormacjack Registered User, DL Beta
Hi All,
having been a Hog II user for some time i'm going to start my first run of show's on an IPC in hog III mode.
Most of you are way ahead of me so i'm looking for some help setting up a basic show.
I want the show i create to be something i can continue to use in festival situations over the summer so anything i start now will be the basis for my festival show later in the year.
Any tips or info regarding building pallettes,cuelists or patching would be of a big help.

Thanks in advance C :welcome:

Comments

  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    While some of the syntax is different, you can use the same logic for laying out your groups and palettes for busking as you did on the Wholehog 2.

    Is there anything specific you were wondering about or are there any particular areas you'd like advice with?

    Here's a few things to get you started:

    FADE CHANGES
    There is no longer a Live Programmer button in the Control Panel. Each editor, including the Programmer, has a Fade Changes button on the toolbar at the top.

    ADDITIVE VIEWS
    Hold Open and press the View soft key to open the view directory.
    Press the spreadsheet icon to look at the spreadsheet view.
    There is an additive column that can be set Yes / No.
    A view with Additive set to Yes will recall the windows stored in that view on top of any other windows that are already open. This allows you to save a couple of basic views with all of your standard windows and then use additive views to recall specific windows you need on top of those views.

    GUARD CUELISTS / ACTION AT END OF LIST
    The cuelist directory has a Guard button on the toolbar at the top. If you have guard turned off and you tap a cuelist, it will activate a Go for that cuelist. This allows you to run cuelists that are not attached to masters.
    In the cuelist options window, there is a drop-down list for Action at end of list. If you set this to "Add release end cue", pressing go when in the last cue will release the list. By using these 2 features together, you can cuelists with a single cue that can be turned on and off by tapping the list in the cuelist window. This can be a convenient way to change colors, change gobos, or strobe fixtures.

    SCENES WITH IPCB FADERS
    Record a scene to a master. Open the scene options and on the Master Controls tab, set the Fader to be an IPCB crossfader. Running the fader will manually crossfade parameters from their values on-stage to the values in the scene. This is very powerful and can allow you to manually fade all of your wash lights to blue or all of your spots into a ballyhoo, for example.

    TAP SYNC
    For chases that are assigned to masters, holding the Choose button for that master and tapping play will tap-sync the chase.

    INHIBITIVE SUBMASTERS
    Moving a Group onto a master will create an inhibitive submaster for that group of fixtures.
    CAPTURE PAGE ACTIVITY
    In the page directory, you can capture the state of the current page so that it will be restored every time that page is loaded. You can also click on the spreadsheet view and directly edit the comment macros used for this functionality. You can add macros to go or release lists, fade masters, enable timecode, and many other options.

    I hope this helps to get you started. Please let me know if you have more questions.

    Thanks.
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    Hiya Cormac,

    How's things in F.F. land? You still with them?

    You will definitely want to get a good feel of how Spreadsheets and Editors work.

    There's a whole lot more flexibility there for things like offsetting effects, cahnging tables, etc. to get precisely what you want, which is something I've seen you do a lot on the Hog-2.

    It's MUCH easier to work with all that now.

    As always feel free to give me a ring on my cell if you still have my number. Otherwise drop me an e-mail if you need it.

    The guys in support are very helpful as well if you hit a snag.

    Hope I run into you again soon!
  • cormacjackcormacjack Registered User, DL Beta
    edited March 2006
    Hi marty,
    Yep still on the FF roadshow which hasn't really stopped since i saw you!,
    thanks for the offer of advice which i may well take you up on.

    1.Please correct me if i'm wrong but when building colour pallettes that will work when i use the "change type" feature in the patch should i building them from the colour picker or creating them myself or neither?

    2.Is the process for pallette building the same as in Hog II where you only use a single fixture so that it carries on if you add more fixtures or is that now not the case.

    More questions to follow i'm sure,

    thanks C
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Cormac,

    1) Change Type looks at the common parameters that are shared between the old fixture type and the new fixture type. If the both the old and new fixtures have CMY parameters, those will be transferred. If the both fixtures have HS parameters, those will also be transferred. If both fixtures have a Colour 1 parameter (static colour wheel) with a slot named Red, then anytime the Red slot has been used in cues, scenes and palettes for the old fixture, it will be used for the new fixture.

    2) There are 3 palette types: Global, Per-Type, and Per-Fixture. The console is usually intelligent enough to determine which type to use. Global palettes apply the same values to all fixtures. Per-Type palettes apply the same values to all fixtures of a single type. Per-Fixture palettes apply unique values to each fixture.

    Global palettes and Per-Type palettes will behave as "greedy" and can be applied to fixtures that weren't originally recorded to the palette.

    When you record a palette, if all of your fixtures have the same values, the palette will be recorded as global. If each of your fixture types have the same values, but there are differences between the types, the palette will be recorded as per-type. Otherwise, the palette will be recorded as per-fixture.

    You can override the type of palette created by selecting Global, Per-Type, or Per-Fixture from the More... section of the Record Options Toolbar, but it will not let you perform an invalid operation, such as recording a global palette when you have differing values in your programmer.
  • sicklouiesicklouie Registered User
    edited March 2006
    cormacjack wrote:

    1.Please correct me if i'm wrong but when building colour pallettes that will work when i use the "change type" feature in the patch should i building them from the colour picker or creating them myself or neither?

    It's my understanding that to get the best results for "change type" when going from one CYM fixture to another - you should build your CYM pallettes utilizing Hue and Saturation. The color picker is a quick way to do just that or us the Hue and Saturation encoders. Apparently the desk processor handles the transposed information better. One warning though... in earlier versions software if you had a cue written with CYM lights using a pallette made with Hue & Saturation - if you touched the Cyan, Yellow or Magenta encoder(s) with those lights selected - the console will bump out all CYM live! For live editing of Hue & Saturation - always use the Hue & Saturation encoders.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Han,

    That is true if you are working with colour calibrated fixtures because you are more likely to get consistent colours after changing type.

    CMY values will transfer when changing type, but if you are changing between 2 colour calibrated fixtures and you have programmed your colours with hue and saturation, the hue and saturation values that are transferred should produce the same colours from the light. Different lights will often produce slightly different colours when using the same CMY values because of differences in lamps and colour mixing wheels, so it is correct to say that you will have the best results when changing types between colour calibrated fixtures if your colours are programmed with hue and saturation.
  • cormacjackcormacjack Registered User, DL Beta
    edited March 2006
    Thanks all,
    this is the sort of information i need to know.
    I have read some of the manual and information like this is not listed (i hope!!)

    1.As a rule when i record my first cue on a cue list ( Hog II) i usually use record state to record all values into the first cue.Is this process the same in Hog III.

    Best C
  • barnes2000barnes2000 Registered User, Hog Beta
    edited March 2006
    teerickson wrote:
    CAPTURE PAGE ACTIVITY
    In the page directory, you can capture the state of the current page so that it will be restored every time that page is loaded. You can also click on the spreadsheet view and directly edit the comment macros used for this functionality. You can add macros to go or release lists, fade masters, enable timecode, and many other options.
    :cool:Is this sort of like Snapshot on the Virtuoso?
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Cormac,

    There's no need to record state for your first cue.

    There are 2 times when I can see this making a difference:

    1) When no playback is controlling a parameter it is set to its default value. If you were to change your default values in the Edit Fixtures window, this could change how a cuelist looks on stage if you had not blocked the first cue.

    2) When you have interactions between multiple tracking LTP cuelists playing back, the entire cuelist is asserted each time Go or Assert is pressed. If you had recorded state into the first cue, every parameter of every light would be asserted instead of just the parameters that you had changed while programming the list.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Scott,

    Yes. This is "sort of" like snapshots on the Virtuoso.

    Here are the differences:

    1) Snapshots are accessible at any time. Capture Page Activity sets options only when you change to that page.

    2) Snapshots record and recall pretty much everything about the current state of your console. This can be somewhat narrowed with filtering. Capture Page Activity uses comment macros, so you can do as much or as little as you want. You can recall views, go or pause or release lists and scenes, set fader levels, enable or disable timecode, etc. The one thing that snapshots do that you cannot currently do with comment macros or Capture Page Activity is change the current fixture selection.

    There may be some other small differences, but that should give you a general idea. It's been a while since I've used a Virt.
  • sicklouiesicklouie Registered User
    edited March 2006
    cormacjack wrote:

    1.As a rule when i record my first cue on a cue list ( Hog II) i usually use record state to record all values into the first cue.Is this process the same in Hog III.

    There's another trick to giving a hard command at the beginning of a list. Try selecting the fixtures and use touch. This will load all perimeters into the programmer so when you record or update the cue those fixtures will be "blocked". This is most use full for cues that you know your going to duplicate or move about within the list. I'll make a group for every fixture & desk channel that I consistently want to block. Usually exclude key light specials, smoke machines, etc. so those are left out. This can bone you though if your going to edit at the beginning of the list and expect the edit to track forward.
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    1 - On palette types, in addition to the 3 palette types, you should also be aware that palettes DO NOT automatically "nest" or "reference" the way they did on Hog-2.

    You must select "Allow Refs" when recording "nested" palettes. You'll find it in the toolbar at the bottom of the right-hand screen after pressing "Record" and then "More" right along with your palette type selection options.

    i.e. - If you record indivual focus positions for Vox, Drums, Keys, Guitar, etc. And then you make a focus position for "Band-1" that has two lights at each position, if you do not select "Allow Refs" the hard values will go into the palette, and any changes to any one of the other focus positions will not carry over.

    2 - on HSI vs CMY values. Tom is quite right about using HSI values to get accurate colors when changing type WITH CALIBRATED FIXTURES is the key there. Not all the fixtures have been color calibrated to the HSI color model. To see if they have simply look all the way to the right in your PATCH window in the "Col Cal" column. And yes do be careful about bumping your CMY wheels if doing HSI changes on-the-fly.

    Additionally, do be VERY careful about using HSI in your cues. Slower, smoother changes may produce unwanted results. Especially if the colors are very far apart on the HSI "wheel".

    i.e. - you are changing colors from Deep Blue to Yellow using HSI with a fade time of say 4 seconds. You may see your color mixing mechanisms doing some strange and possibly unwanted things as the lights change color. This is because the Hue and Saturation values are moving around the wheel to get to the next color, and this is not necessariliy the natural path the mechanisms want to take to get there. If you ever run into Dan Hardiman over there ask him what happened to him the first time he tried using HSI values to program a UB-40 tour....

    So here's the workaround I use. Just create a set of HSI palettes of the colors you are going to use, but make sure it is with a color calibrated fixture. These will act as a sort of reference palette only. Then simply select your new set of lights, select the HSI color palette, touch your CMY wheels and record the new palette with CMY values (after making any possible necessary adjustments) and make sure your cues are built from the CMY palettes, not the HSI ones.

    WHEW!!! That was quite long enough...hope it helps.:headbang:
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    As Marty mentioned, the colours you see on stage when fading in HS can be different than the colours you see when fading CMY. This makes sense when you think about the fact that we crossfade the real world values in the cues.

    If you are fading from yellow (full yellow flag in) to congo (full cyan and magenta flags in) using CMY, you will fade through a point where all 3 flags are halfway in, producing a bland gray. This colour couldn't even be mixed using HS. If you do this same fade in HS, both colours are at full saturation, so the hue value will be faded which moves you around the colour wheel through some other fully saturated colours.

    It's a matter of personal preference and I've found that there some crossfades I feel CMY look better for and there are some where I prefer to use HS.

    As a few people have already mentioned, only the HS colour space will allow you to take full advantage of colour calibrated fixtures. Marty offered a good workaround if you prefer to use CMY crossfades, but it may limit some of the functionality with other operations. If you are working with CMY values and you clone parameters to a different fixture type, it will copy the CMY values and you may see a slightly different colour rather than taking advantage of the colour calibration as it would if you cloned HS values.
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    Hey Tom,

    Something Dan mentioned to me makes a lot of sense, and I don't know if he's logged it already as result of his involvement with BETA versions....

    Can there be a CMY fade path for color values in cues? Just like start, end, linear, etc. paths.:notworthy:
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    Oh yeah....

    Cormac,

    One habit that took me a while to break going from Hog-2 to Hog-3 was using that wonderful new "Merge" button right next to "Record" for updates.

    So now its:

    Cue-#-Merge-Enter.......DONE!! for a chosen master of course..otherwise add List-# to that syntax.

    Rather than the two ways of doing via touchscreen on the 2 (which was always fun since calibration was always a bit dodgy on the 2)
    i.e. Record-#/#-Enter...wait...hit selection on touch screen, and pray it's not the one next to the one you wanted.

    No more of that thanks!! Although that method/syntax will still work.
  • sicklouiesicklouie Registered User
    edited March 2006
    Marty,

    I guess that would be the "Replace" soft button. Accidentially touching that after moving one fixture in a focus pallette that is the basis for just sbout every look in a television show, five minutes before being on-camera and then having the back-up disk corrupt while trying to re-load. :aargh4:

    "Will someone please call 911. Our programmer appears to be having a heart attack!"

    And there's a lot of guys who still insist on using Hog II. :confused:
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    Yep, I'm sure anyone who worked on Hog-2 for any length of time did the fat-finger "Replace" instead of "Merge".

    I surely did, fortunately I knew right away I made an error, told my designer and we fixed it right away, but it always was a bit nerve racking under pressure "Oh God PLEASE let the screen not screw me up!!!". The safety was to select "Merge" from the bottom right tooldbar, but that also sometimes took a few presses to get it selected if the screen was off.

    I don't know why guys still want to use the II, but it has meant a low demand for Hog-3s here in NY. I got so sick of not being able to find one here that I just simply bought my own! Things are starting to change (albeit slowly) here though now that folks are getting more exposure via the iPC
  • sicklouiesicklouie Registered User
    edited March 2006
    Things are starting to change (albeit slowly) here though now that folks are getting more exposure via the iPC

    I agree. Once the software on the Hog III catches up and all the products are completely compatible and able to network... I think you'll see demand for the Hog III increase in the city.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Marty,

    I really like the idea of a crossfade path that controls the colour space that is used for the crossfade. It would be fabulous to have control over this on a cue-by-cue and fixture-by-fixture basis.

    I began to log an enhancement for this and then I had a realization.

    What happens if I'm fading between two HS colours and I want to use a non-default path (like shake or damped) and I want the fade to happen in the CMY colour space?

    I would have to set my CMY path to have the crossfade use CMY values and that would prevent me from setting the actual crossfade path I wanted to use in the cue.

    I'm going to continue thinking about this one. Please let me know if you have any grand ideas, because I like the direction this is headed.

    Thanks.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Marty,

    I also wanted to make sure that you were aware that:

    Merge 1 Enter

    will do the same thing as:

    Cue 1 Merge Enter

    Both merge into Cue 1 on the currently chosen master.
    If you want to merge into a cuelist on a different master, you can either use this:

    Merge 10/1 Enter

    Which will merge into Cue 1 on master 10.
    Or this:

    Merge List 4/1 Enter

    Which will merge into Cue 1 of Cuelist 4 (even if Cuelist 4 isn't attached to a master).
  • sicklouiesicklouie Registered User
    edited March 2006
    teerickson wrote:

    What happens if I'm fading between two HS colours and I want to use a non-default path (like shake or damped) and I want the fade to happen in the CMY colour space?

    I would have to set my CMY path to have the crossfade use CMY values and that would prevent me from setting the actual crossfade path I wanted to use in the cue.

    Could you not simulate this already be offsetting or delaying individual perimeter timing either CMY or HS? You would probably have to experiment quite a bit to get the desired results.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Han,

    Not really.

    Think about the shake path. It goes up and down and up and down and up and down and up until it reaches the destination. I might want to apply a shake path to a fade that happens in the CMY colour space or to a fade that happens in the HS colour space. If I'm setting a CMY path to define the colour space that a fade is happening in, then I can't apply a shake path to that fade.
  • quinnquinn Registered User
    edited March 2006
    well.

    what if the colorwheel concept was changed to a colorsphere, at least under the covers..., with white and black at the poles.

    a third encoder could toggle whether the HS change always evaluates to the surface (1,Φ,θ) as it does now, or if it takes a direct line through the grey space (ρ,Φ,θ) effectively simulating CMY's behavior.

    your H/S shakes will actually be HS calibrated shakes rather than shaking along the path between two dmx values.


    ...and it's a perfect model for RGBW, too...
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    As I mentioned initally I can't exactly take full credit here as Dan was the one who first came up with the idea of a fade path for CMY.:147: :friday:

    Yeah I know the all the "Merge" syntax, just trying to keep it straightforward at first...good lookin' though;)

    I like Quinn's idea in theory, but I'll have to wrap my brain more fully around it after I score some ZZZZZs:aiwebs_007: something just isn't sitting right with me...get back to ya in a bit.

    BTW - Cormac, you still receiving us out there brutha? :phone: Anything you need?
  • cormacjackcormacjack Registered User, DL Beta
    edited March 2006
    Ok everybody,
    now i'm this is my thread,you've really got to slow down.......

    Thanks for all the info

    Cormac
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    OK..got some sleep.:)

    I really thing Quinn is onto something here Tom. Map it to a dynamic sphere instead of a circle. (Any fellow Aikido-ists out there??;) ) I tried a few rudimentary models this morning to help me visualize...

    The only sticking point is the method of how to tell the model to move. Over the surface or directly point to point through the sphere. It could be a third encoder, but maybe it needs it's own column in cues, and button at the top of the programmer (a la "value, fade, table, etc...)

    Maybe you can get Tom Grimes involved in this on a software/technical level since I know he's the 3-D Guru down there who made a bunch of the stock .obj-s for DL-2.:notworthy: He's got the perfect mnd for this sort of thing.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    It sounds like we've managed to evolve this thread into 2 separate features.

    First, we need a way to specify for each colour mixing fixture in a cue whether that fixture will crossfade into that cue using a CMY / RGB colour space or a HS colour space.

    My only concern with this is that I believe it would only apply if crossfading from a HS value to a HS value because there are CMY combinations that cannot be represented on our current colour wheel.

    Second, we should consider an enhancement or replacement to the colour wheel (like a colour sphere) that would allow us to add the concept of "intensity" to the colour model.

    I don't see the calculation of the crossfade path as the problem here. We are either fading along a raw value path like CMY or RGB, or we're fading along an abstracted value path like HSI.

    I do see 2 problems. First, this would mean a complete change to our colour model. I would have to verify with the development team, but I assume that a change like this would mean having to redo colour calibration on all fixtures and would most likely break the backward compatibility of show files.

    Second, if we were to implement a sphere, we're talking about presenting a 3D space. We need to have an easy way to access any point in the colour space from the (2D) touch screen. One of the conveniences of the colour picker is that I can open the window and just tap on a green that I like to apply that colour.
  • Woodj32177Woodj32177 Registered User
    edited March 2006
    Or just a seperate "slider" next to the color wheel that determines the intensity of the color.
    Josh
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    Well, I think we're starting to get ahead of ourselves alittle bit here....:rolleyes:

    Tom, we don't have to have a "real" 3-D model, just a simulated one.....3-D space in a 2-D environment. We're in essence already doing that whith DL-2.:headbang:

    The color model would behave the same on the surface. Take the existing Wheel and wrap in onto a sphere. H & S changes happen on the surface...no real big change there. Hue would move like Lattitude on a globe and Saturation moves like Longitude. (If you look at the current "wheel" you would be viewing the sphere from the "white" pole, and the edges of the wheel are very close to the "black" pole past the equatorial line)

    {EDIT*** Maybe the sphere will "rotate" to keep the current position of H&S at the center....so rather than have the "circle-x" icon move over the globe, you have the globe move behind the icon....or maybe this too should be an option under user prefs "Define HSI visualization" or something like that}

    But when you defiine a "point to point" movement, (which would engage a CMY mechanical path) It would be like sticking a toothpick through an orange (minus the messy juice;) )...going from one to another. Where one end of the toothpick is your starting color and the other end is your finishing color. (Any Frank Herbert fans out there....folding space like in DUNE)

    The trick is how do you define that movement. I agree it could be a third encoder wheel, but it shouldn't be called "Intensity". Maybe it should be called "Color Change" or "Navigation".

    A wheel is a bit overkill for a fucntion that only has two possible modes. Better for it to be a slot, maybe it could be included under the current "Mode" slots or "Engage"
    {EDIT***Whooops I mean "Enable"} slots.

    My understanding of the current HSI model it that fixture Intensity is already the "Intensity" of HSI...no reason to change that.

    If I am wrong and have missed something critical here, and the model does need to change. Thereby negating all the currently color calibrated fixtures....What better time than now to do so, as there are so few calibrated fixtures in the library to begin with:confused:
  • quinnquinn Registered User
    edited March 2006
    many thanks to marty for gettin all of that out of our heads and onto the page.

    true, all of this may be overkill, but my honest hope is that a really big idea will allow us to settle somewhere in the middle.

    a couple things i'll reinforce...
    teericson wrote:
    I would have to verify with the development team, but I assume that a change like this would mean having to redo colour calibration on all fixtures and would most likely break the backward compatibility
    naw dude, if the "outermost" surface of the o/w hemisphere equals the current color wheel exactly, everything else should be just a quick interpolation ala XYZ (RIP).

    as for compatibility, um, really? if it's better then break it. i'm sure people who have enough consoles for this to even be an issue can handle avoiding mismatched versions of the editor... bump the rev major. done.
    teericson wrote:
    we're talking about presenting a 3D space
    well, wasn't what i was thinking, but i'm not gonna shoot it down either...

    i like the color wheel. (i like green, too :rolleyes:). really the only thing that bugs me about it is that i can't make it my favorite size or maximize it quickly now that it's trapped in an mdi. but that's so not the point.
    teericson wrote:
    I believe it would only apply if crossfading from a HS value to a HS value
    yup. that's how the whole thing started. but it does beg the question, why doesn't CMY know what HS is doing?...
    teericson wrote:
    this would mean a complete change to our colour model.
    yeah. i can think of a whole bunch of things an additional dimension would enable. its purpose would of course vary based on fixture "class". a small handful of examples:

    subtractive
    • temperature correction wheels
    • "Luminosity" by C+M+Y all in
    additive
    • RBGW. it's gotta go somewhere, and i consider it more a property of color than intensity, as (R+B+G)/3≠W...
    • RBGA. re-align the axis and it's done.
    and where i'm *really* going with this, is it could even be re-used on other functions.
    • position. xyz. there. i said it.
    • gobo. our "toothpick" path could be used to crossfade from >> to Index without <<'ing or that twitch when hitting the first index value.
    i'm happy to just get over myself at any time, but we're definately due for a cleanup on aisle 1757.
  • cormacjackcormacjack Registered User, DL Beta
    edited March 2006
    Dave Klotz wrote:
    CORMACJACK

    Go start another novice link and yOU

    thanks for your polite reply,it's fantastic to see members being so friendly to those who who have not made the "grade".

    Thanks marty and tom.

    Appreciated Cormac
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    No worries Cormac....always here to help...none of us pretends to know it all. That's what makes this forum such a great resource!

    Let's all just play nice in the sandbox now shall we kids!!:soapbox:

    Quinn is quite right, and has beaten me to the punch again:beerchug: :friday:

    ....the "toothpick" movement could be very useful indeed for other areas.

    as mentioned - XYZ positioning (make Pan & Tilt take shortest path...vs travel in XYZ coordinates.) amongst other things.

    Hadn't really thought of Gobo modes though....good one! That's always bugged me too.

    I didn't really want to go there yet till we dealt w/ HSI vs CMY....but the door has been opened.....
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Marty & Quinn,

    Since you have both touched on some similar issues that affect this discussion, I'm going to reply to both of your posts at once. Hopefully I'll catch everything you guys mentioned.


    3D Space

    Quinn - I'm curious about how you were thinking of handling this, if not in 3D. We're adding another dimension to our colour space, so I think it would either have to be a 3 dimensional model or our current colour wheel with a separate fader for the third dimension as Josh mentioned.

    I still need to think on this one a bit, but my current thinking is that our current wheel would map on to one hemisphere of a sphere and a similar wheel with black at the pole instead of white would map to the other hemisphere.

    Marty - You say that we just need a simulated 3D model. My concern with this is that we still need to maintain a very easy way to pick a colour. We obviously can't implement a solution that makes it more difficult to pick a colour than it would be to dial one up with the encoders.


    Crossfade Paths by Colour Space

    I'm not horribly worried about this because it seems to just boil down to "are we fading our abstracted HSI values for a crossfade around the sphere or are we fading the raw CMY / RGB parameter values for a linear fade".

    We would want to implement a way to specify on a per-fixture per-cue basis which colour space would be used for a crossfade.

    Quinn - You asked why CMY doesn't know what HS is doing. The answer is that it usually does, but the problem is that there isn't a 1:1 relationship between positions in the two colour spaces. This is even more true now that we have fixtures like RGBA LEDs. I can mix a beautiful amber with red and green or I can just use the amber LED. If you give me RGBA values I can always tell you what the corresponding HS values are, but if you give me HS values I may be able to mix that colour a few different ways using RGBA.


    Colour Calibration and Compatibility

    I don't have an official answer on this one, but I'm sticking with my original assumption.

    Quinn - You say that the current colour wheel maps to the outside of the sphere and everything else is "quick interpretation ala XYZ". That can't really be the case if we're talking about additional colour parameters. If we're building this to help us handle White and Amber LEDs or CTO and CTB wheels then we will be redesigning the way that colours and their associated fades are determined. This also means that since these new features require an additional dimension in the colour space that our colour calibration model needs an additional dimension in the colour space which may require re-calibrating fixtures.

    I still think that a change like this (a complete rework of our colour model) sounds like something that would certainly break backwards compatibility. While that may not sound like a big issue to you, we have many shows on tour or in permanent installations that this can be a big issue for. There is a ton of planning and thought that goes into something like this and we certainly can't take it lightly.

    If we do need to re-calibrate fixtures, this also is a large undertaking. Acquiring, cleaning, re-lamping, and measuring a fixture is already a sizable project, but a change to the colour model means changes to the calibration routines which is another significant consideration.


    Everything Else

    Marty - You asked about our current HSI model taking intensity into account. Currently we have a HS model. Intensity is in no way taken into consideration when working with the colour wheel or HS colour mixing. We would need to add the support to handle a concept of intensity in the colour model.

    Quinn - What problems are you having resizing or maximizing the colour wheel? It's always been a MDI window as far as I know.


    Hopefully this answers most of the issues you presented. Let me know if that's not the case. I think this is a good discussion and that it's really worth working out the details.

    Thanks.
  • Akito.HAkito.H Registered User, Hog Beta
    edited March 2006
    If 3d space is mounted, might how about the movement of the surface with a track ball.
    I think that the track ball is a sphere, too.
    And, I want to use I-wheel when moving in it.

    Though it is thought that 3D can be freely moved by this.

    Thanks,

    Akito
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    I hate to do this to you Tom,....but:rolleyes:

    Page 15 of the printed Hog-3 manual v1.3.8-EN detailing how the HSI color model works:

    - it states that the Intensity in HSI "...is identical to the dimmer control on most fixtures."
    :notworthy:

    Having said that..

    I think we're talking about two totally different changes. While a true 3-D space might be useful...:33:

    I think all we really need to do is make the "wheel" a "sphere" or maybe even just a "half sphere" with only a "white pole". As I mentioned before Hue moves like lines of lattitude, and saturation moves like lines of longitude. If a "half sphere" this changes nothing as far as color calibration only user interaction.:)

    As far as being able to "see" the other colors, maybe there needs to be a split screen view of the new sphere as an option. I.E. view as normal, or do say a double view in the same window, one from the black pole, and the other like we are already used to seeing it...from the white pole. This would not be necessary with a "half-sphere" though as our current view of the wheel would be unchanged.

    All we need to add then is a "mode" that allows for one of two options:
    1 - "Normal" - Hue and Saturation move along the surface as already discissed
    2 - "Toothpick" - This crossfades HSI color changes via a mechanical CMY path and goes directly from one HSI color point to another.
    These should be "slot-bar" options somewhere...I suggested "Mode" or "Enable" earlier.


    Regardless of any of this, I do like Akito's notion of mapping Hue and Saturation to the Trackball as we already have Intensity on the I-Wheel. Should be as simple as a trackball button option. As for knowing that the Trackball is now in "Color Mode" maybe the blue LED could fade in and out as an indication. A color sensitivity setting under control panel would be nice similar to the ones for P/T and pointer modes. This could be very useful even under the current model.
    Nice one Akito! :beerchug:
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Marty,

    I understand that Intensity is part of the HSI colour model. My point is that there is never a time currently when tapping on the colour wheel will change the Intensity value of your fixtures in the Programmer. Our colour model is completely unaware of Intensity and the colour space that we use isn't designed to handle this. This means that we need to design a way to handle variable colour parameters other than the primary additive and subtractive mixing colours (RGB / CMY), like Intensity, White, Amber, CTO, and CTB. Our colour model, the visual representation of it, how we crossfade through it, and how we colour calibrate for it would all need to change.

    The "mode" you refer to is actually a way to tell the console which colour space is being used for calculating the crossfade. The two options with our current model would be a fade that uses raw dmx values (cmy) or a fade that uses abstracted real-world values (hs).

    I think that the trackball / i-wheel for moving through the colour space is a good one. If a sphere ends up being the best solution this seems to be a nice way to navigate through it.

    Thanks.
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    Tom,

    Agreed, if we go to a truly 3-D spherical environment, we would need a third wheel to navigate that space as to our "depth" if you will.

    I really don't think we need to go there though. The more I think about a half-sphere model....the better it feels. Simply map our current wheel onto a half-sphere....no need to define "depth" because we are only travelling on the surface, until we take a "toothpick" path/mode.
    teerickson wrote:
    The "mode" you refer to is actually a way to tell the console which colour space the fade is being used for calculating the crossfade. The two options with our current model would be a fade that uses raw dmx values (cmy) or a fade that uses abstracted real-world values (hs).

    :arms: Yup!!! That's what I was originally talking about days ago. This is much needed to make HSI as it stands now really powerful!

    On the issue of CTO & CTB, I rather like the way that they are handled now as Color Temperature adjustments....rather than actual color adjustments.

    Yes color temperature affects the final color, but I don't think that they should be included in any model based on HSI because they effectively are changing the base white point.

    As for iWhite and iAmber on LEDS....that's a bit tricker.:33:
    - I kinda feel like iWhite should be CTB...since that's really more what it is. (White LEDS are really just blue ones that are being pushed)
    - iAmber is the slippery one (I use the Pixel-line products quite often). I'm sure there's gotta be a way to mesh this into HSI somewhere between green and red. Defining those "seams" and transitions is really the hardest part. It is surely too saturated to be treated like CTO.

    {EDIT*** Defining the transitional seams between Green-Amber-Red shouldn't be any harder than defining the ones already between CMY & RGB no?!?!}
    teerickson wrote:
    I think that the trackball / i-wheel for moving through the colour space is a good one. If a sphere ends up being the best solution this seems to be a nice way to navigate through it.

    Even if we don't have a sphere, I think this could be useful to us right now!:)

    Thanks for sticking with us on this Tom, we've got a lot of ideas bouncing around on this thread!:beerchug:
  • srautanesrautane Registered User, Hog Beta
    edited March 2006
    Akito.H wrote:
    If 3d space is mounted, might how about the movement of the surface with a track ball.
    I think that the track ball is a sphere, too.
    And, I want to use I-wheel when moving in it.

    Though it is thought that 3D can be freely moved by this.

    Thanks,

    Akito
    I also like the idea adding trackball control to Hue and Saturation like Marty said.
    I guess, it would be nice to control hue and saturation simultaneously using your thump/trackball and other fingers on I-wheel...

    Too bad there's only blue LED in trackball...it could change colour :)
  • Akito.HAkito.H Registered User, Hog Beta
    edited March 2006
    Thanks for every reply.

    I feel the thing that a advanced discussion is done here now.

    The thing whose LED of the track ball is only blue is regrettable.
    I want also to switch the color.

    However, I do not like to change hardware.

    Then, how about blinking for this 3d Color sphere mode?(As well as the Blind mode)

    I think that it can achieve this function without improving hardware if it is this method.

    Akito
  • aphylotusaphylotus Registered User
    edited March 2006
    Hi,

    the idea about the trackball for the Hue/Saturation is a great idea. Also like it, with/or without the 3D Discussion (very interesting, and great ideas), but I also see the problems behind it.
    But if possible go for the Trackball, the blink idea (or fade) is also good and doable :)

    Tom
  • quinnquinn Registered User
    edited March 2006
    3D Space

    it's gotta go on the encoder wheels. as the extra dimension's purpose could vary (W,A,CTO,XYZ...), the color wheel shouldn't try to expose anything more than common functionality.

    at least for now.


    Colour Calibration and Compatibility

    i'm gonna leave alllll of that for your homies to decide, we're just going back and forth and the answer's utimately gonna come from them anyway...


    Everything Else

    true, they've always been parented, but definately not trapped...

    somewhere between 803 and 1112, we went a little overboard with Qt.

    now everything but the toolbars are trapped inside the "Primary Screen"s.
    and nothing's got a titlebar, just a QWidget docked at the top to fake it...

    so there's no maximize/restore without reaching all the way over to the other screen, no minimize (which was totally useful for restoring rather than re-opening in a different position), no dragging to move, and user-resize is disabled. probably all to get move/size/focus etc working (cuz the "primaries" still behave, *and* have 31 vertical pixels of non-client area???)

    i'm gonna have to find some time to re-load and take screenshots of how great it was before going back to the stupid, stupid WHII-style "layout". (especially on a lonely laptop...)
  • Marty PostmaMarty Postma Registered User
    edited March 2006
    Hey Quinn, you lost me a bit on that last part "Everything Else" :confused:

    We talking about Hog-3PC for iPC now?
  • bradpepebradpepe Registered User, HES Alumni
    edited March 2006
    Quinn,

    You said "there's no maximize/restore without reaching all the way over to the other screen, no minimize (which was totally useful for restoring rather than re-opening in a different position), no dragging to move, and user-resize is disabled. probably all to get move/size/focus etc working "

    You can drag, resize, etc all you want the various windows within the Wholehog 3 system, you just need to unlock them first. In addition you can use the various shortcuts with the Open key to move, minimize, etc without having to "reach accross the screen". Please refer to page 87 (section 13.2.3) of the Wholehog 3 User Manual for further details on these functions.

    thanks,
  • quinnquinn Registered User
    edited March 2006
    awwwwwwwwwwww!

    well of course now that Move's working, Lock should too...

    jeez, go me. :o
  • teericksonteerickson Registered User, HES Alumni
    edited April 2006
    Marty,

    I like your point about CTO and CTB.

    They really are modifiers that would affect the colour temperature of the entire model and could be handled separately. It would still be very nice if the change was reflected in the colour picker, but this becomes difficult if we have multiple fixtures selected that have different CTO / CTB capabilities or values.

    I think we still have some thinking to do about the easiest way to display and control colour, but we certainly have a good start here and we can continue this discussion as we have new ideas.
  • Greg151Greg151 Registered User
    edited March 2010
    Hi

    Just wondering if any of the good ideas about the color picker and color system have ever been taken any further?? Based on the performance of the console I guess not. But I certainly think it is worth another look.

    Greg
  • srautanesrautane Registered User, Hog Beta
    edited March 2010
    Btw, it was nice to read this again...sometimes I feel we tend to forget things too soon.
    One nice 3d color picker is the Lee filters watchball.
    Also, something useful to read http://en.wikipedia.org/wiki/HSL_and_HSV
Sign In or Register to comment.