• Date
    Kelvin Leung
  • Date
  • Replies 16 replies
  • Subscribers 183 subscribers
  • Views 31430 views
  • Users 0 members are here

How to assign particular channels in grandmaster for a show?

 

I would like to know how to specify channels to be controlled in grandmaster.

Apart from that" Does anyone have a practical list of commands for executing a " Assert Cue " in cue list?

Thanks

Kelvin

Parents
  • Hey Kelvin.  At this particular time, you can't assign just specific channels to your Grand Master.  That will be added in the near future though.  It's part of the implementation of fader displays (to isolate the stage view down to just what that particular fader is contributing to the output) and assigning filter states to faders.

    Regarding assert - I'm assuming you mean "What the heck is this feature for."  ??

    One of the sticky things in a multiple cue list/multiple playback fader desk is cue list ownership.  Who is talking to a channel parameter (therefore, who "owns" that guy) and how is that ownership traded off.   Eos is a move fade desk - by default.  So channel parameters only respond to move instructions, not tracked data.  This is how ownership is established.  So, let's say you have two cue lists.  In Cue List 1, channel 1 is set to full in cue 1.   It tracks forward until you get to cue 20, and there you move him to 50%.  In Cue List 2, Cue 1, you have a value for channel 1 at 25%.  So you playback Cue 1/1, and advance to cue 1/4.  Channel 1 is at Full, tracked.  You execute 2/1.  He moves to 25%.  You hit go for 1/5.  He is going to stay at 25%, because the value for channel 1 in Cue 1/5 is a tracked instruction.  Assert is a way to say to that tracked value, "You should come back and do this now."    Why does this matter?

    Let's say you have a base look for your cyc in cue list 1 (your main cue list).  At various points during the show, you are going to need to do (let's say) a sunrise.  You decide to do that on a second cue list, because you'll use it several times.  That also allows you to set your base look up in the first cue you need it, it tracks through the whole show, so when you need to change it, you only have to change it in that first cue.  So you run the second cue list.  At the point in the show that you need to return to the base look, you "assert" those channels.  This returns control to the main cue list.   Does that kind of make sense?

    Assert can be placed on a cue, a cue part, a channel or a channel parameter.  It is sort of like a block, which takes a tracked value and treats it like a move instruction.  But an assert will basically treat a tracked channel like a move instruction for playback, but allows it to continue to be edited like a track.

    It is placed and removed on a cue or cue part just like all other cue attributes.... [Cue] [n] [Assert] [Enter] places it; the same action removes it.  When an entire cue or cue part is asserted, you see an "A" in the flag field of the cue.   To place it on a channel or channel parameter, you:
    [Channel selection] [Assert] [Enter] or [channel selection] [parameter selection] [Assert] [Enter].  When this is done in live, you'll see a red "a" next to the channel/parameter you've placed the assert on.  You need to store or update the cue/cue part.   Once stored, you'll see a blue "a' indicating that channel/parameter will be replayed on an in-sequence [Go].  Also, a lower case "a' is shown in the flags field of a partially asserted cue.

    Does that help?  There is a thread somewhere else here that gives more examples of how assert is used.

    Thanks much!

    Anne



    [edited by: Anne Valentino at 11:54 AM (GMT -6) on Fri, Aug 03 2007] [edited by: Anne Valentino at 11:52 AM (GMT -6) on Fri, Aug 03 2007]
  • in reply to Anne Valentino

    Anne~

    After reading your response...

     
    "Assert can be placed on a cue, a cue part, a channel or a channel parameter.  It is sort of like a block, which takes a tracked value and treats it like a move instruction.  But an assert will basically treat a tracked channel like a move instruction for playback, but allows it to continue to be edited like a track."

    Is it possible to be able to place an "assert" on an entire cuelist?  Or even better in future be able to possibly assign "priorities" to cuelists... so whenever a higher priority cuelist is played it will "stomp" another cuelist.

     M



     

  • in reply to MacStgTek
    Matthew --- 

    It is on our list to apply "assert" to a cue list.  Right now though, you can place a cue list on "independent."  (As you can a submaster BTW).  So, something controlled by an independent playback cannot be controlled by any other playback - unless independent is released.  It's sort of like the priority states on a Hog.   It is important to note that independent status is equally shared .... there is no "independent hierarchy."  

    Assert on a cue list means that all values are replayed.  Independent means that no other values can be applied.  They are similar, but different.  Did David go through the Null features on Eos with you?  They are sort of like channel level filters.  This is the way you can remove stuff from a cue in a cue list... so, depending on how much you are busking or how much you plan ahead.... there are a variety of different ways to manage cue list ownership.

    Make sense???

    a

  • in reply to Anne Valentino

    Anne~

     Thanks for the response.....

    Yes, Null values make sense.... record "remove" has always been a favorite when operating tracking consoles.  In fact is "@ enter" the only way to make something a 'null" value?? 

    Regarding Assert.... I, understand the functionality, however coming from a primarily moving light background, it isnt the "norm" how other consoles react, i'd want the ability to "assert" the cuelist, so that no matter when I ran this cue list.... everything would come back here.... 

    Dont, get me wrong.... Its a very powerful feature, you're definitley taking Hard values, Tracked Values, and Lack of Value to an Entirely new level.  Its definitely the right way to go about it, just lemme make it operate the other way as well......

     Many thanks.

    M

     



    [edited by: MacStgTek at 9:54 PM (GMT -6) on Wed, Aug 08 2007]
  • in reply to MacStgTek
    We've actually been having a lot of discussion here about nulls and filters (basically the same thing).   Let me give a little background.

    On Eos, anytime you do a selective store (channels n thru x record) or ( - intensity record) to an existing record target, we treat that as a merge function, not as a replace function.    So, if it is a positive selective store (channel 3 record cue 5 enter), we are saying add the current values for channel 3 to cue 5.  If you construct a negative selection (- focus record preset 2), you are ignoring the current focus data.  If that record target already has focus data, that data is maintained.  

    When we originally implemented nulls and filters, we treated the application of them as a "remove", not as an "ignore."  We subsequently changed it so that the rule set was the same as all other selective storing commands - because for all intents and purposes, it IS a selective store.   Does that make sense so far when rerecording existing targets (whether you agree or not, Mr. M..... well, we will get to that in a minute).

    If you are recording a new target, (if not a cue), the nulls and filters will withhold the data from the target.  A little trickier with cues, because this is a tracking desk (and we are treating nulls/filters as an "ignore" condition).  So, if you have a null flag on channel 1 intensity, if channel 1 intensity is not part of the preceeding cue, it will be completely withheld.  If channel 1 intensity is in the preceededing cue, the current value will be ignored, and channel 1 intensity from that cue tracked into the new cue.

    So, to Remove something from a cue completely, you go to Blind and put a null on it.  If you say @ Enter, you are just going to allow the previous value to track in.  In non-cue record targets, you can use either the @ enter command or the null command to remove it.

    We have specified syntax that we've not yet implemented that would allow you to:
    [Intensity] [Delete] [Preset] [1] [thru] [9] [Enter] - for example.  So, you'll be able to remove stuff without going to blind, but it won't be via the filters.  It is worth noting though, that on cues, you'd be deleting the move instructions, allowing tracked values to enter the record target(s) specified.  And you'd need to be sure to append the [Cue Only/Track] instruction as necessary.   If you want to remove the channel/parameters from the cue ..... blind/null is going to be the way to do that.

    Ok, so that's were it stands today.    I brought this topic up for discussion again after you and David worked together in the LA office.    I've spoken to two other programmers who've used Eos on a show and they seemed to feel that the way it is working now is the most consistent and easily understood.    Using filters on tracking desks gets a little tricky.... and I think we need to have the same rule set regardless of the tracked or non-tracked nature of the record target (cues vs presets, for example).

    Let the open discussion begin!  And I'm gonna get on my homework assignment post haste!!

    :)

    Anne



    [edited by: Anne Valentino at 11:05 AM (GMT -6) on Thu, Aug 09 2007]
