Will version 1.5 fix this...

I think that you've misunderstood a few things about the difference between Assert and Block in Eos.

Blocking is a Recording/Updating function - it defines how updates will track (or not) through the cuelist.

Asserting is a Playback function - it defines how the cues interact with each other.

Quote:

"What we need a is Black While Moving function (BWM) from a console that doesn't yet have true Move In Black (MIB).  That is, someway to force fade the mover in anticipation of moving to a new mark for the pending cue."

I don't think you really mean that you want Black-While-Moving, and we're not going to do it. There are a couple of main reasons why:

• How does the console know which lights should "Blackout, move, come up" and which should "Move across the stage while still on"?
• How does the console know how fast to fade the lights out, how fast to move them and how fast to bring them back?

The only way to know is for you to tell the console.

So you just need to insert a cue between that blacks out the fixtures you want to mark, while the ones that you want to move live remain on. You've then got complete control over the transition to pick the lights and the timings, using the tools you already know. You can set that cue to auto-follow into the upfade after the move, or to wait until you press Go.

The console does have a fully-featured Move-In-Black function, in fact it has one that's far more advanced than many other consoles - the Mark function allows you to tell the console to mark anything at any appropriate point in time. Move-In-Black only does it at completion of the previous cue, while Eos can have fixtures mark several cues earlier - you can even have it mark unused fixtures right at the start of the show when they're actually used right at the end.

However, I think you're looking for the "Automark" option. This automatically flags Mark cues where possible.

Remember that you can set follow-on/wait times for your 'fade-out' marking cues, so the fade-out-move-come-up cues run automatically.

Hi there... Richard addressed most of the issues you brought up (I think).

