Hog III Novice

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:

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

[QUOTE=Marty Postma]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.

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.

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).

[QUOTE=teerickson]

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.

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.

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...

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?

Ok everybody,
now i'm this is my thread,you've really got to slow down.......

Thanks for all the info

Cormac

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.

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.

Or just a seperate "slider" next to the color wheel that determines the intensity of the color.
Josh

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:

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...

[quote=teericson]
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.

[quote=teericson]we're talking about presenting a 3D spacewell, 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.

[quote=teericson]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?...

[quote=teericson]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 inadditive

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.