• State Suggested Answer
  • Date
    Archi
  • Date
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 187 subscribers
  • Views 55 views
  • Users 0 members are here

Potential bug : Uncleanable Auto-block created by manual marking

Hi Hivemind !

I was "translating" an auto-marked show into a manual marked one and I've ran into an issue. After finishing creating all my marks, I notice some cues had channels with the auto-block appearance in the channel display (white underscored values).

However, the Auto-block doesn't show in the PSD, the channels aren't selected when Queried Auto-block, and the blocked values aren't removed when Auto-block Clean is used.

I then realized that these blocks appear when I try to mark channels that have some parameters moving but not all. For example, a channel has Live-moves in Focus and Beam, but not Color. If I mark it (I tested Earliest, Earliest M, and a specific Cue), the Color parameter will be auto-blocked. I am then left with a ton of autoblocks that I can't clean in any way except manually selecting then At-Entering them.

Is this expected behavior (and if so I don't like it), or a bug with Eos, or a bug with my software ?

THANK YOU FOR YOUR ATTENTION TO THIS MATTER.

Version information : This was first found on v3.3.1, and was then replicated in 3.3.3 Build 10. 

Following are screenshots of the damned values and the absent autoblock flag

This next one is particularly annoying because the auto-blocks are the only Live-moves in the cue, so Eos wants me to create a mark when it isn't necessary

Parents
  • 0

    This is expected behavior. And while they do look like the autoblocks you're familiar with and while they're a kind of automatically created blocks, they don't fall in the regular category of autoblocks.

    The reason for the blocks you're encountering is to protect the references of marking changes against tracking.

    In your screenshot let's look at channel 99. The M says that this is the reference cue and there's an earlier cue that marks the color to make sure that when you fade in in this cue you're already in the right color. If the channel had a different color earlier you would see CP 30 in green because it'd be a move instruction that is being used to mark. In your case however channel 99 already was in this color, which means we would typically expect CP 30 to be written in magenta. But referenced marking aims to protect the marking values in the R-cue against tracking. So the values must not be written in magenta. In the first case (where channel 99 previously had a different color) we don't need additional protection, since the color isn't written in magenta and protected against tracking anyway. But in the second case (the channel had previously already been in CP 30) the console needs to find a way of not using magenta font for channel's 99 color (which is exposed to tracking). And this way is to use white font.

    To summarize: Only white underlined values accompanied by a b in the PSD are the autoblocks you can clean. The others are essential for referenced marking to behave as intended and can't be cleaned up.

    If you still think there's a bug at play you can of course send us your showfile to eos(dot)moderator(at)etcconnect(dot)com and we'll take a look.

Reply
  • 0

    This is expected behavior. And while they do look like the autoblocks you're familiar with and while they're a kind of automatically created blocks, they don't fall in the regular category of autoblocks.

    The reason for the blocks you're encountering is to protect the references of marking changes against tracking.

    In your screenshot let's look at channel 99. The M says that this is the reference cue and there's an earlier cue that marks the color to make sure that when you fade in in this cue you're already in the right color. If the channel had a different color earlier you would see CP 30 in green because it'd be a move instruction that is being used to mark. In your case however channel 99 already was in this color, which means we would typically expect CP 30 to be written in magenta. But referenced marking aims to protect the marking values in the R-cue against tracking. So the values must not be written in magenta. In the first case (where channel 99 previously had a different color) we don't need additional protection, since the color isn't written in magenta and protected against tracking anyway. But in the second case (the channel had previously already been in CP 30) the console needs to find a way of not using magenta font for channel's 99 color (which is exposed to tracking). And this way is to use white font.

    To summarize: Only white underlined values accompanied by a b in the PSD are the autoblocks you can clean. The others are essential for referenced marking to behave as intended and can't be cleaned up.

    If you still think there's a bug at play you can of course send us your showfile to eos(dot)moderator(at)etcconnect(dot)com and we'll take a look.

Children
No Data
Related

www.etcconnect.com