You might notice some softkeys when you [Go to Cue[- there are some softkeys painted that allow you to select what components of the the cue you'd like to go to... this includes "moves only."

Out of sequence cues. (linked cues or cues that you load into pending). These are always taken as full asserts - in that the entire content of the cue is replayed.     You mention that out of sequence cues do not respect null values.  This is true.  When any cue is taken out of sequence - and this includes a go to instruction - the desk will clear any manual values that are not overrides of another active cue list.  This is to keep you from having to clear out manual states that might  be left hanging.... when all you are trying to do is get back to a known state.   Imagine if we didn't do that?  When you went to a blackout cue, if you had manual values up on channels that were not stored in the cue list --- they would be left up.  Channels can be captured... and selected channels are withheld from go commands. 

Automark enable can be found in the setup menu.  It is disabled by default.  When enabled, it can be disabled on a cue or cue part basis.

The difference between block and assert is something that catches a lot of users the first time.     But splitting those feature up ... so that blocking is only about editing, and assert is only about playback --- adds greater control.

Hope this helps.

a

Hi there... Richard addressed most of the issues you brought up (I think).

You might notice some softkeys when you [Go to Cue[- there are some softkeys painted that allow you to select what components of the the cue you'd like to go to... this includes "moves only."

Out of sequence cues. (linked cues or cues that you load into pending). These are always taken as full asserts - in that the entire content of the cue is replayed.     You mention that out of sequence cues do not respect null values.  This is true.  When any cue is taken out of sequence - and this includes a go to instruction - the desk will clear any manual values that are not overrides of another active cue list.  This is to keep you from having to clear out manual states that might  be left hanging.... when all you are trying to do is get back to a known state.   Imagine if we didn't do that?  When you went to a blackout cue, if you had manual values up on channels that were not stored in the cue list --- they would be left up.  Channels can be captured... and selected channels are withheld from go commands. 

Automark enable can be found in the setup menu.  It is disabled by default.  When enabled, it can be disabled on a cue or cue part basis.

The difference between block and assert is something that catches a lot of users the first time.     But splitting those feature up ... so that blocking is only about editing, and assert is only about playback --- adds greater control.

Hope this helps.

a

The problem with "Automark" is that its just reference marking running a Just In Time (JIT) algorithm.  The marking is decided during editing (design time) instead of playback (runtime).  As a result, it will not function out ouf sequence.  Also reference marking and auto marking are mutually exclusive, and toggling Automark Enable will erase all your manual reference marks.  With MIB at least some of the out of sequence  transition will be cleaned up.  There are consoles out there that have MIB and reference marking and reference cues not relegated to just marking. 

Now, since linking a cue is a design time edit, is there any reason automark couldn't read the link and make an adjustment? 

Also, I think stuffing a bunch of nulls in a cue is not something a novice would do and should convey my intention sufficiently to the console to NOT assert trackings values for any reason. 

The problem of a mover being on in one cuelist and being ASSERTed out into another preset by another cuelist (a flyaway) is solvable by delaying the move until fadeout  (like MIB which would have to be a runtime decision since you have to wait to see which GO is pressed) .

As to manual values being left up, they are left up during normal execution until a move is reached.  I think there should be a difference between a GOTO CUE command line jump, and a jump programmed into cues.  Link and loads should not just act like a GOTO CUE macro.  The fact that all cues have an ASSERT option available means you should not have hard wired it to Link /Load operations.  More options for the operator is a better selling point.

I f you check the release notes for version 1.4.0 you will see that the changing block channels to recording/editing only is fairly recent.  Traditionally a blocked channel is a redundant move, but still, a move, and as such will take control when Go is pressed.  The release notes also state that older versions of shows having block cues will have the ASSERT flags set on them when loaded into a 1.4.x console.  This is to retain the old functionallity. So when Richard states that ASSERT is for cuelist to cuelist interaction only, he is mistaken.

If you want that white zero to take control on Go you need to apply an ASSERT flag to the channel itself.

The GOTO CUE softkeys don't seem to function as advertised.  The moves that don't play back get faded to background (like nulls).  This is still a "move" in my opinion.

I still need a way to execute an "known move'  and not a "known state".  Like movers fading for auto marking and everything else untouched, no matter what is in control. This is not a problem for a real tracking console.  You need to take the "training wheels" off future versions.

Go to Cue is working as per our design intent (or should be).  It sounds as though you are looking for a merge function, to leave other stage content untouched.   This can currently be accomplished from a query or a  recall.  Having said that, we could add a condition in Go to Cue to combine the stage looks.   This would make it faster to achieve what you are looking for, but that would remain an exception to the basic rule set defining Go to Cue operations. 

Yes, we did change the block function after release.  This was done upon conversation with programmers who felt they'd have more flexibility if block became an editing only function and assert was for playback.   I've had designers in the past complaining that once editing was complete (if that EVER happens), they'd have to lift their blocks to get the show to play back the way they wanted.  The block and assert flags can be applied in the same instruction, and the keys are adjacent to one another.  In the past several months, this decision has been revisited since people now have time with the changed function.  The decision was to leave the behavior as currently specified.

In retrospect, we should have perhaps called block something else - but as the change was made after we started shipping the product, that ship had sailed.  All desks have the same labeled functions - update, record/store, highlight.  They all put a slightly different twist on them.  This decision was neither made  capriciously  nor in a vacuum, but upon consultation with a number users.  I'm sorry you disagree with the decision.  

Regarding marking - Go to Cue use marks will respect lights that are fading to zero and then automarking.  Go to Cue use marks does not currently respect lights that should already be marked when the cue comes active.  That is being added in an upcoming build.  Will look into automarking respecting links.  It's been discussed in the past, but we've never implemented it.  Automarking would be fine for this.... for users who prefer referenced marks, it could get a bit tangled.  Will review. 

I'm curious..... what type of show are you doing?

Anne

And you are correct.  Assert is not just for inter-cue list behavior.  Where I see most people get caught by this is going to a blackout, that is blocked, when some of the channels have begun their fade out in the previous cue.    We are looking for ways to bring the change in block functionality more to users attention - as it will reduce the number of calls to tech support.   But once you know, you know.

a

We do mostly "Go-shows" with an occasional fund raiser musical tribute show, which is marginally rehearsed.  Anybody who's used movers knows how ugly a "GOTO CUE" transition can be, so I want to be able to preprogram safe entry points for each act and be able to remember how I did it for the next time.  I want to be able to reorder the show with links and use an MC cue on a separate fader.

Each top of Act needs the following elements

1. A mark cue to invoke auto mark for the main look.  Only the movers needed in the next cue have hard moves or are block/asserted at zero, everything else tracks.  Replacing the track values with nulls may be necessary if the mark cue needs to be reasserted (as of v 1.4.5)

2. main look part 1... all intensities blocked/asserted. This has to been done in blind with the syntax <CLEAR> INTENSITY BLOCK <ENTER> INTENSITY ASSERT <ENTER> . for some reason the parser chokes if the cue # is on the command line.

3.main look part 2... delays until part 1 fades to zero. all NIPs blocked/asserted. Syntax <CLEAR> FOCUS COLOR BEAM BLOCK <ENTER> FOCUS COLOR BEAM ASSERT <ENTER>.  As acts are recorded out of order, and blocks are converted to moves, I want the move to happen here.  If the console had an "AUTO HOLD" feature , where movers fading to zero had their moves delayed (fading to 1% or higher  would be a live move), this part would be unnecessary.

I prefer to use a part 2 instead of a follow cue because as lights are added to the main look and updated to part 1, they are automatically removed from part 2.

It should be noted here that the system allows me to use a global "B" setting, and pull the blocks into different parts using parameter ASSERT flags, but playback doesn't respect this, which is really my general complaint, playback ignoring what I created.

This setup works well bouncing to/from an MC cue on another fader, and it minimizes cleanup when acts are written out of order.

The only remaining issue is reordering the sequence with links.  If my act2 is stuck on the freeway, I want the transition from the end of act 1 to the mark cue for act 3 to look like there never was an act 2.  Currently the GOTO CUE behavior of LINK TO CUE will bring up the tracking values from the end of act 2 as well.

My wish is that in some version (1.7?), given that you can put ASSERT flags on almost everything, a toggle switch is added to show setup with the following values for LINK TO CUE/LOAD CUE transitions: ASSERT FULL or ASSERT FLAGS ONLY.  With ASSERT FULL the default, this should be backwards compatible with older 1.4.x versions.

In the meantime. My options are:

1. Delete Act 2 cues tracking.  What if act2 shows up backstage?

2. Copy the end of act 1 to just before the act 3 mark cue. Ok if there aren't any last minute edits that need to be duplicated.

3. If act 2 shows up and I need to transition to it without using LOAD CUE, the best option seems to be to move act 2 cues into its own cue list.  The mark cue will be trash since tracking values convert to hard moves, so it will need editing.

For this kind of show, I'd definitely recommend using separate cue lists for each act.

It makes your show file much cleaner, as it's always immediately obvious to you which cues belong to a given act, and it's much easier to keep track of your 'preset' cues.

It also gives you the option of putting each act onto its own fader, which may make life easier for you.

Finally, it makes it much easier to do your 'top of act' cleanups, as you just Assert the entire cuelist rather than trying to work out which channels should be Asserted.

This is the method I used when I programmed Hog IIs - unfortunately I've not had the opportunity to do this kind of show on an Eos, but the principles are exactly the same.

Finally, if you use a Preset to hold the 'MC Look' then you can have a cue using this Preset at the top of every Act, and even safely Assert that cuelist the moment it's announced, before the act actually begins - thus lights not used in the MC look can pre-emptively Mark themselves.

- To update the MC look, just update that single Preset and that will propagate across all your cuelists.

Richard,

I thought with hogs you could force other parameters into a palette, making it like a eos preset? (note: responding to deleted statement above)

Anyway, the mulifader option is interesting, although here they call shows as one numercal sequence, even the slap together stuff.  For a lot of people, LDs and department heads included,multifaders is too much voodoo.

In the context I'm using ASSERT, it is with global commands, not one channel at a time.  Unfortunately, the block/assert combo is necessary to affect NIP timing in a block Q.  Many a time an LD has had me put a global block on a downstream blackout Q, and when we get to it, the movers flyaway because tracking edits have converted blocks to moves.  So maybe an "AUTOHOLD" feature like I suggest would apply only to global block cues, thus saving me the trouble of building safety net cues.

So to get back to my original post.  Here we are in 2009. I'm watching  full screen video on my PC thru phone lines. I have a wireless phone the size of a pack of gum. So why am I confronted with the same issues on my new "moving light" board with the 70+ Megabyte software package, that I was having with the strand 530 (MSDOS based two floppy OS) console.  Why do I have more user options with a free internet browser that I do with a top dollar console package?

If they're going to ignore me on this point, the least they could do is assign macro numbers to the unused keys on the keyboard, so we can at least get our money's worth out of them.

I'm a little hesistant to respond to this thread - but......

It seems to me that for your out of order music shows, the multiple Q list thing actually hurts you becuase you have a lovely safe entry/exit point in your standardized MC Q.  If you create your MC Q as 2 Q's - the first is a Clean up INT block/RGB-CMY Color Shift, which follows to the second which would be a traditional full block.  If you Restrict your Buttons a bit and your MC Q to CMY, RBG, Conv. etc your exit is pretty clean by default.

= THEN =

When you link around you link first MC look to  the second MC Q Preceeding your musical act.  Now you have your marks, etc.  Again pretty clean by design.

Since your Second MC Q is your Full Block you wont have to worry about tracking through, and if you standardize your Q numbering it's not hard to keep track of where to go (you're always linking to 20, 30, 40, 50, 60, etc.)

As an added bonus you keep more of your piano open for live effects - if your into that kinda thing.'

Obviously the larger your gear list, the easier it is to be restrictive for your MC Q and musical buttons, but still......  The huge downside of Asserting other Q lists (other than real estate) is that it will never pay attention to what's happening in front or behind it.

Patrick,

I'm just glad your not writing to tell me that I could split the timing on a block cue by just putting a DELAY on the FCB times. 

Anyway, I'm not sure if you're saying the MC Q is being linked to/from in the same cuelist, but if I were to go by your first sentence, I would assume yes.

Of course, everybody INTENDS to run their show as rehearsed, but stuff happens.  Like, for instance, one act is supposed to introduce the next act, (No MC Q needed of course), but they forget and walk off.  Therefore my use of the term MC Q refers to a safety cuelist on a second fader (followspots don't hurt either).

Quote ""When you link around you link first MC look to  the second MC Q Preceeding your musical act.  Now you have your marks, etc""

I think we agree that a safe entry point requires some sort of full block spread across 2 cues.  But whether linking to them directly works depends on what you want your transition to accomplish;

You want the first cue to be safe transitions that cover for movers marking for the second cue (auto-follow).  I'll call this a movers-lagging transition, OR...

You want the movers to sneak out in the first cue and mark so the whole rig can transition in the second cue. Call this a movers-leading transition.

At first I was going to say that linking would be no trouble in the first instance.  But since linking always ASSERTs tracking levels, even if it's linked to the next cue in sequence, the fact that you only block the intensities in the first Q makes no difference.  if FCB parameters don't match where you're coming from they will move, tracking or not.  You will need to put delays on the FCB times to handle this. 

Even worse in the second instance, since the tracking info in the first cue is probably junk you don't want ASSERTed.

Hopefully, neither of us is relying on AUTOMARK to help since currently it doesn't read thru links.  It also only works on the active cuelist (the one you just hit Go on), so I wonder why its a global setting instead of a cuelist option (comments invited)?

The only way so far as I know to fire a cue out of sequence and prevent tracking info from asserting is to put that cue in another cuelist.  The first cue in any cuelist has no tracking levels, so problem solved there.  We can put our pair of MC Q's in a loop so hitting GO on that fader always brings up the MC Q complete. If you set the fader to I-master, you can pull it down before you hit go and get a blackout that marks (as opposed to just bringing down the Grand Master).

The use of the ASSERT flag is simply to get control back to my main cuelist, with this two fader strategy.  This also applies if the MC look is in a sub that grabs FCB paramters or is set LTP.  I think the rule should be BLOCK for knowns (ie previous cues in the list) and ASSERT for unknowns (other sources ie faders, subs, manual values).

I have some ideas to make eos more idiot proof than a strand 530 which I may entitle "What do you want in EOS 2.0 (whether ETC agrees or not)" in another thread,  unless you want to post it?

Obviously my post isn't intended to address any technical issues - and in truth isn't meant to specifically address your situation.   I'm not there so I dont really know, and you got a good handle on it.    There's a lot of different level of user here though and it's a fairly common show type, so I figured it was appropriate to highjack your thread :-)

(EOS 2.0 thread good idea - leave that second part out - I'd wait until 1.5 hits the street).....

If it were me - I'd pull the Generics into the main Q stack for 3 reasons.  

First -  if we can restrict our gear selection so that our first generic Q cleans up our music button and our second Fully Blocks and Marks for our next act, and we have this sequence in between each act - then we can link any Generic Q 1 to any Generic Q 2 and play our show in any order.  They look the same to the eye - so asserting a full block at this point doesn't hurt us.   

Second - the Mark function on this desk requires a reference by definition (which - if I read it correctly - is the original concern of the post). Asserting a seperate Q list is always going to take things out of context, so we'll have a lot less confidence in hitting that button. 

Third - I always want more piano.  Usually in this situation I'll have an act or two that I'm scoring without any rehearsal, never even heard the track. If I care enough to do a true mutli stack live score - every fader counts.

But really I want to provide a counter argument to the idea that running separate cue lists for 20+ acts in an under rehearsed live live show is always the best way to go - or even practical.  I can create and copy paste the cuelist below in a single stack way faster than trying to manage multistack.   And by standardizing my cue numbers I can actually get to where I want to be faster too.   I constantly hear that running single stack or Cue Only or putting a Full Block in almost every Q are stategies solely for the weak and it's just not the case.  For my cookie cutter variety shows it's really the best way to go - regardless of how large the gear list is.    (Rant done :-)

The Q list below builds out in minutes, and since each musical act has it's own header/footer there's room for custom stuff in the generics.

Q 10 Generic 2 (Full Block) Restricted to RGB/CMY/Dimming. Mark inactive here. Put Macro Fader Page swaps here. 

Q 11 First Music (M)

Q 19 Button (Music Ends) Restrict to gear that doesn't need to mark for the Generic.

Q 19.9 Generic 1 (M) (INT Block only)

______________________________LINK TO ANY -0 Q_________________________

Q 20 Generic 2 (Full Block) See above

Q 21 First Music

Q 29 Button

Q 29.9 Generic 1

An interesting point of view, and definitely one way to do this - but I completely disagree.

I wouldn't call the single-stack approach a 'strategy for the weak' - it's just the method you've been forced into using by the consoles you had previously. If you only have one quickly-accessible cuelist, then it is essentially the only way to do this kind of show.

But what you've really been doing is working around the single-stack limitation of your previous consoles, by inventing your own sub-stacks.

This is why:

By using 'specific' cue numbers, you're automatically limiting yourself. Do you need 10 cues per act? 50? 100 cues? It's unknown when building the framework, so you've got to leave 'lots' of space and hope it's enough. In your example, the moment you need more than 9 cues for the act you must use point cues. Life gets hard when you need more than around 20-30 cues for an act due to running out of point cues in the right place.

If you take your framework and stick it into multiple cuelists, you get this:

• Q x/1 Generic 2 (Full Block, Full Assert*) Restricted to RGB/CMY/Dimming. Mark inactive here. Put Macro Fader Page swaps here. 
• Q x/2 First Music (M)
• Q x/900 Button (Music Ends) Restrict to gear that doesn't need to mark for the Generic.
  • I picked 900 because you're unlikely to need more than 8,999 cues for an act, but you can easily renumber these 'cleanup' cues to get more/less space for the act without making any changes to the show. I also don't like using point cues unless I *have* to.
• Q x/901 Generic 1 (M) (INT Block only)
  • Optionally link to cue y/1, to automatically link into the next act.

These cuelists live in 'limbo' if you want to keep the faders free, just being linked or manually loaded into the Main Playback (simply using Goto Cue) as the show progresses.
* The Full Assert is there in case you later decide to use them on seperate faders. If you're not going to, then it's not required.

To create a new Act, just copy cues 1,2, 900 and 901 into a new cuelist and label that cuelist accordingly.

The final result is actually identical to what you described above, but you've removed the limitation of having to 'guess' how many cues you'll need for a the acts.
On top of that, you can record each act using [Record] [Cue] [Next], rather than needing to remember to 'fill in' using point cues if an act will need more than 9 cues - thus it's faster to program.

Because you can label the cuelists and see them in the list of cuelists, it's no longer a big deal if your cribsheet goes missing. It's also much easier to hand the show to an operator or revisit it months later, because it's partially self-documented.

Finally, just because you could put these cuelists onto faders, doesn't mean that you have to - you can treat multiple cuelists as being one, really big cuelist by linking them end-to-end in the Main Playback or using [Goto Cue] [#] [/] [1].

Thus your playback is completely unchanged, but your show maintenance and programming is simplified.

With respect to cue numbering strategies, on this console you can insert up to 99 cues between cue 1 and cue 2,etc, which gives you more wiggle room.

The intent of my original post was to suggest that the computing power of the console is being underutilized, with respect to preventing unintended movement.

For example, after every cue edit the console searches for auto mark opportunities, and if found , the previous cue is marked “M”. Why can’t other live moves be indicated on the playback status display?　

Quote “How does the console know which lights should "Blackout, move, come up" and which should "Move across the stage while still on"?

We should be able to set a cue level flag to indicate our intentions to the console to not allow our movers to move for this particular cue. This would allow the console to use delays, edit confirmations etc to enforce our intentions.

This is more of a 2.0 kind of discussion.

Hi Richard, 

Absolutely love a good debate.  Thanks for entering it.

Totally agree the scenario above yeilds very similar results, and I can appreciate that different things work for different people.  I would counter a couple points -

1) Your assumption that I'm an 02 programmer is a little premature - I never found the Hog to be limited to a single stack :-)  I do however find it limited in workflow management tools for large scale shows which the EOS handles extremely well.  Also - I absolutely love true spread sheet effects for music - so I'm ETC all the way - Hoorah.

2) Q's 20-30 have 1000 available Q's in between them.  I use a highly specific numbering system and single stack or not would encourage anyone to do so as well.   Q 22.05 is almost always going to be the 1st chorus for the second Artist running a ".5" style effect - So there's never any guessing - the song numbers itself, I just choose what parts to use.  Record next just encourages people to pay less attention to the numbering which has inherent risks.

3) If you really do have 20+ cuelists you can never really get rid of that crib sheet in Live.  You still need to pick out a cuelist number sometime and the Blind Cuelist Display isn't very user freindly.  Even in 1.5 after 9 lists you got to pick up the mouse to scroll down to see the numbers/labels - and then to edit that list in blind you gotta type in the list number in order to populate the cuelist.  

Since it's a theatrical console at heart the EOS handles long primary lists very very well - I can next through my cues from live or blind. It's all right there to be edited already.

4) Since I run a lot of other faders I wouldn't want to have a global block/assert on one of the little go buttons - it  just invites disaster.

5) I dont particularly like running Q's from the execute line (there's a bit of a lag time and order in which things are fired can have implications to LTP objects)

