It's elementary, my dear ETC

 
Element board and a monitor

  More things right and (mostly) wrong with Eos

I could say that this is sort of a follow-on to a couple of other pieces on this family of controllers -- an early rant about the Ion from almost ten years ago, and some other tricks-n-tips noted during Arisia '18.  Much of what's said there still applies, and taken all together with this could almost start forming an "Undocumented Eos" book.  Over the years ETC has learned a few things from its market and made its share of improvements, but there are still some aspects of these controllers that can really bite the unwary.

On inquiring with 4Wall as to what our controller options appropriate to Arisia's main-tent rig were, Paul decided that the Element 60 seemed the best match for a medium-scale theatrical board.  It has a lot of built-in faders which easily map to individual channels, a working model that old-school operators are well used to.  But every slider can also be a submaster, and with 60 of them on the faceplate a fairly large show can be set up and run without having to change submaster pages.

That's fine, until you get into cue structure, fixture personalities, execution order and precedence, and basically anything that isn't a conventional dimmer.  This is where Eos, the underlying operating system common to this whole family of boards from ETC, starts throwing some nasty subtleties in your path.  Whether it's full-scale Eos or one of the purpose-tailored variants -- Ion, Element, Congo, Cobalt, etc -- we run into the same issues.  This centers mostly on the Element, as explored at Arisia '19.

  Learning process

In advance of the convention, as part of trying to learn more about the board I went to see if more recent versions of the offline emulator were available.  I had a really old one which was missing a lot of the updated features, and hadn't fired it up in forever.  In poking around ETC's website I found a Mac-specific download of Nomad, which is what they're calling the desktop/laptop based package now, which can run both as an offline editor and become an online control when supplied with an appropriate output dongle.  I was astounded that the package actually *ran* on my ancient Mac, as usually newer software fails to load because the system libraries are too old.  ETC must have built this cut on a sufficiently back-rev machine.  Having it turned out to be really useful, since I could actually try stuff and learn what would work or not and what things actually look like in the displays.  One of the biggest learning-curve speedbumps on these boards is figuring out *how* to look at what you need to see.

First off, I tried to internalize ETC's wack-job nomenclature for screen and window layouts.  A workspace is basically what comes up on an external monitor, and it can contain various configurations of frames which split up the screen into distinct areas.  Within each frame can exist a number of displays, which are essentially windows, all of which are referenced by tabs descending from their window areas which can be clicked directly or tabbed through in sequence.  Displays/tabs can freely appear and disappear depending on what you're doing and typing, and can change size and location if the command-line area called "CIA" is expanded or not.  Some displays have different ways of, uh, displaying information, which the "Format" key can cycle between, and then the *amount* of displayed information can be changed with the "Flexi" key.  It's a little bit like the "box model" of HTML/CSS, in a way.  A given layout with displays assigned to frames within a particular workspace, all sized and formatted and "Flexi"-ed to one's liking, can be saved as a snapshot -- and liberal use of those to get back to a known state is highly recommended.  A snapshot saves everything about a viewed layout, including which tabs are fronted, the size and position of objects inside a display, how many frames are assigned and where, and the state of the command-line area.  [On Hog, the equivalent is called "desktop view".]

  Loopy LEDs

Now that we have some idea of what we're looking at and more importantly how to get it back again, it's time to try controlling some lights.  Generic dimmers are straightforward, and the traditional ETC syntax of <Record><bump-button> works well enought to record a scene component into a submaster.  Here's an example of how the best-intended setup can start going wrong.  Our rig at the time would have some LED fixtures mixed in, which are easy enough to control as separate traditional channels, but defining them with LED personalities allows use of more enhanced device-aware features like color pickers and crossfade paths.  A problem arises that even if an LED device only has simple DMX slots for its colors, R, G, and B for example, the board insists on including an intensity parameter in the personality -- even if it is only a virtual concept that doesn't exist in real life on the fixture itself.  Furthermore, the stock LED fixture personalities in the on-board library all default their color channels to full, so that when you bring up "intensity" on any of them you get white.  The fake intensity level basically applies a reduction factor across the color channels, and for the most part works okay with manual commands and cueing.  The problem with this is that typical LED control is easiest via the direct color channels only, allowing straightforward additive mixing, thus we want the color channels to start dark.  Sure, we could select the units and start mousing around on a color chart, but that's harder to do when the colors get run from submasters -- because really, that makes show design visually easier.

