Thru Thru

Hi all,

We've just finished programming our rep season on our EOS (running V1.7), and ran into this problem (in fact, I posted a thread on it).

We discussed it here, and everyone seems in agreement that the logic should be "1 <Thru> 5" always picks up channels 1,2,3,4,5 (provided the channels exist...not that they necessarily need to be patched to anything) irrespective of what flexi display you're in.

<Thru> <Thru> would be a nice lazy-man's shortcut for me to select the active channels in the range (my first automatic thought is Strand's "Thru On", rather than the "select active" function) - I'm not sure I understand the difference between what Thru Thru does that's different from what I expect Thru to do...

I can see the Rep house argument, but I think it would be more intuative this way.

Hope that makes sense!

Dave

Dave,

If you are in a flexi state, thru thru will select all channels in the range specified, using thru just once will only select what channels are being displayed by the flexi state. Make sense??

Now my argument against the behavior being swapped (and this is in NO way a direct slap in the face to you, just trying to create more discussion about this)...if it is swapped to where 1 thru 10 selects all regardless, and you have channels that don't exist in the show, why would you want to record values to channels that do not exist? It does not make any sense to me why anyone would want that. Why make the programmer and designer have to think about what channels to select?

My other question/argument/confusion is that why is this all of the sudden an issue? The behavior IS the same as it was in obsession land. From talking to my boss and a few designers who have used EOS, they've all said that the behavior should stay the same.

Thoughts?? Comments??

-Nate

Ncoons said:

My other question/argument/confusion is that why is this all of the sudden an issue? The behavior IS the same as it was in obsession land.

I guess, which I didn't really explicitly state in my post, was exactly what Nate is saying.  The syntax is the same as it always has been, so why is this even a discussion?  I vote for leaving it the way it is.  If you change it, then there will be even more confusion.

-Tim

Tim,

I hope you know that just because you posted that five times, you don't get five votes.

Nate,

I accept and respect that other folks have different situations and methods, but it seems a foreign to me that one might have a bunch of channels not in the current show.  Especially now that it is so easy to have many discreet show files on the hardrive.  I might think differently if I were in your shoes, but my inclination would definitely be to patch specific systems of purpose  in consecutive channels.   Otherwise, do you end up with, say, your warm front lights in something like channels 1, 3,  6, and 10 instead of 1 thru 4?

B

It seems that a lot of the people having issues are coming over from Strand type consoles. I made the switch from an Obsession 600 so the new version of thru is in line with what I am used to.

I think that the capability of having multiple people using multiple displays with independent flexi modes does change the game. Like one of the other people mentioned it makes sense for [thru] to be consistent for everyone and [thru] [thru] to be user specific. For this to be possible [thru] should grab all of the channels in the specified range and [thru] [thru] should grab only the channels visible to the "programmer".

I wonder if flexi modes could also become modifiers within commands. Something like this.

[1] [thru] [9] {patched channels} [out]

Sorry, that was a PowerBook + Firefox = FAIL.  It froze up so I was hitting refresh to try to get it to load the page and I guess it sent the post five times.  My bad.  Can a moderator delete four of those or something? No need to leave them all there.

Ncoons said:

If you are in a flexi state, thru thru will select all channels in the range specified, using thru just once will only select what channels are being displayed by the flexi state. Make sense??

Yup, in other words it does exactly what I'd expect thru to do.

Ncoons said:

if it is swapped to where 1 thru 10 selects all regardless, and you have channels that don't exist in the show, why would you want to record values to channels that do not exist?<snip>Why make the programmer and designer have to think about what channels to select?

I wouldn't want non-existant channels to come up - but equally, I delete channels that are completely out of use, so they wouldn't come up - channels that haven't been patched yet might be waiting for me to patch them when I know which dimmer it has been plugged into - so I would want them to come up.

If a designer has channels 1 through 10 as front cover on the stage, s/he may have only used 1,3,5 in the show so far (so only 1,3,5 will be active). Typing "1 <Thru> 10 @ 50" at this point will only give 1,3,5 at 50, rather than the whole front wash because the operator found it easier to look at the active channels display. To me, that is counter-intuative, and not what the designer wants - I've had plenty of designers ask for the channels which are 'on' between 10 and 50 to go to full, but whenever they ask for "through" they mean every channel.

Ncoons said:

My other question/argument/confusion is that why is this all of the sudden an issue? The behavior IS the same as it was in obsession land. From talking to my boss and a few designers who have used EOS, they've all said that the behavior should stay the same.

I suspect it is because the EOS is getting people from all sorts of backgrounds - some ETC, some not, so I guess the discussion is more about what users feel is logical to work with. Also, I believe the Obsession only had 2 flexi modes - the EOS has 4, and this only applies to one out of those 4.