I find Goto Q in a live live show leads to problems.  Even with the O2 keys on the Eos - typing mistakes are just a part of life.  The moment you hit enter on a goto command, your done.   [Blind] [Link] [#] [Enter] has a few more key strokes, but the link auto-posts (if the link line was previously blank), and I get a chance to look at it a couple times before I hit Go.

6) With Multi Stack I'm much less likely to be able to see what's coming up, which can be a real problem.  These are often times 1 or 2  day shows, rehearsed out of order with no dress.

7) With multi stack at some point you need to stitch it together, by whatever method.   No matter how you look at it - it's just something else to do.

8) As before - mark always requires a reference so if you Assert other lists you always have to manually make sure your clean.

9) From top to bottom this desk has been designed and advised by pure traditional theatre folk.  I spend a lot of time swimming upstream with this console - for all the reasons above I find this issue not worth fighting. 

Again - I totally appreciate the debate.  No one ever really discusses work flow related issues and I think it's a very healthy discussion to have.  

If you can get a rock solid handle on the cue numbering, the benefits of a single main Q list on this console can be  very real.  It's less stuff to manage, fewer screens to look at,  stitches itself together automatically, has superior display attributes during playback and your mistakes are less likely to be catastrophic because your asserting less out of context.

1) You got me there!

2) I'm quite used to building a framework that other people have to fit their parts of the show into - so I try to make it hard for them to mess it up. As long as they stick inside their designated cuelist(s), they won't break the show. As integrator, I just have to check the top-and-tail of the cuelist.

