• Date
    Kelvin Leung
  • Date
  • Replies 16 replies
  • Subscribers 183 subscribers
  • Views 31422 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]
  • in reply to MacStgTek

    We have also discussed alternate ways of removing data from record target while in live, without having to set nulls and then record them. If in live, you were able to use [chan 1 color delete preset 1] to remove all of channel 1's color from preset 1, would that provide what you are looking for? This way you wouldn't need a seperate record operation to complete the command, and it would be less ambiguous what the results would be.

    Thoughts?

Reply
  • in reply to MacStgTek

    We have also discussed alternate ways of removing data from record target while in live, without having to set nulls and then record them. If in live, you were able to use [chan 1 color delete preset 1] to remove all of channel 1's color from preset 1, would that provide what you are looking for? This way you wouldn't need a seperate record operation to complete the command, and it would be less ambiguous what the results would be.

    Thoughts?

Children
  • in reply to Dan Duffy
    Anne & Dan~
    Thanks for the replys.
    To me, I can see both sides of the fence.
    However maybe Im also miss-understanding the way EOS is treating nulls and filters, since you mention there the same thing... Im understanding NULL to be a lack of value in a target, Im understanding FILTER to be the filter window on the CIA screen, meaning this is what I use to determine what I want to record or remove etc....
     Does that make sense so far when rerecording existing targets  - Yep!! Makes sense.
    I also agree with keeping things consistant, However, to delete unwanted info from a CUE, I have to do it in blind, to do it to a preset I can do it in live.  To me that seems inconsistant... Or is my mind backwards.   I particularly prefer to do everything in live, as doing things in Blind on a conventional desk has never made sense to me... Im not particularly fond of things being put into cues without the programmer pressing a "record" or "update" button.....  but thats just me... ok.. forward ho.....
    Anne Quotes.....
    "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."
    I guess I want the filters to not be tied to a specific function, but rather what im doing on the console.

    If I go, (Ch1 gobo1 color delete preset 1 enter) the gobo and color info for Ch1 should be removed from Preset1. 
    So I guess Im missing something here, if the above syntax works with presets and pallets, can it not also work with cues?... why cant I go (ch1 gobo color delete cue 2 enter) thus removing Gobo and Color move information for Ch 1 in Cue 2, thus tracking the values from Cue 1.
    As always... MANY thanks....
    matt.


    [edited by: MacStgTek at 10:54 PM (GMT -6) on Thu, Aug 09 2007]
  • in reply to MacStgTek
    MacStgTek:
    I guess I want the filters to not be tied to a specific function...

     Actually do you but you just don't want it to be a global cue change.  We'd want it to be more specified.  It makes sense to explain in Hog2 speak where you pull manual values into selection and then remove anything you had just grabbed manually from whatever you specify in the command line.  Something like Record Delete Manual Enter.

     
    -j
     

  • in reply to MacStgTek
    Hey Matt.  Well - we haven't implemented the delete at a channel/parameter level syntax yet, so it's all open for discussion.  But, initial instinct upon deleting data from a cue is that you are removing move instructions.   When a move instruction in a cue is deleted, data from the previous cue tracks in.  We could make a special case for delete that says the actual result of this action is placing a null for that channel/parameter in a cue.  Since its a very deliberate action --- and there are other ways to remove moves in live -- keeps you from having to go to blind.    And.... since we have never supported channel level deleting on our legacy products, it won't disrupt long established habits.  OK, I'm game for that.  

    And no, I don't think you are misunderstanding the ways nulls and filters work.   Just like Artisan or Virtuoso, when you apply a color filter in live (for example), you are telling the desk that you are not interested in storing IFB parameter categories (so, you are selecting the parameters you do want, automatically excluding any parameters you have not collected).  At this stage in the game, you will see "n" is superscript on all IFB parameters -providing a fairly significant visual indiction that you've excluded IFB from record operations.  When you apply a null to a channel/parameter, you are excluding that channel/parameter directly.... also resulting in the grey "n'.  So, both operations net you grey "n" indicators..... one from a negative selection (parameters that you didn't collect under filters) and the other from a positive selection (make null).    Does this make sense so far?

    I think the biggest issue for you - coming from Virtuoso - will be the "ignore", not "remove" rule.    If you are recording IFCB palettes or presets, you are determining, via the filters, exactly what you want to store in that palette - so for the most part, you should get what you expect. (There is one thing that I want to talk to you about, but will do that via email).  The biggest issue will be cue data.  If you have excluded beam parameters via filters (they have that "n" next to them), following the "ignore" rule, you will not store the current settings for beam parameters in any cues you record.  HOWEVER, if there is any beam data from preceeding cues in the cue list, that data will track into cues as you store.  

    This is why this issue is so significant - and I gotta tell you, I think its a jump ball.   We've argued both sides quite successfully.  I think we went with the "ignore" decision because it is ultimately protecting your show data to a higher degree than "remove".    If you want to remove data, there is a pretty easy way to do that.  If it worked the other way around, and you made a mistake (you wanted to ignore - not remove), that's a lot of work to fix.  Not to mention the fact that you'd have to construct "ignore" instructions always from the command line. Hmmm..

    Interesting stuff, isn't it?   

    Thanks so much!

    a  


    [edited by: Anne Valentino at 5:49 PM (GMT -6) on Fri, Aug 10 2007]
  • in reply to jabadger
    Actually do you but you just don't want it to be a global cue change.  We'd want it to be more specified.  It makes sense to explain in Hog2 speak where you pull manual values into selection and then remove anything you had just grabbed manually from whatever you specify in the command line.  Something like Record Delete Manual Enter.

     

    -j



    First --- I thought I was nuts to be talking about control logic at 5AM.  You are up really early!!  Good to see you here!

    Elaborate please?

    Thanks!  
    a


    [edited by: Anne Valentino at 6:01 AM (GMT -6) on Fri, Aug 10 2007]
  • in reply to Anne Valentino

    Well I'm cheating.  In France right now so it's not 5am :-)

    What I mean is that on the Hog2, when you grab any parameters of a fixture, no matter what it is (red, green, intensity at 20% at 50% whatever), when you Record+Remove from a cue/preset it will remove the data for the parameter you grabbed and not care that you grabbed red/green, etc.

     -j
     

  • in reply to jabadger
    Got it.  Well, I think if we say that deleting channels/parameters from cues doesn't just remove the move instruction, it "nulls' them in the cue, we get the same thing.  On Eos, a null applied in blind is the same as a "knock out" on a Hog.

    Have a great trip!  And please tell me you are working.... because if you are on holiday in France and still posting to this forum, I'd be seriously concerned about you! :)

    a



    [edited by: Anne Valentino at 5:47 PM (GMT -6) on Fri, Aug 10 2007] [edited by: Anne Valentino at 7:49 AM (GMT -6) on Fri, Aug 10 2007]
  • in reply to Anne Valentino

    Anne~

     

    We've been worried about Jason for ages.

     

    M 

  • in reply to MacStgTek

    Shush!

    Yes I'm out here working.  Less than a couple weeks to go! :-)
     

Related

www.etcconnect.com