## This contains two parts, describing interaction with the SmartFade board:
##    pre-event thoughts
##    post-event experiences

Subject: Smartfade @ Arisia
Date: Sat,  8 Jan 2011 21:01:01 +0000 (GMT)

One piece of relatively new gear I'm renting for Arisia is an ETC Smartfade
24/96 board.  These have shown up at a few cons in the past but were never
really utilized, and a couple of years ago I railed a bit at its lack of a
properly-featured cue stack.  That's still true, but there are some other
favorable reasons for picking one of these boards.  It looks roughly like

   http://techno-fandom.org/~hobbit/lighting/arisia11/sf.jpg

which is a screenshot from their "SmartSoft" emulator application, and
the manual is available at etcconnect.com.

It's one of the cheaper options our local rental house has in stock, for
starters.  Quite a bit less to rent than the Leprecon 1536 we've gotten
for a few years.

It can do 96 channels, which allows a bit more versatility in the rig
this year.  Besides the usual dimmers and cyc units I'm getting a batch
of Ocean Optics SeaChangers dichroics for side-stage -- they're like the
Colormerge units we've had before, assembled between the body and barrel
of a source 4, but are *so* much nicer.  They take 4 DMX channels apiece
for CMYG, so for full color separation capability among six units that's
another 24 separate control channels needed.  For an entire weekend's
worth of diverse events I can see a few reasons for not wanting to just
gang them up per-side or whatever at the DMX or patch level, so we're
already past what the Lep could offer.  More channels also allows for
interesting cyc-unit splits.

It has a shitload of submaster memories, arranged in 12 easily-accessible
pages.  So for a Masq or the like it would be feasible to run in "sub or
two per entry" mode and basically never run out, and still have a bunch
of look-composition basics ready to hand for building scenes.

It can save onto an SD card, and its default file format is a USITT  .ASC
file which can easily be hand-edited if necessary.  Whee!  Build your show
offline in emacs or vi, your choice!

The board *does* have a cue stack, but the big downside is that there's no
concept of link cues.  The traditional approach with the Lep was to record
entrant cues starting on block boundaries of 10, just doing it linearly
through rehearsals and then inserting cue *link* numbers to chain them all
together the right way once we got run-order sheets.  In the absence of a
scratch, this works well -- you can just go, go, go right from one to the
other if you've built in all the setup and blackouts around it.  But you
can't do that on a Smartfade; you'd have to be frantically manually wheeling
the "next" called cue number to wherever it needed to go and there usually
isn't time for that during run.  And we *never* rehearse in run order, as
nice as that might have been.

I really don't understand the aversion of some board designers to having
a plain ol' keypad, easily facilitating a "goto cue NNN" command.  This
is a serious break from ETC's longstanding tradition of straightforward
keypad entry, which fortunately hasn't [yet??] spilled over into the newer
high-end stuff.  An encoder wheel is just about the height of *wrong* in a
UI involving arbitrary numbers under performance pressure.  And the board's
propensity for having lots of little lighted buttons continually *blinking*
at the operator is sure to drive some people bonkers.

While sub-per-entry and direct access to them can make up for cue-stack
deficiencies in the type of shows we do, now we're also throwing in the
wrinkle that the SeaChangers need to be preset in black to whatever color
they'll show when lights come up.  You don't want to have them crossfading
from white along with fadeup, eww!  Before you ask, no, there's no
inhibit-mode submaster capability like on other ETC boards which would
allow holding down all the intensities while the rest of a memory sets up.
So how do you do get the correct effect when running on HTP-only submasters?
Workaround: use two subs -- one for color preset, and one to add in the
lights themselves.

Given the slider layout and how pages work, it seems best to use two memories
physically located above each other, and reference each "virtual cue block"
from the show-caller's standpoint by a simple two digit number.  The first
digit is the memory page the pair is on, and the second digit is the "setup"
sub for the entry.  The sub under it then does intensity up/down.  So when
L1 hears "lighting cue 23", she'll quickly swap to page 2 and bring up
sub 3 on that page, and then be ready on sub 27 under it for the Go.  The
setup can happen as fast as desired, since the Seachangers are dead-quiet
at any speed.  Old CXI scrollers, these ain't.  To record, get the desired
look and then just record *both* appropriate memories and edit lights out
of the preset side later, or if time/facility permits go to black without
touching the color and then record the setup-only memory on the upper handle.
Memories can also be copied, so splitting a single "has everything" handle
into two during post-fixup is fairly easy.

So that allows for 9 x 9 = 81 distinct single-look entries using two digits
of reference.