Reply
  • in reply to MacStgTek
    We've actually been having a lot of discussion here about nulls and filters (basically the same thing).   Let me give a little background.

    On Eos, anytime you do a selective store (channels n thru x record) or ( - intensity record) to an existing record target, we treat that as a merge function, not as a replace function.    So, if it is a positive selective store (channel 3 record cue 5 enter), we are saying add the current values for channel 3 to cue 5.  If you construct a negative selection (- focus record preset 2), you are ignoring the current focus data.  If that record target already has focus data, that data is maintained.  

    When we originally implemented nulls and filters, we treated the application of them as a "remove", not as an "ignore."  We subsequently changed it so that the rule set was the same as all other selective storing commands - because for all intents and purposes, it IS a selective store.   Does that make sense so far when rerecording existing targets (whether you agree or not, Mr. M..... well, we will get to that in a minute).

    If you are recording a new target, (if not a cue), the nulls and filters will withhold the data from the target.  A little trickier with cues, because this is a tracking desk (and we are treating nulls/filters as an "ignore" condition).  So, if you have a null flag on channel 1 intensity, if channel 1 intensity is not part of the preceeding cue, it will be completely withheld.  If channel 1 intensity is in the preceededing cue, the current value will be ignored, and channel 1 intensity from that cue tracked into the new cue.

    So, to Remove something from a cue completely, you go to Blind and put a null on it.  If you say @ Enter, you are just going to allow the previous value to track in.  In non-cue record targets, you can use either the @ enter command or the null command to remove it.

    We have specified syntax that we've not yet implemented that would allow you to:
    [Intensity] [Delete] [Preset] [1] [thru] [9] [Enter] - for example.  So, you'll be able to remove stuff without going to blind, but it won't be via the filters.  It is worth noting though, that on cues, you'd be deleting the move instructions, allowing tracked values to enter the record target(s) specified.  And you'd need to be sure to append the [Cue Only/Track] instruction as necessary.   If you want to remove the channel/parameters from the cue ..... blind/null is going to be the way to do that.

    Ok, so that's were it stands today.    I brought this topic up for discussion again after you and David worked together in the LA office.    I've spoken to two other programmers who've used Eos on a show and they seemed to feel that the way it is working now is the most consistent and easily understood.    Using filters on tracking desks gets a little tricky.... and I think we need to have the same rule set regardless of the tracked or non-tracked nature of the record target (cues vs presets, for example).

    Let the open discussion begin!  And I'm gonna get on my homework assignment post haste!!

    :)

    Anne



    [edited by: Anne Valentino at 11:05 AM (GMT -6) on Thu, Aug 09 2007]
Children
No Data
Related

www.etcconnect.com