Eos is pretty clearly ETC's attempt to catch up with the Hog series, which predates them and most other console makers by about ten years in terms of capability and interface design. It still seems like everybody else is way behind Flying Pig in this regard. ETC has drawn on some of its own prior console art and clearly swiped several ideas wholesale from the Hog methodology and some of the other manufacturers, getting some things right [e.g. mostly intuitive for people experienced on the Expression/Express line] and totally screwing the pooch on others. They have a whitepaper on the website that seems to make various excuses for their adopted development philosophy.

One upside in starting any of this study is that ETC not only has the full Eos / Ion manuals up for grabs at etcconnect.com, they also host a bunch of tutorial Youtube videos [albeit done in a rather dumbed-down style] and full emulators / offline programs one can install on a PC or Mac and at least get to fool with some of the basics. [*Native* on MacOS, yet!] They haven't forgotten the value of a designer being able to lay out the bulk of a show in an offline package and then transfer that to the real board. However, ETC's website doesn't work at all unless you turn on cookies and are sending some non-null User-Agent header; I did beat their self-designated "webmonkey" up about this after getting a bit frustrated trying to find stuff [and I have some direct link references into their product pages from other writeups that can break as a result too!]. Trying to actually download any software roadblocked me with a stupid signup form with a scripting-based "submit" button which I found not only intrusive but completely nonfunctional, so I finally called in and I think their web team got the message when I said "I'm starting to feel like the webmonkey is throwing its feces at me through the cage". They read me a direct download URL for what I needed, and I finally got the bits. We should soon see less dependency on browser fluff at their site as they work on updating it. Yup, still fighting the battle, one naively misguided company at a time.

Once through that, their "Eos Family" software package came up reasonably straightforwardly on my macbook, although I did *not* run their silly installer as an admin user and only had to point to the application bundle and fiddle one symlink under /Library to let it find all its fixture libraries and the like. There is a keyboard-shortcut PDF guide with it as well, just like HogPC provides. The running binary on Mac is *huge* -- 51 Mb or so. It contains all the extra guk like PDF backends, Qt display stuff, image libraries and screen graphic components, fonts, printing handlers, internationalization support, USITT/ASCII show-file and other export format conversion, and of course various types of device networking including TCP/IP as that's one option for talking to remote DMX processors over ethernet. Eep. I even saw one or two references to "www.inkscape.org" go by in the internal strings. A lot of its internal database storage appears to use multibyte/Unicode, bloating it by 2x or more. The offline software seemed to function pretty cleanly other than the fact that my mouse cursor kept sporadically vanishing while moving over the program's window. It sufficed to explore some of the concepts laid out in the manual.

This appears to be ETC's first real foray into modern moving-light control as the industry has generally come to think about it, e.g. every *device* is treated as as single "fixture" or in ETC's nomenclature, a "channel". That can be confusing sometimes but ETC clarifies that by always speaking of DMX numbers as "addresses". What it doesn't allow for is the Hog versatility of referencing devices either by "type / number" or unique device number within a rig. But once you've selected a given device, the typical classes of changeable parameter are then applied to it -- intensity, focus [position], color, beam. And as with all such things, "beam" tends to get more and more overloaded as new features appear in moving lights like programmable shutters, motion-effect wheels, zoom/focus optics, etc. Parameter abstraction and palettes are supported, including graphic hue/saturation color wheel pickers and an extensive database of gel numbers from which one can "get close" to an expected color in CMY changers and such. Things like strobe frequency and pan/tilt degrees are taken into account, expected real-life accuracy aside. It's even got little images of stock gobos in various fixtures, like LightJockey started to have back in, what, 2002 or so? ... although a quick check shows that ETC got some of them wrong for at least my vintage of Robo 918s. Well, Martin is the evil competition, they can't be expected to care too much. What was really funky was how trying to slide around on the color picker for a 918 became all jumpy, since the 918 only has discrete color wheels instead of CMY fading and the desk seems to know that only certain slot combinations of the two wheels are available.