But what about multi-cue entries, which we get often enough?  We need to
change to one or more different states, but ultimately still hold the
Seachangers still during final fade-down.  Simple: use the next vertical
pair of memories to the right, and manually crossfade pair-to-pair which
is an easy two-handed action.  The final intensity fade would run on the
lower slider as though it was a single-cue entry, and then the upper one
releases the color.  So for a typical two-cue entry called "23", memories
3, 4, 27, and 28 on page 2 would be used and we'd never call a cue-block
"24".  Obviously the higher subs toward the right end of the board on
each page would generally not get used in such a scheme, but that's okay.
There could also be alternate multi-state memory allocation schemes that
might increase efficiency a little, but the idea is to minimize likelihood
of errors *and* keep it simple for the show caller [i.e. no cues in the
hundreds].  An upcoming entrant block that we're told will be multi-cue
could easily start on any page's handle-pair 9 and spill into 10/34,
11/35 ... and remain opaque to the overall labeling scheme.

I suppose that for something *really* complex, like that "complete LoTR
trilogy in nine lighting cues" deal from last year, it would be easier
to use the cue stack anyway.  For a *very* small number of those, it would
be feasible to wheel to the right startpoint for each one.

Just some thoughts about board organization strategy to deal with these
little guys.  We will probably see quite a few more of them deployed in
other spaces we tend to work, so there's no harm in getting more familiar
with them.

_H*

 === post-show wrapup; see "arisia11/" for specifics ===

The Smartfade, for all its perceived faults, could handle everything we needed
for the weekend.  Having 96 channels of control was nice in a rig with half a
dozen SeaChanger dichroics and LED cyc units, as I was able to address all of
that in a fine-grained fashion.  This allowed for some beautiful sweeps of
color across the cyc, a bunch of different sidelight color for that "party"
look, etc.

Having the SmartSoft offline package available was useful, as it allowed
exploring the user interface in good depth before applying knowledge to the
live board.  It turned out I was playing with version 2.something and the
board we got was already up to 3.0.0, but the differences are quite minor.
Obtaining any of these offline applications from ETC's website is a nightmare,
as they don't provide straightforward links to them and run the visitor
through script-laden forms to try and collect personal information before
finally pointing to where it really resides.  I would provide direct links
except that as the versions advance, additional unpredictable numbers become
embedded in the filenames along with [build numbers or dates or something] so
it's probably best for those interested to just run through the dance and get
their own latest copy.  The SmartSoft app is pretty large -- around 100Mb for
the Mac package once unzipped.

I arrived at the event with a predefined patch done in SmartSoft and stored
to an SD card, and the real board read it right in.  The patch was some basic
rerouting to collect channels in the cyc units, which are normally RGB RGB
etc, so with a little fiddling I could have all the reds in one slider block,
all the greens in another, etc.  By simply drawing "curves" with the sliders
in each color, nice laterally-blending rainbows would appear.  Naturally
I also had full-cyc subs for RGB containing all the appropriate channels.

All the look-construction basics were built onto page 12, and then a few
essentials from that such as preheat, house lights, MC podium, and a basic
"get light on stage" sub were copied to just about *every* other page on down
in advance.  Those would be needed regardless of where anyone was.  Some higher
pages were used for other events, leaving 1 through 9 free.  Another group with
their own lighting person took over the venue for some periods of time, and
could run on their own page with some very simple basics that met their needs.
Now, there is a nasty board "feature" in which typing MEMS twice in a fairly
leisurely definition of "quick" succession immediately swaps to page 1.  I
would say the most important thing when handing off to someone else, besides
having all the above essentials available on every page, is to teach them
how to hold down MEMS and bump back to their own show page in case they
inadvertently swap to another.

My theoretical "batches of subs" on different low memory pages as a masquerade
run technique worked out okay, using the vertically-oriented pairs of memory
faders for setup and execute of entrant lighting.  We in fact had a fairly
large Masquerade, and I was working on page 4 by the time we got through
rehearsals.  Blocks 11 and 12 I preconstructed as "generic warm" and "generic
cool" [which our crew loosely refers to as "warm fred" and "cool fred"] and
used them for a few entries -- e.g. on a 24/96, page 1 memories 1 (setup)
and 25 (run) for the warm look.  But with all that lovely side-stage color
available under my fingertips in many cases it was easier and more appropriate
to build a new look for each entrant.  I found myself getting the total look,
and then recording the second memory of the set [the full "go"] and then
bringing everything except the color-changers down to record the setup memory.
Then to run the piece I could just bring the secondary one back up in time.