The attempted workaround this year was to copy the stock fixture in the fixture editor to a new custom type, and set the "home" value for all its color channels to 0 instead of 100.  Then, I dedicated one submaster to bring all LED *intensities* only to full -- stage still dark -- and left it up.  Programming more submasters only with individual colors then ran into the "grouping" problem primarily when done in Live mode, where for example trying to set Red to 100 results in the other colors also recorded into the submaster at 0.  This was most easily separated out in Blind, where clicking the column headers for Green, Blue, etc and typing "@ <enter>" knocked them out completely; this trick was noted in the Arisia '18 section.  Afterward, submaster mixing, color-picker, palettes, etc would work in a more sensible HTP way, and not cross-conflict.

That's all fine, until LED output is integrated into some larger general scenes with a combination of fixture types.  For example, we usually have some "general cool" and "general warm" full-stage looks with LEDs augmenting spectrum in a conventional wash.  These things are often run in combination, at different levels, to get a more neutral overall look and/or to just get more light on stage.  Here's where things get tricky: bringing up a submaster is execution of an operation, and in an environment where everything but intensities runs in a latest-takes-precedence way, the submaster that truly gets control of the LED parameters is the *last* one brought up from zero.  So you can start your pair of "gen Warm" and "gen Cool" upward but push the Cool slider higher, expecting more from the blues and greens of the LEDs, and then find that red and amber LED output is mixing in with your cool conventionals instead.  As wacked as this seems to anyone used to an all-HTP environment, it's simply because the warm slider came off 0 after the cool one did, so now the cool slider has little or no effect on its LED components while it's still driving the ice-blue lekos just fine.  In fact, the cool LED output has actually been stomped and forced *lower* by the precedence of the last-activated "Warms" slider, almost as though it was running a manual crossfade cue to its own exclusive scene. 

To get my cool LEDs back, I'd drop the cool slider to 0 and bring it back up, and lo and behold the mood on stage changed to what I intended!  So that was the Q&D workaround at the time for most cue composition and realtime stuff, once I was aware of what was going on.  But it still wasn't true HTP mixing.

The manual even specifically states, "non-intensity parameters (NPs) are always LTP" and there is no way out of that, either in custom fixture personalities, submaster attributes, patch, or anything.  Here's where ETC fell down on this, because there *are* occasions where we might want HTP behavior from something other than intensity -- especially with LEDs, where the color channels technically *are* intensities and levels can clearly be "more" or "less" than others.  The custom fixture editor doesn't really let you get clever and give a unit more than one intensity channel that actually works as intensity.  Even the "Generic RGB LED 8bit" fixture type adds the bogus intensity channel, not mapped to DMX output but regulating the color outputs.  That's the only part of it affected by "@ level" commands, inhibit subs, grandmasters, etc.

I'm certainly not the first person to have wrestled with this, uh, functionality, and arrived at similar workarounds and conclusions.  Users have complained and asked for help on ETC's very own forums after observing wacky, unexpected behavior from their devices:   Example 1, and   Example 2.  Take careful note of the posting dates -- it's been a steady undercurrent ever since these desks and their "philosophy" have been on the market.  The right answer here may be to give up on the fancy stuff, and go back to driving LEDs as collections of single channels.  At least you can type things like "1 thru 12 {offset} 3" when programming, to grab control of just the reds in your first four RGB units.  This leaves us with a choice: if you want to use the CIE chart and color palettes and rainbow effects and the board's idea of gel equivalences, use the LED personalities with color attributes.  If you just want pretty colors under your fingers right now, run them as straight 1:1 HTP channels and record what you see.

  Lovely LEDs