One thing I can't understand is how ETC brought back one of the dumbest visual means of indicating devices -- the little oval "tiles" that were such a space-wasting nightmare in the early "Horizon" PC-based desks. They even apply the cumbersome "selection toggle" model if you mouse them. For something as lean as a single dimmer, wasting an entire tile's worth of screen real estate to indicate channel and current level is nonsense. It only possibly makes sense when you're considering a moving light or even a scroller or CMY color-changer that has some color attributes, but even here they don't really show you what's specifically going on with that fixture. We couldn't find a way to get any more information than "this device has some part of its I/F/C/B attribute class set" by seeing a tiny "+" sign turn some other color on the screen, the color loosely indicating if the change had come from a sub, a cue, manual control, etc. With that much pixelage dedicated to ONE item, ETC didn't even do anything intelligent like, say, take a little thin bar up one side of it to visually indicate intensity or the like, which would have been trivial to do and much faster to see at a quick glance than trying to squint at a number. Even the alternate "table view" with devices listed in a slightly longer format doesn't reveal much information as to actual state. By contrast, the Hog model for showing output is to make the required area as small as possible for a given device type, group them by device classes, and dedicate a maximum of ONE line of text to each for more complex things like movers. This allows the entirety of a respectable rig to appear on one screen in full detail showing where things are set to, including palette references even if some longer names get truncated a little bit. It's enough, very compact, and lends itself well to offline programming. Well, at least with ETC it seems you can zoom the overall screen size of icons and objects and make them really small, which may help.

The "RELease" button is gone. This caused all kinds of confusion until I found the obscure little paragraph in the manual about how they've overloaded the "Sneak" button to effectively mean the same thing. The thinking is that once you've grabbed a few things and messed with them and recorded what you need, the next operation is to "sneak" those items back to some background base state. The only real difference is that the traditional "Release" is immediate, and "Sneak" can have a configurable fade time associated with it so that an audience is less likely to notice a change if it's done live. Well, when you're programming cues or banging through dimmers at a focus, who really cares about that?? But that's how they chose to go at it, so now we know that [Clear][Sneak][Enter] is the Eos equivalent of [Rel][Rel].

It is also possible to have channels still under manual control even *after* you thought you snuck everything out -- it's a weird limbo state where the desk assumes you're building a tracking cue of some sort and now the channels remain up but in magenta instead of the usual red meaning "grabbed". This is *not* documented anywhere, but sufficient thrashing turned up that the get-me-outa-here fix to that state is [Goto Cue][Out] which jumps the expected "background" state back to the default zeroth cue with all parameters reset. If this doesn't make any sense, well, it didn't to me either but I'm just relating this in case anyone finds themselves on one of these desks staring at a bunch of purple numbers that refuse to go away and thinking "how the F did I get into *this* mess?!" I suppose it's the moral equivalent of the "programmer" in the Hog, where one can have many fixtures under manual control but not every one of them necessarily *selected* for futher modification. Their philosophy whitepaper even makes reference to a "programmer" area without mentioning that it's an original Hog concept. I could also see this being useful at focus to leave some lights up while changes are being done to others and have some of them *immune* to being released by mistake for a while, but the way it works really needs to be prominently documented. The folks over at Lightnetwork seem to agree [you may need cookies enabled to see the postings].

Speaking of tracking, the desk finally adopts the fairly standard modern philosophy that everything "tracks" forward through a cue-list, e.g. if you've told something to be in a particular state it stays that way until some later cue explicitly changes it. This is NOT how the older consoles work, although the Express series does have a rudimentary concept of tracking if you remember to invoke it specifically for each recorded cue. In the Eos series the tracking model is also optional, i.e. you can globally turn it off and cue behavior will revert to the hard-values-everywhere style we find in the older boards. With moving lights and many devices that really want to be preset in dark before intensity comes up, tracking is generally the way everyone thinks about these things now, and it can certainly apply to a rack of conventional dimmers just as easily. Like cue 1 brings up your main stage washes; cue 2 brings up a special and cue 3 brings it out; obviously to store cues 2 and 3 as "<special>@FL" and "<special>@00" takes much less memory than storing hard values for the whole rest of the stage along with. But one always has the option of making a cue into a "blocking" cue which effectively puts a bunch of new hard values for everything else into it too. Now, ETC tries to make a big deal out of this by having a type attribute for each cue -- this just confuses the whole picture, because really, all a blocking cue does is assign new values for every device and then tracking would proceed onward from there. The Hog model simply suggests recording all the attributes you want to change in a given cue, without trying to give it some special mystical quality -- if you want a value of 0 at some point and have that track forward, just set the damn thing to 0 and be done with it. ETC's documentation falls all over itself trying to explain "block" instructions vs. "assert" and a couple of other cue-related issues and I *still* don't understand quite what they're getting at with it.

They also try to be intelligent about "auto-marking", e.g. if one cue sets a bunch of parameters including intensity in a device, there's an option to semi-automatically let the *previous* cue set up all the non-intensity parts so the fadeup is clean in the current cue. That's called "mark" for reasons I never quite understood. The Hog has some concept of this too but I never used it, as living and breathing the tracking philosophy encourages one to just program like that anyway and leave out the intensity changes until the right moment.

