Auto blocks . . .

Hello?  Anyone?  Yes? No? Maybe?  Is this thing on?  Check 1 . . . 2 . . . 3 . . .

Just guess I'm not used to nothing but silence in reply . . . especially on what is a very real issue for this user!

- Tim

We are adding an auto-block clean up function in an upcoming release.  We've not heard other reports of any of the behavior your describe.  As Luke said, if you can help us try to to find a duplicator, that would be great.  

thanks,

a

We had a very simple (20 cues or so) show that seemed to do it if you even looked at it funny . . . let me see if that still exists, and if I can create a command sequence that will trigger the problem . . . It may take me a week or so, but I will definitely see what I can create . . .

- Tim

Ok that would be great.  Just to clarify for those who may not fully understand, an auto-block is created whenever a channel that was previously a move instruction is matched in level is a preceding cue.

So, if cue 10 sets channel 1 to 50% (it is a move, displayed in either green or blue, depending on direction of travel), and you later go to, let say, cue 9, can set channel 1 to 50%, it will become auto-blocked in cue 10.   The desk maintains the concept of the move, even though it is no longer a move.  It's a data protection device. 

a

Anne -

We took this console to 1.9, and I was still able to create a scenario where a cue stack will go completely dead following an automatically generated block. 

Please refresh my memory as to how you want stuff uploaded, and I'll get his small snipped (10 channels, 10 cues . . .) uploaded so that you can tell me if we are just plain nuts, or if there really is a bug behind this . . .

Thanks,

- Tim

You can send the file directly to me.

matt.kerr@etcconnect.com 

I would love to take a look at this. 

Matt

Thanks Matt.  You know where to find us when you see what you see.

a

I have also many problems with the AutoBlock functionality. I work in CueOnly Mode, and the autoblock

turns realy crazy. After a programming session with many works with Recall, copying cues and channels,

and Tracksheet operations, my Cuelist is full off Blocks and it needs much time to put them out (cause it

brings some problem with the AutoMark).

I think that Autoblock is not a conceptional feature for use in CueOnlyMode (I know EOS is trackingconsole, but ..).

Please make it possible to switch it off in the Setup, or ... make it more intelligent.

Stefan Staub 

The rules for auto-block are pretty simple.  We can't really make it "more intelligent" as we don't know what your intent is when data is copied.  

.... we are adding a channel level move instruction that will decrease the number of times autoblocks occur.

Hope that helps.

a

Anne,

One thing that needs improving is preventing Autoblocks inside of of Full block cues.  They have no underscore, but show up as move instructions when using syntax like "Query Is in Cue 2".  More specifically, after cleaning up all the baby blocks we use commands like "Query Isn't In Cue 1 Thru 200" to find the unused channels so we can remove them from the final show file.  Some channels will have moves in the hard blocked cues even though they never get above zero, so they won't show up in our "query".  Toggling the Block parameter removes the autoblock but it would be better if they weren't created in the first place.

Anne,

One thing that needs improving is preventing Autoblocks inside of of Full block cues.  They have no underscore, but show up as move instructions when using syntax like "Query Is in Cue 2".  More specifically, after cleaning up all the baby blocks we use commands like "Query Isn't In Cue 1 Thru 200" to find the unused channels so we can remove them from the final show file.  Some channels will have moves in the hard blocked cues even though they never get above zero, so they won't show up in our "query".  Toggling the Block parameter removes the autoblock but it would be better if they weren't created in the first place.

Autoblocks don't happen with full block cues.  If you block a cue, and one of the move instructions in that cue is later matched upstream, the value is converted to a block, since you blocked that cue.   It is no different than when the block flag is first applied.  Any channel stored in a cue, even at zero, is considered used in that cue.  There is a huge difference between not used and stored at zero - this is the engine that facilitates the use of multiple cue lists.  What you are looking for is a query that asks for lights not above zero.  That is being added.  In our next release, we are also adding a channel list of channels that are never stored above zero to the utility reports.

As to whether auto-blocks are created or not.... this is a huge jump ball.  You either love them or hate them.  And that is why we are adding an autoblock cleanup function in the next release.

Thanks,

a

I have version 1.9 in front of me. In my hardblocked (B) blackout cue 2 one of the white zeros is in the cue (according to the query) while the rest are not.  I know the reason is because I toggled that channel's level in the previous cue, which created a move to zero in cue 2, which was then left there after I toggled back.

All those new features will be much appreciated. 

Interesting.... completely not seeing that.  There is an issue with query at zero collecting null channels... that's being fixed in the next release.  Can you send me your showfile?  anne.valentino@etcconnect.com.