Once I have my independent LED control, however it was achieved, I do a slightly weird thing for the Rokboxes which are R, G, B, A, W.  Putting the sliders in that order makes it harder to bring up "flavors" of color without a lot of independent fiddling.  What makes things much easier is to order the sliders R, A, W, G, B, and then nice warm or cool pastel tones can be had by "slanting" the set of 5 one way or the other.

      |     |     |     |     |             |     |     |     |    [=]
     [=]    |     |     |     |             |     |     |    [=]    |
      |    [=]    |     |     |             |     |     |     |     |
      |     |    [=]    |     |             |     |    [=]    |     |
      |     |     |    [=]   [=]            |     |     |     |     |
      |     |     |     |     |             |    [=]    |     |     |
      |     |     |     |     |            [=]    |     |     |     |

              Warm-ish                              Super-cool
You can still get the punchy colors by bringing up individual colors -- basically, a saturate color has narrow spectral peaks, not a broad wash of wavelengths.  Generic combined looks or not, I would use this set for fine-tuning and then whatever I record into a cue plays back verbatim, thus pushing the precedence problem into the background for actual run.

  Cue blocking

Masquerades don't get rehearsed in their final run order, so any kind of sequential numbering effort is right out the window at run-time.  We tend to just use "cue block" numbers and call them as such.  On an Ion I'd be tempted to make each Masquerade entry a separate cuelist, to run independently on a slider or load it to the main go-controls.  While Eos in general is capable of working with multiple cue stacks at once, the Element is deliberately limited to one.  Almost like ETC is talking down to the theatre market, implying that several cuelists running in parallel is too complicated for them.  Thus, it is also impossible to assign a cuelist to a fader, as we can on the Ion -- these are only channels or subs on the Element, depending on the setting of the physical knob at the top.

I even tried to fake it in the emulator -- saved a show out as an ASCII file, which included data for cuelist 1, and then attempted to duplicate that section to a second cuelist and re-import that as a show file.  Locked the entire thing up solid -- Element was having none of this multiple-cuelist stuff, even when I tried to sneak it in the back door.

So on this board I wound up first recording full blocking base-state cues at every boundary of ten.  "Blocking" means that *every* stage channel and *every* attribute is hard-coded in the cue memory, so that everything goes to a known state and there aren't any tracked last-takes-precedence leftovers from earlier cues.  Cue xx1 would then be the entrant's first [and usually only] look.  A blackout would come next to bring them off, *specifically* only for intensities so that nothing else would change -- this is super-important for moving lights, because having lights fading *and* slewing back to home positions is the most distinct hallmark of poor programming.  I had all the relevant stage intensities on an inhibitive sub so I could just drag it all to dark quickly and record it.  As cues ran, once everything was out on an entrant I could either fall to the next block, or type "GotoCue xx0" to jump to another block.  So I was kind of faking separate cuelists with full "home states" as their boundaries.

I had one cue set up as a template for this -- with time set to 2 seconds, on ALL attribute types -- because simply typing "time 2" does NOT override the default 5 seconds for color, focus, and beam!  Just keep typing "Time" and it scrolls through the different parameter classes including F,C,B so you can update them.  [Yes, that bit me a couple of times when we changed cue timing for entrants.]  The mainstream Eos/Ion allows Setup defaults for those.  Then I just did "copy to" of that cue up to all the others one by one.  What got interesting about this is that as soon as I had a stage look and recorded it as xx1, the default "automark" operation of the board would put all the setup -- the LED color channels specifically, and mover presets if we'd had them -- effectively in the previous cue, xx0.  That's executed in that previous cue's timing, which is why making sure all the NPs ran in the same time was so important.  So xx0 would automatically function as a preset-in-dark for the next entrant, with only intensity coming up on the next Go.  Automark does ease programming a little if you're used to it and confident that it'll do the right things, but will affect how you think about framework.