For a multi-step entry and crossfading pairs of memories, the second one
should be brought up about halfway before the first one starts down for a
better "dipless" crossfade.  In cases where the second one simply brings in
more light, it may not even be necessary for a true crossfade -- just add
the "go" slider of the second set into the mix, and then pull both lower ones
at the fade.  So the usage here isn't 100% cut and dried.  Crossfades in
color-changers can also get a little squirrely since bringing in too much of
multiple dichroics tends to make the light *dim out* and go muddy.  So now
it's ideally "high cross" on the lights and "low cross" on the CMYs!  This
might actually need a little practice to pull off.

Under pressure I got a little confused once or twice as to which page I was on
and may have overwritten something minor on my "construction tools" page, but
either it was nonessential and there's always this "undo" button on the board.
Thinking about this and the "default to page 1" thing in post, maybe it would
have been prudent to keep a copy of the scene-building tools on page 1 anyway,
for an easy one-handed way to get back to them, and start building more complex
look blocks on pages 2 and up.  With all the look-constructors built beginning
from the right-hand end of the slider blocks, that would have still accomodated
my "11" and "12" and a couple of others right there on page 1 along with.

Since a cue can reference a memory instead of hold a specific output state,
I could presumably have still used the stack to drive the Masq memory pairs.
To do that, the REC SEQ button must be used [still with STACK as the target
"sequence"] and the bump for the appropriate memory entered as the contents.
As mentioned a while back, the board's stack is really a degenerate case of
"sequence" without the looping but with its own state memory.  During playback
in such a mode, the board *does* show in the display what the contents of
the next cue are -- either "State" or "Mem:01/04" and the like, so that
would give a little confirmation that the correct next thing will happen.
This would have involved building the stack to reference all the right "block"
numbers in run-order once it was known, and making sure appropriate setup
and blackouts were wrapped around each section, possibly as point-cues so the
main sequence numbers would match the run order -- almost certainly adding
another layer of possible screwup, as well as additional time in pre-show
prep to bang all that meta-framework in.  And since the show-caller already
had the block numbers and at runtime it was quite straightforward to swap
pages and go, there wasn't actually any need.  But if someone re-e-ealy needs
go-button simplicity or it's a multi-night show with leisure to build the
cue-wrapper, that's another usage methodology to think about.

I did use the cue stack for one part of the show, a musical play.  Building
the cuelist was fairly straightforward.  There's a minor difference in stack
recording between version 2.x and 3.0, where doing REC MEM and STACK offers
the opportunity to wheel to exactly *which* cue is to be recorded.  This is
useful for a number of reasons -- if nothing else, showing which cue is about
to get overwritten if you're not at the end of the stack already.  2.x only
offers "new step" by default without saying where it would be placed, and the
hidden answer is right after the cue currently playing which may come as a
surprise.  Also when one needs to duplicate one cue into another later on,
i.e. a repeat of a previous scene, it's handy to wheel around to exactly
the desired destination cue before committing to it.

It seems that to edit an existing cue, the easiest way is to simply be in
it and invoke EDIT MEM.  Blind editing is doable but involves a lot of
wheeling and "yes" button hair -- Yes, Sequences, Playback:XF, Modify Steps,
Select Step, Edit, fiddle with the channels, and finally EDIT MEM to save --
all that to change ONE cue, and one has to go through this ENTIRE set of
steps for each one to edit.  Best to just run the stack and change what's
needed live.

There are some restrictions on what can be brought up and left there when
swapping modes and re-using a fader for its different purpose.  If a memory
is brought up and then the page changed, the memory in question remains
"locked" on the previous page and cannot be reused in the current page until
it's brought to 0.  That's fairly normal and expected, but what if something
needs to be lit and left as is?  It must be done at the channel level, since
swapping between channel blocks and MEMS doesn't lock a slider.  For example,
a couple of safety lights left on just a little at "full black" in everything
else, such as rope-lights we use to edge the stage and put a tiny glow into.
If those are cheated up at the channel level and the board swapped back to
MEMS mode for running, it's the closest equivalent this board has to parking
[modulo any use of the grandmaster, of course].  Beware: typing CLEAR various
numbers of times will make those go back out too, as it's not a true "park".
The MEMS are more "sticky" with regard to page changes, so when allocating
memories it's good to keep potential slider re-use conflicts in mind and
separate them.

So ... despite the lack of a real keypad, at this point I'd use a Smartfade
again on a show and would encourage others to explore as well.  They may very
well find some more useful tricks and methodologies that I've completely
missed.  And making show backups is certainly easier onto SD instead of
messing with floppies or a MIDI laptop.

_H*  110121