I am an EOS Family programmer, currently working on tightening up my process. I thought I would reach out and see if you guys had any ideas or suggestions.
Clay
Clay
Control/Dimming Eos family: Workflow tips.
- Thread starterTheTheaterGeek
- Start date
I worked at a LORT B theatre as the AME for the 2014-2015 season. My duties included anything that related to the console (ETC Eos Classic), and many things that didn’t. It’s probably more information than you’re looking for, but I figure I might as well write it all up:
The ME would dimmer the plot and then input the dimmer into Lightwright. I’d deal with any additional DMX and power runs as well as fitting the DMX devices for that show into the console outputs. Those would then go into Lightwright as point units so that I can patch them easily later. At this point, I would save a private copy of the Lightwright and work off of this for my console import.
I use query a lot. It’s a huge timesaver for a large number of things, and it’s best used in conjunction with a Lightwright import. First things first in this private Lightwright file is cleaning things up, and shortening names for the console. It’s unnecessary to query “ETC Source 4 36 Degree SeaChanger”, when “S4 36*” or “SC” works just as well. (As a side note, I assume that every show I program will be worked on by someone else. Consistency, labels, and simplicity are incredibly important!) Positions get changed from “LS #6 3RD ELECTRIC” to “LS06”. Currently in Eos 2.2 you can only import 4 queryable textfields, I typically picked: Position, Instrument Type, Purpose, Color.
The private Lightwright is exported (there’s some magic that goes into making this work, that I won’t go into because Eos v2.3 changes all of that) and things are imported. At this point, everything has the proper start DMX addresses, but the profiles are wrong. Remember those point units from two paragraphs ago? Those come into play here - I query those and change the unit type. Typically it was SeaChangers, ML #1, ML #2, LED tape, strobes. Import any stock things I want for this show (macros, effects, snapshots, macros, magic sheets, have I mentioned macros?). Run a test (any MLs get hung backwards?) then go out for a beer.
Next, are palettes. Have I worked with this designer before? Great! Import color palettes from the last show file and move them to the 1000 range. They can get moved easily later. Oh, I’ve never worked with this designer before? Email time - Macros, snapshots, any other console things they’d like imported or created. Saves tech time, and everyone likes that.
For MLs I will create focus palettes for the designer’s focus points (either from the Lightwright, or the Vectorworks file) and make them absolute palettes so I don’t start nesting things. (Remember where I said I made things consistent and simple? No tricks!) These palettes go on a MS so they’re easy to find and use.
Above is the prep I did. Tech is a whole different beast.
If you have any questions about this specific process, let me know.
The ME would dimmer the plot and then input the dimmer into Lightwright. I’d deal with any additional DMX and power runs as well as fitting the DMX devices for that show into the console outputs. Those would then go into Lightwright as point units so that I can patch them easily later. At this point, I would save a private copy of the Lightwright and work off of this for my console import.
I use query a lot. It’s a huge timesaver for a large number of things, and it’s best used in conjunction with a Lightwright import. First things first in this private Lightwright file is cleaning things up, and shortening names for the console. It’s unnecessary to query “ETC Source 4 36 Degree SeaChanger”, when “S4 36*” or “SC” works just as well. (As a side note, I assume that every show I program will be worked on by someone else. Consistency, labels, and simplicity are incredibly important!) Positions get changed from “LS #6 3RD ELECTRIC” to “LS06”. Currently in Eos 2.2 you can only import 4 queryable textfields, I typically picked: Position, Instrument Type, Purpose, Color.
The private Lightwright is exported (there’s some magic that goes into making this work, that I won’t go into because Eos v2.3 changes all of that) and things are imported. At this point, everything has the proper start DMX addresses, but the profiles are wrong. Remember those point units from two paragraphs ago? Those come into play here - I query those and change the unit type. Typically it was SeaChangers, ML #1, ML #2, LED tape, strobes. Import any stock things I want for this show (macros, effects, snapshots, macros, magic sheets, have I mentioned macros?). Run a test (any MLs get hung backwards?) then go out for a beer.
Next, are palettes. Have I worked with this designer before? Great! Import color palettes from the last show file and move them to the 1000 range. They can get moved easily later. Oh, I’ve never worked with this designer before? Email time - Macros, snapshots, any other console things they’d like imported or created. Saves tech time, and everyone likes that.
For MLs I will create focus palettes for the designer’s focus points (either from the Lightwright, or the Vectorworks file) and make them absolute palettes so I don’t start nesting things. (Remember where I said I made things consistent and simple? No tricks!) These palettes go on a MS so they’re easy to find and use.
Above is the prep I did. Tech is a whole different beast.
If you have any questions about this specific process, let me know.
I've made various lengthy posts on here regarding my programming methods, use of macros, etc. that you can probably search for fairly easily. The macro post in particular talks a lot about my methodology for setting up my desks. Beyond that, this question is a little vague - is there something specific you're looking for?
Of the many programmers I know and work alongside, no one does things exactly the same way. As much as I'd like to pretend that my methods are the fastest and most efficient, it really comes down to what's best for you. It's also important to remember that your workflow depends a lot on what kinds of shows you do and what kinds of designers you work for. As an example, a friend of mine has virtually no stock color palettes in his stock show file, because the designers he works with are very particular with color choosing - they want you to dial in a color live so they can stop you when it's perfect. Most designers I know, however, are perfectly fine with asking for a "light bluey-purpley thing" and then adjusting from there, which is why most programmers will bring hundreds of well-organized by-type palettes with them when they set up the desk.
Of the many programmers I know and work alongside, no one does things exactly the same way. As much as I'd like to pretend that my methods are the fastest and most efficient, it really comes down to what's best for you. It's also important to remember that your workflow depends a lot on what kinds of shows you do and what kinds of designers you work for. As an example, a friend of mine has virtually no stock color palettes in his stock show file, because the designers he works with are very particular with color choosing - they want you to dial in a color live so they can stop you when it's perfect. Most designers I know, however, are perfectly fine with asking for a "light bluey-purpley thing" and then adjusting from there, which is why most programmers will bring hundreds of well-organized by-type palettes with them when they set up the desk.
I have found the same, this question was intended to shed light on what fellow programmers sought to keep consistent between gigs. It's more of just a topic to open up avenues of thought. If that makes any sense.
John Palmer
Well-Known Member
While not EOS specific, here are some thoughts.
Consistency!
My first ten color palettes and my first ten position palettes are always the same. If in a heartbeat I need to get to red, I know that it is CP#5 because it is always CP#5.
If I am programming for an LD and they want a different Palette order, then I move my palettes to another range but keep the numbering consistent.
Groups are numbered by the lowest channel number in the system. Grp 21 is cool front light containing Ch. 21-30. I will make copies so that I can make a group select screen hold the primary groups. I find it easier to remember Ch#s and Grp#s if I am consistent with my numbering and conventions. Warm before Cool. Frontlight before backlight.
If the LD is dictating palette #s and names, try to keep them consistent! It is much faster to get it labeled correctly than fix it later.
Take care,
John
Consistency!
My first ten color palettes and my first ten position palettes are always the same. If in a heartbeat I need to get to red, I know that it is CP#5 because it is always CP#5.
If I am programming for an LD and they want a different Palette order, then I move my palettes to another range but keep the numbering consistent.
Groups are numbered by the lowest channel number in the system. Grp 21 is cool front light containing Ch. 21-30. I will make copies so that I can make a group select screen hold the primary groups. I find it easier to remember Ch#s and Grp#s if I am consistent with my numbering and conventions. Warm before Cool. Frontlight before backlight.
If the LD is dictating palette #s and names, try to keep them consistent! It is much faster to get it labeled correctly than fix it later.
Take care,
John
I think John's points are among the most important to remember. It's crucial to standardize as much of your workflow as possible so that you don't waste time hunting through the desk for information. My best example is that I always set up 9 manual focus palettes for every show I do, numbered 1 through 9 in graphical relation to the stage - 1 is DSR, 5 is MSC, 8 is USC, and so on. These never get recorded into cues, and most LDs probably don't have any idea I'm doing it, but this allows me to quickly get a fixture near where I need it instead of wasting time dialing it in from wherever it may have been pointing before. Similarly I have most of my macro and beam/color palette direct select locations memorized so that my finger automatically knows where to go to process a specific command without me needing to think about it (incidentally, this drove me crazy when Flexi direct selects first came out and I tried to use them - it wasn't a good day). I rarely have LDs who care about specific palette numbers or locations, which is good because I fiercely guard my stock numbers. If you really want your CP #1 to be a dark red, I'm happy to oblige, but there's gonna be a lot of cursing on comm every time I try to put a fixture in open white and it turns red instead. Good programmers are valued in part because they can instinctual perform many actions without needing to stop to think about process, and messing with that process without a good reason is just going to slow you down.
I 99% if the time use my personal naming, numbering, and ordering scheme consistent across all my show files.
An Eos specific point, What about moving between Ion, Gio, Eos Classic and Ti. How can you prepare screen layouts and real estate for the different configurations you run into? How do you work between having 2, 4, and 5 displays, also, how do you integrate touchscreen use without tainting your keypad speed?
An Eos specific point, What about moving between Ion, Gio, Eos Classic and Ti. How can you prepare screen layouts and real estate for the different configurations you run into? How do you work between having 2, 4, and 5 displays, also, how do you integrate touchscreen use without tainting your keypad speed?
Which is great if you're programming a show and the show "dies" at your house but if the show is transferring somewhere (or could) and is going without you, you need to prep for that by using the designer's labels/numbering/ordering schemes. Makes it easier on them and they very much appreciate that.
If you have touchscreens, who cares where your palettes are number wise? Stick em up in the 9000s and access them via a magic sheet array. They'll always be in the same place and the designer can number how they want.
I've made "black boxes" in photoshop that are the same size as the screens I work with. E.g 1920x1080 pixels for the internal Ti screens. I don't get supper accurate with them, but it lets me rough things in.
The second part is really something I feel out depending on the designer. If we're moving between color palettes to see what they like best it's a lot faster to bounce through them on a touch screen then typing the palettes out. There isn't a "rule" as far as any of this goes. It's all depends on you and what gets the job done well and efficiently.
Similar threads
Control/Dimming
Eos software questions