To me, it makes no sense that the way I choose to display channels should affect my programming syntax - I wouldn't expect changing the format of the display from table to tombstone would prevent me from changing the colour of a light (for instance - I do realise that it doesn't have this behaviour). IMO, the displays should be there to provide the information the programmer needs in the most logical form, whereas the syntax is about what the designer asks for - I don't feel my choice of display should impact on what happens on stage.

Ncoons said:

(and this is in NO way a direct slap in the face to you, just trying to create more discussion about this)

ditto - this is just the way it works for us here and in my head.

Cheers all

Dave

Ahhh!

Please leave [Thru] as Flexi dependent. This is me rallying behind Crispy. We to have about 1000 ways of dimming it is sooo useful to have this feature. Does it not work for you 'patch what we use' guys to use Tab 1 with Patched channels and then have a second tab with Active if you like this view? It seems Active is the only problem case here.

T

Wow guess I really opened a can of worms with this thread.  I still stand behind (Thru) should be Abs.  Thru selecting whatever you type 1>5 selects 1,2,3,4,5 if they are patched of course.  I read everyones thoughts and alot of them make great sense.  So whatever ETC decides I will adjust, then figure out how to explian to all the different types of designers it is not a BUG just a new function.  I think right now though we are about 50/50 on this???

Anne, have you guys made a final decision yet about this???

This is why I think this should be a desk setting, that we the programmers can choose for ourselves!

Have fun everyone

tomsnell said:

Does it not work for you 'patch what we use' guys to use Tab 1 with Patched channels and then have a second tab with Active if you like this view? It seems Active is the only problem case here.

Then you'd have to take up 2 screens with the channel display - because Patched Channels would have to be an active tab (and therefore visible) in order for the desk to respond to the commands, and the other one with Active Channels so you can see that...

(With all these tuppences I've put in, I'm down several quid, so I'll shut up now!)

Dave

Anne and all the wonderful folks here,

Well, it has been several years since using the Obsession 600 and my theater days (miss you guys), as I now program in film & tv. I was recently reminded of THRU THRU and it logical makes sense. It has been mentioned to keep the syntax as is and I agree with that, an OPTION in desk settings to adjust (I love the fact of customizing the console to a certain extent) a plus. In my world we do have programmers changing shows and replacing programmers, so keeping the console consistent is of course the best option. The common consoles in film & tv are Expression 2,3, Hog and soon to be ION. Most programmers (newer ones of course) are familiar with THRU and have had little programming with Obsession syntax, so coming in on a new show with this console with THRU THRU can ruin the day for them, as well as, future employment. I have been using the Ion for 4 months (Love It). I REQUIRE the use of Flexi-Active channels for efficiency as the Gaffer (lighting designer) is always asking for levels on channels and having them displayed on one screen a must and using THRU a big bonus. OK....with that said....every second counts in dollars for production time. Until, reminded of the THRU THRU I was pulling my hair out at this situation, my bad memory. NOW, that I am reminded of the syntax it is fine but would be faster with just THRU (wouldn't be a bad idea to BOLD case it in the MANUAL on all required pages) and ADD a option in desk settings to Turn ON or OFF so we may customize the console for our world. Sorry for the rant and hope this adds a different perspective....if not, well thanks for reading, peace.

I appreciate the rallying behind me but I must say that i don't really mind which thru does what. Although it may have happened that way on the obsession doesn't mean that its necessarily the most logical. 

Just let me know and I'll learn to push those buttons instead.

To chime in again, I think there's actually two points being discussed.

- First is thru vs thru-thru behavior, which one is flexi based and which one is absolute.  

I'm inclined to say thru should be flexi based; if you're taking advantage of the feature, you're most likely in a rep sort of situation with channel gaps in a system of channels and will use flexi thru all the time.  Thru-thru would only be necessary to add new channels to show channels view or active view, which is much less common.  I recently discovered that if the starting channel in the thru range is not on the screen, thru becomes an absolute thru.

- Regardless of how the votes go, I think the other issue is that the flexi mode of thru is screen dependent, and that Eos can have multiple channel views, with an RVI in yet another view.  Even in mirror mode, if my understanding is correct, the Eos desk could have, say, a third screen of active channels that is not mirrored on a 2 screen RVI.

I think for flexi thru to be useful to a designer, there needs to be some way to know that the programmer is in the same flexi mode, whether that's a desk setting, a soft key ([thru] {show}), some way to bind thru to a tab, etc.  Admittedly, the alternative is to just always use groups or a frequent use of the [-] key, which isn't so bad.

-Josh

To rehash an old thread

Thru should be absolute..

thru thru should be active in cue

It would allow you to use it no matter the flexi state....

I understand its usefulness don't get me wrong.  But in any other flexi state thru means thru.  If Thru Thru was to selcet active i see it as a way more useful syntax....

Sorry to try and open this up again,