Thanks much!

a

It's easy to recreate, in fact its hard not to.

New Show File:

create channel 1 thru whatever as dimmers

Blind Cue 1: All channels at zero (blue)

Blind Cue 2: Hardblock(B) : All channels are white

Query Is in Cue 2 <Enter>  returns Error: Channel LIst Empty

Blind Cue 1:Take Channel 1 to Full <Enter>. Now take it Out

Blind Cue 2:

Query Is in Cue 2 <Enter>  returns  Channel 1 selected

The question to ask the software engineers is if a hard move to zero (green) in a Full Blocked Cue becomes redundant (autoblock), do they bother to erase it?  My observation is that autoblocks are only erased when the block flag is toggled, or when @ <enter> 'd by the user.

The only thing that makes this an issue is that the display function that paints all channels white seem to take precedence over the underscore symbol.

Ok... while we look at this, can you tell me why you store a cue with all channels at zero?  (cue 1).  Purpose?  Not there is anything wrong with it, but I'm interested to know why.  Since full blocks take care of any channel additions downstream... 

The first time we used muliple cue lists, there seemed to be an issue with newly created channels updating and autoplaying when first applied.  We decided the first cue in each cuelist should have a hard value for channels it intends to control so as to eliminate ambiguity, so our main cuelist usually starts with a cue 0.5 with hard zeros and all NPs in preset 1 as I don't like plus signs on the channel summary page. 

I observe with 1.9 a new unowned channel will want to update into the last cue played back.

Yes. in 1.9, unowned channels update to the selected cue list.

"The question to ask the software engineers is if a hard move to zero (green) in a Full Blocked Cue becomes redundant (autoblock), do they bother to erase it?  My observation is that autoblocks are only erased when the block flag is toggled, or when @ <enter> 'd by the user." --

If you have a cue with a channel moved to zero (green) and the cue is blocked - and you match that move in an earlier cue, the move to zero becomes blocked.  I don't know what you mean "bother to erase it."    

Yes, blocks and autoblocks are only lifted by toggling the block flag or at entering the channel.    Blocks and autoblocks are handled exactly the same way.  The only difference between them is that you asked for the block and the system applies the autoblock.  Again, the channel in this instance is not autoblocked, it is blocked because the cue has a block flag.

I only keep bringing this point up because when we add the autoblock clear utility, it is important to understand which blocks will be removed and which won't.  If it doesn't have an underscore... it isn't autoblocked.

There is something pooched in the query cue command ... (sorry, I was trying the query at a specific level earlier).... working through it now.

a

By "erase it" I mean't the actual move to zero".  When I "@< Enter>"  channel 1 in blind cue 2 the hidden move is erased, altering the query result. This tells me there was discreet data as well as the global block flag being applied.

You will have to fix the usage report as well since the hidden moves show up there also.

When you say "automatically by the system", it seems to me that block channels are  natural to a tracking board, all channels that have a move are by definition also  "blocked", and all blocks are requested, one way or another, by the user.  You can call a redundant move a fancy name like "autoblock" for the sales department, but the system didn't really have to do anything to creat it.

The fact that when a move becomes redundant, it loses its affect on playback, is where EOS deviates from other consoles.

It is clearly evident that when I edit a cue, EOS processes the entire cue list, looking for levels to declare "autoblocked", and filling the PSD with "b" s.  If a new "autoblock" is found in a cue that is already a "B" cue, what happens then?  Is the discreet data removed? I think not .... at this time.

As I have mentioned, there is an issue with querying cues.  It is related to what it means to be in the cue.  So, for the moment, it would be useful if we could leave the query discussion out of this.  Yes, there is an issue.  And yes, we will fix it.

Blocks are not move instructions, they are editing tools.  Asserts are move instructions.  There has been quite a bit of dialogue on these forums about this.   And yes, we do differ from other tracking consoles in this.  

Yes, when you edit a cue, Eos processes the cue list to see if autoblocks are needed.  It also processes the cue list to see if the change should result in a track or a move.    I have said this before, and will say it one more time.  If a cue is blocked, any move instruction that is matched in level in an earlier cue will become blocked.  It is not an autoblock.  It it caused by the fact that the cue has a block flag.  Discrete data is not removed. 

This discussion could go on for years with no satisfying results on either end.  I would suggest that you contact either David Hilton or Lowell Olcott in our LA office..  Again, leaving query out of it, please tell them what your issue is.  Please show it to them.  They will interpret and let me know if we have an actual problem.

 look forward to hearing back from David or Lowell.

thanks much,

a