We were amused to realize that the guts of the board is an ordinary compact PC motherboard jammed into a box hanging off the rear, complete with USB and ethernet ports and 1/8" sound I/O jacks in the back, and then the rest of the desk wrapped around that. With the base desk you get *no* sliders except the main cue-run crossfader and a grandmaster; you have to buy fader wings if you want submaster sliders. Submasters seem to no longer be grouped in pages in the traditional sense; you do get to switch through blocks of faders as they appear on the wing but they all have unique numbers up to something like 300 instead of "page 2 sub 3". So the concept of sub page changes simply slides your viewing window around over a larger spread of them. And the wing faders aren't just subs; they can also be various forms of playback handle for alternate cuelists and effects. In fact by default on a new show they aren't *anything* -- you have to configure them to be *something* before they work at all. There are some show-setup bulk shortcuts to help with this in various typical ways, though.

Submasters are the usual proportional HTP type, although they can be set to use LTP syntax which probably makes things get really interesting if you're running a combination of cues and subs. Subs can also be used as group selection specifiers, a la [Group][Sub][4] to grab all the fixtures defined in that sub for further fiddling. One big caveat with that is that a sub can contain a channel set at zero intensity -- which you'd never notice on normal HTP playback as some other sub containing a real value would override it, but would broaden a group-selection beyond what's expected -- this bit us at some point because during sub programming some unwanted channels had been forced to 0 rather than snuck out of control completely. One is advised to go back through programmed subs in "blind" and look for any channel with 0 as the value and delete it, as it can cause confusion. This has been made a bit more cumbersome on the Eos/Ion, as the old syntax of typing [Sub] and then using the [+] and [-] keys to whip through them while staring at the screen to see what values come up no longer works, but the rough equivalent is available via the [Next] and [Last] keys. To get into the correct mode to do this, you have to type all of [Sub][n][Enter] out to start examining any one of them and then you can quickly index back and forth. The [Last] key really should have been named [Previous], as "last" sort of implies recalling what was most recently changed. Be aware that submaster edits in blind mode take effect immediately -- no need to re-record them, as they're already changed as soon as channels are modified.

Note carefully that while the typical ETC notion of groups still exists too, they do NOT store proportional intensity data whether they are selected from subs or the regular [Group] numbers. They are now *only* channel selectors. That's going to throw a few people. The workaround, I suppose, is to just make a handful of subs and bring them up as needed.

Eos can now handle multiple cuelists, which has been the foundation playback model for the Hog since day 1. But I don't think Eos can play a cuelist straight out of memory like the Hog can, it has to be bound to a slider somewhere, and there doesn't seem to be much consideration for one cuelist kicking another one to run as needed. This would make my ridiculously multi-level club-dance environment pretty much impossible to duplicate on an Eos class board. Might be okay for the rock-n-rollers who want to busk a fistful of faders along with the band, something that Avolites set some of the industry precedents on especially when moving lights started entering the picture.

The physical console provides four parameter finger-wheels across the top as well as a separate level/intensity wheel to the right of the keypad as so well-loved in the Microvision and Expression lines. It's really nice to be able to type a couple of channels and wheel them up *slowly*, being much nicer to cold filaments, and the usual assumption is made that moving the wheel terminates the selection command and starts changing levels. I found this level wheel to be a bit squirrely, but someone may have set its multiplier and acceleration a little wonky and I didn't go in and check. We were pleased that once we worked through patching up some CMY scroller/dimmer fixtures for the Colormerges in the show, that once a combined unit was selected and the "color" parameter group accessed, the CMY values came right up mapped to the first three wheels and we could spin away into all kinds of lurid looks. There seems to be an option for using a trackball for doing X/Y position programming, but ETC chose not to follow Hog3's example and build one into the console.

One thing I noticed immediately is that some operations are *dog-slow*. Basics like switching between [Live] and [Blind] take a noticeable half-second or more delay. In some multi-part patching operations [such as defining a CMY scroller/dimmer] we typed [Enter] and had time to look and say "huh, that didn't seem to ..." before the command actually completed and updated the screen. I believe the backend OS in the physical console is some Windows variant, especially noting how internal and USB drives come up as C: and E: and such, so if that's the case then what can we really expect in terms of OS efficiency. The Hog 3 software family runs on an embedded Linux kernel, which was probably the only starting point available that could hold its own against the lean completely custom touchscreen OS they did for the Hog 2 back in the day.

Anyway, there's probably much more to be learned about these things going forward, but this weekend was probably more useful in a learning sense than getting a seat at the recent training sessions that ALPS hosted last month that filled up too quickly for any of us to attend.

_H*   100215