3) Yes, you'll probably need a cribsheet regardless, but it's much easier to rebuild that cribsheet if it's all in one list on the console.

4) Remember that you can link the last cue of Cuelist 1 to the first of Cuelist 2 instead of putting them on multiple physical or virtual faders. I don't think you could do that on Hogs (been a long time since I used one). So there's no need to have the extra cuelists on faders if you don't want to.

5) Yup, you're right there. Goto Cue is an 'emergency' thing - which is why i like them to be as obvious as possible. In this kind of show, you're doing it because the running order changed unexpectedly - otherwise you're linking one act to another (either cuelist to cuelist or cue to cue).

6-8) Hmm - I tend to think in terms of single acts that I'm stitch together, rather than a whole show broken into parts. Many of the Variety shows I've done didn't have a running order, or the running order changed every night with acts joining and leaving, and many of the other shows of this general type have been

That's probably some of the reasons why I approach this from the other angle.

9) Yes, Eos and Ion were designed from the ground up to be excellent theatre and opera consoles - this kind of 'live', seat-of-the-pants stuff is more what Congo was aimed at. The core strengths of the two families are quite different, while they do almost fully overlap in capabilites.

Quote:

We should be able to set a cue level flag to indicate our intentions to the console to not allow our movers to move for this particular cue. This would allow the console to use delays, edit confirmations etc to enforce our intentions.

I don't understand. You appear to be saying "I want to tag a cue to say that movers must not move. Thus when I goto it, it does not actually play back but leaves the movers pointing in a random direction and in a random colour". Is that right, or do you mean "The console refuses to let me Goto that cue"?

What do you mean? Can you give examples?

To be honest, It really feels like you're after a "Do What I Mean" function, which sadly isn't going to happen. It is just a computer after all.