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

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