Anne,
Can you please explain to me why you took away the Next key putting up the next available(Q #, Sub # etc.). I came to depend on that function and have yet to understand why it now calls up the next recorded. I wish you would put it back. Please. Also I have on my RFR the next wheel does a similar thing. Where I could use it to scroll to the next channel # now it goes to the next active channel. Very frustrating.
Andy
Andy, I just checked the next/last functions on Eos and Ion in 1.7 (also checked in with the team to make sure I hadn't forgotten anything). Next/last is working as it always has (as far as we can tell... and there were no code changes to this feature between 1.4.x and 1.7).
When you have a record target on the command line (either terminated or unterminated), next always advances to the next stored instance of that target.
So, [Sub] [1] [next] will post whatever the next stored submaster number is.
When you are using the [Record] function, [Next] advances numerically, depending on the granularity in use.
So, if your selected cue is Cue 2, record next will post cue 3.
If your selected cue is 2.2, record next will post 2.3.
If the last sub you did something to from the command line was sub 100, record sub next will post sub 101.
If you have a channel on the command line, next accesses the next channel.
If the command line is empty, pressing next will post the next highest cue above the currently selected cue.
What are you seeing that you think is different from previous releases??
thanks much!
a
Anne Valentino
Eos Product Line Manager
Hi Anne,
Read your reply and it's not the same. Before when I was building cues in blind if was in Q 1 and typed Cue next I would get Q 2. Now I get the next recorded cue. If there is no later recorded cue it will show the cue you are already in. It the same in the Submaster editor. I ran the console all last summer and half of this summer and it is different. When Josh came the day I installed 1.7 and pointed it out to him he confirmed that it had been changed. This software has been making me doubt my sanity. It is doing some unexplainable things. Maybe it just doesn't like me.
In 1.4.x. the fact that from an unterminated command line in blind if you said [cue] [x] [next] - it would post the next numeric cue, not the next recorded cue was a defect. This was fixed in 1.7, to make it consistent with the use of next from an unterminated command line in live.
This is one of those instances where you fix something that most users consider a defect - only to find that a handful of other users found it useful.
Sorry. We've devoted HOURS of time discussing how next and last should work through record targets. The solution we now have seems to be the one that works for most people most of the time.
As one of that "small" group who found that defect useful I must say I don't understand how having the option is a negative thing. Since using next alone did the same thing as both next and cue next does now. Removing functions doesn't seem like a good thing to me. Also I now find the on my wireless remote that the next last wheel doesn't work as it used to. I could formerly scroll through from channel to channel making focusing faster and easier. Now it goes to the next active channel. I find this to very unuseful. So as is often the case the majority in not always the best judge of what's good or useful. I doubt since you spent so much time discussing it that you would consider reversing it but it would make this operator very happy.
much love,
If we are back on the what should happen when you press Next could I repeat my little request that group# + next select the next group and not just some random channel that is the sequential channel to the last one recorded in the grouping. I have never understood that logic. So please could we consider changing it.
Thanks in advance
Paul
Paul Higgins
Royal Opera House
pressing group# + next without using the enter key between the group # and the next key will select the next group. You can continue using the next and last keys to go through your groups until you press enter. Once you have pressed enter you are working with the channels within the group and you can use next and last to select through all the channels within the group. If you use the select last button to re-specify the group you can use the next and last buttons to again go through your groups.
Hope this helps clear things up.
Andrew Webberley
Andrew
I'm afraid that on Eos what you suggest does not work and has never worked.What i want to be able to do is select sequential group numbers without having to type the actual number. You can with channels and I can't understand why the same logic does not apply to groups.
But thanks for the reply anyway
just trying to clear this up.
what you want to be able to do is end up with
group1 + group2 + group3
without having to type in the group number each time.
right now if you press
group 2 + group next
you get group 2 + group 1 because the console defaults back to the first group.
if you press
group 2 + next
you get group 2 and a channel
what you are looking for is the default behavior to assume group once you have selected a group. I don't see that happening because there is no channel key.
what I can see maybe working would be pressing
and getting
group 2 + group 3
that is how I could see this work.
You are right it does not do that currently. I defaults back to group 1.
I'm sorry I misunderstood what you were looking for it to do.
The syntax [group] [1] [+] [Group] [next] [enter] - should be giving you groups 1 and 2. It isn't currently, but we will make it so.
Paul, I know we have had a lot of discussion about group n + next over the past year. We've not changed it to your suggested result because there is an application for a syntax that selects a group plus the next channel number over the last one in the group. And the way the syntax currently works is completely consistent within our syntax rules. Group 1 + next selecting the next group is an exception to those rules... and as Andrew points out, as there is no channel button....it would be completely impossible to construct a command line that does what this syntax currently does.
As the above discussion of cue next would indicate..... changing existing syntax is problematic. Even if you do it for consistency, its likely to make some users unhappy.
Just some thoughts.
Thanks!
is there a doc with the syntax rules defined?
point the bright end at the talent!
Hmmm... not really. The basic idea though is that thru ranges collect "same type" targets, while + or - ranges can be used to specify "different type" targets.
does that help?
Hi Anne!
Will this fix the syntax Group x thru Next as well?
Currently this syntax delivers Group x thru 1....which made me trip 90ways of dimming about a week ago! I should have checked my command line before hitting Level....but hey....!
1.8....1.9???!
Oh and a quick reminder/plea about Update Last Referenced....you previously said 1.7, but I guess as 1.7 is what we all expected as 1.5....1.8?! I just really want that feature....will make me feel a whole lot more comfortable about updating at speed! And will also speed up my relights time no end!
Cheers
Warren.
Warren Letton
ROH and various other places!
Warren, Group x thru next is being fixed. We are not making any changes to update in 1.8 (a limited release to provide two new features). Update last reference will be in 1.9.
Hope that helps.
OK Anne... You opened the door. What two features are coming in 1.8? :-)