Now, what nasty subtlety about Automark have I not mentioned yet?  Remember that intensities-only sub for LEDs that was up all the way?  Guess what Automark did -- by presetting the LED color channels to the next cue, there was suddenly light on stage from them in a supposed blackout!  So obviously the "intensity hack" sub had to be brought down for running cues properly, where LED intensity would come from the cue instead.

One thing that's lame about GotoCue is that things like follow times are NOT honored, the board just sits in that cue until you Go to the next one.  So if you had an awesome sequence loop starting at 120, don't count on it running by going to 120 -- program it to start on 121 with the follow, and then Goto 120 and hit main GO to kick it off.  I suppose you could write a macro to do that for you...

  More departures from the Old Way

The board is so married to LTP operation that even the old concept of "capturing" a channel is gone.  You can command 3 @ Full and it will turn red saying "FL", but will only stay that way while the channel is *selected*. Work on something else, and then if you run one of your hard-blackout cues, guess what?  3 is forced back to zero.  It used to be that manually grabbed channels took highest precedence and stayed put; not so now.  The only way to keep something commanded where you want it is Park.  At least the Park display allows making a channel selection and then wheeling up and down, so you can set it where it looks right, and as soon as you dismiss the Park display it's locked there. 

Since an unfamiliar board may have remnants of someone else's show in power-on recall memory, it's best to sit down at it and start a completely new show file and name it what you want up front.  A freshly created show has a lot of stupid defaults in it, so by now I've now got a short checklist of what to go through under "Setup" and fix before doing much else.  It takes a little wandering through the settings groups for Show, Desk, Cue, Manual, etc to find all these things -- the locations and categories are sort of non-obvious.  Default cue times -- 2 seconds, and make sure to include all the NP attributes if possible.  Sneak time -- either 0 or at least fairly fast, like 0.5 sec.  Auto-playback helps the cueing process sometimes, i.e. after you record one, you're sitting in it.  Auto-mark enabled, if you have a good understanding of what it will do. And for a fast way to take all channels unquestionably out, a quick macro:

     GotoCue  Out  Time  0  <>  Clear  Sneak  0  <>  ClearCommand
where "<>" is <Enter> to terminate a line, that shows as a little diamond.  GotoCue and Sneak both take time qualifiers.  This is a decent equivalent to instant "release" on the Express series, and resets any running cuelists back to dark as well.  If something's still on after that and your subs pulled down, it's either parked or broken.

Then, set up workspaces/frames/displays in a couple of different ways -- perhaps one layout for programming, and another one for show run, and save snapshots of those.  For the Arisia show I only ever used one physical monitor, and usually just one big frame on that -- about the closest we'd get to a traditional Express display, but it showed me what I wanted.  I also had a two-up layout with some direct-selects for groups and palettes, but never really used them.  You can reference such things by number anyway.  The direct-selects are unable to contain one item that Hog users depend on heavily -- cuelists, that can directly run when moused!  In Eos, you *have* to bind a cuelist to a fader to execute it.

Then I'd patch up, make a gentle preheat for conventionals, maybe have an inhibit sub for all stage units that doesn't affect house or other stuff, and go to town.  Once I got into the flow of things in this environment it was kind of fun, but I did keep thinking about all the things I missed about the Hog.  While we didn't really use the Robo 918 "wiggle lights" on the show, two had come over in the late load and I fired one up just to play with it.  The fixture personality still has a lot of stuff wrong, and of course the Element doesn't have encoders, but the "ML Controls" panel comes up and can be moused, so it is possible to do some rudimentary moving-light programming on it.  The underlying control brains are basically the same.

And having explored all of the foregoing in more depth this year, *my* brain will never be the same again.


_H*   190207