:147:
I read a thread recently where the person posting was a Light Jockey programmer learning to use Hog 3. I was inspired by the post to list this new thread. I took a few excepts from some of my training books and came up with the following:
:confused: :confused: :confused: :confused: :confused:
For those of you hired to program and design nightclubs, you'll find value in this. I deal with many club owners who have small dance floors and small budgets. Typically, a nightclub owner might elect to use a program like Martin's Light Jockey to run the light show. Just so everyone here knows, the cost per universe is about the same.
Number of universes, 1
Approximate Retail: $1,500 Hog PC:headbang:
Approximate Retail: $1,500 Light Jockey:mad:
Number of universes, 4
Approximate Retail: $2,700 Hog PC:headbang:
Approximate Retail: $2,800 Light Jockey:mad:
As you can see, the price is about the same.
PLEASE! Put HogPC any place that has or is considering Light Jockey. As far as programming, here's why. I am going to outline a standard programming strategy for Light Jockey and then for HogPC. You’ll see that a lot of thought has gone into the convention being used in order to expedite programming. Many of you will probably agree that the format and conventions are what we all use and the foundation for why the Wholehog platform was initially developed.
For the sake of this discussion, I will pretend I have two types of Moving Yoke Spots and some Moving Yoke Washes. I will call them Spots, Profiles, and Washes.
Using LJ terms::Eyecrazy:
First, I define a convention. :17:
If you use LJ you know that when you build sequences, you can save them so that they load in a specific "cue slot" and that each cue can have up to 12 slots. The convention I would use for loading the Cue Slots would be as follows:
:blackeye: 1 Spot Intensity
:blackeye: 2 Spot Position
:blackeye: 3 Spot Color
:blackeye: 4 Spot Beam
:blackeye: 5 Profiles Intensity
:blackeye: 6 Profiles Position
:blackeye: 7 Profiles Color
:blackeye: 8 Profiles Beam
:blackeye: 9 Wash Intensity
:blackeye: 10 Wash Position
:blackeye: 11 Wash Color
:blackeye: 12 Wash Beam
:sad:
:aiwebs_010: With the convention now planned, I start building sequences.
I will build all my LJ intensity sequences first. A hint is to use intensity to control strobing and dimmer chases too.
Then I do all my position sequences. A hint is to position all lights and save static positions first. Then, reopen Static Positions and add them to sequence steps and finally add macros for movement and resave as new sequences.
Then Color from Mixing, Slots, and Sequences with chasing steps.
Finally Beam sequences including Gobo, Iris, Frost, Zoom, Focus, Prism, etc.
If there are too many fixture types to allow for four cue slots per type, try combining intensity with position. I recommend saving each position twice, once at full and once at zero so that you can load a cue in black to start from in a cuelist.
Once all the sequences are all built, I record all the individual sequences as individual cues by themselves.
Then record individual cues with all four parameters (intensity, position, color, and beam) for each fixture type.
Finally, build looks using all fixtures and attributes and record these as cues.
This way, I can use the cues that change everything to start the look and then use the individual fixture or individual parameter cues as masks to enhance the look.
For cuelists, when I create them, I make the first a global cue, and then add individual parameter cues (such as position) as steps in the list. Alternately, I create cuelists specific to each attribute. For example, I will create a cuelist of positions so that each GO command step to the next position in the cuelist. The same for color and same for beam.
The idea by this system is to create a layering capability for operation.:1zhelp:
:hogsign: Now let’s turn to the Hog3 Architecture.:hogsign:
I will now utilize Hog3 Terminology to explain a scenario for performing the same thing. I will utilize the convention already inherent in Hog programming which surprisingly is the exact same convention I had to develop for use with Light Jockey.
I move the lights (all or a specific group, it doesn’t matter) to a specific location and record those specific locations as a position Palette. Then using those location Palettes, I will construct position looks and create Position palettes that embed the source palettes. After all the positions are recorded, I will open the effects generator and create custom position effects which map very nicely to the position palettes I have created. I make sure to record these complex effects into the effects onto the effects palette window so that I can access them again.
Now I move on and record all the colors I will use as color palettes and then again create embedded palettes using combinations of the single color palettes as reference.
Finally, I do the same with Beam functions but I do it a bit differently than I do with color. Since I can actually split the Beam palettes so that only individual Beam attributes are recorded into each palette, I create palettes for focus and zoom first, then things like iris, prism, animation wheel, frost, and then gobo.
With all these palettes recorded now, I create Scenes which are comprised of all parameters (intensity, position, color, beam, and effects) for all fixtures. These are my global cues. Then I create more scenes the same way but for specific fixture types. Now, I make scenes for parameter types, color or position for example. These I might make for one or all fixture types, or both.
As you can see, I create scene palettes that are exactly like cue locations on the Light Jockey. I program in a few views which scroll the scene palette down and I have instant access to everything.
To make it a bit more complex, I will also create cuelists using the scenes I have made. First I trigger all the parameter specific scenes, select the fixtures I want in the scene, and hit “Touch” to grab the parameter. Then I record these as cues on a cuelist. Alternately, I can just rapidly use the palettes once again to recreate the looks I saved as scenes and, this time, save them as cues on lists.
With a mouse, and monitor, I now have access to the scene and list windows and can run a whole show faster and better than with Light Jockey.
All in all, when I walk into a club with two dozen movers, I can spit out about 100 complex cues and about 200 simple cues in two days of programming (about 16 hours) using Light Jockey. In three days, I could probably create close to 500 cues.
:friday:
Now for the surprise! :dunce:
Using a Hog PC with the programming wing alone, I can knock the same 500 cue show out in one day. If I use a Road Hog, I can do it in 4 hours. The great thing is, when I walk out the door, everything done on the Hog is better, with more dynamics, tremendous operator variability. If anything ever moves in the club, I simply update my Position Location palettes (takes about an hour or two) and the whole show is updated.
Let’s do some cost comparisons. :nono:
Pretend the average Light Jockey programmer makes $400 a day for work like this. The club owner then has to pay $800 for the programmer to be there (or $1200 if it’s three days). Now if the programmer learns Hog instead of Light Jockey, buys himself a Roadhog (or iPC), he can the show up and do the same thing in one day but rent his Roadhog or iPC out for the day he’s there and still come in under $1200 for the job but do less work, and own his own controller.
:hogsign:
