move groups

that's it. thanks alot.

Wouldn't it be convenient to be able to do this in live as well?
that way i can set the groups geografically.

greetings

Mart

This is by-design. MoveTo and CopyTo with Groups in Live could be ambiguous, as you use Group to mean a selection of channels. So in Live, Group 1 CopyTo Group 2 would copy the information about those channels, not make a copy of that Group. Obviously the behaviour is different in the Group list.

For consistency, Move as required above is done in the Group list as well.

Hope that makes sense!

-luke-

This is a feature I would like to see as well, and I don't understand why it's forbidden either.

To borrow and extend the above analogy, this isn't trying to get apple juice from an orange--it's asking "why is it impossible to make apple juice except in this one room?"

To be clear, I'm only talking about what happens when you want to copy or move a group into a non-existent group.  Doing it in live or any other place except blind group view throws command errors, so I don't see any possible ambiguity or confusion--the user's intent is clear from selecting a non-existent group as the object of the command.  All enabling this would entail is removing the command line error when in other modes.  The only thing achieved by restricting this action to group view is an unnecessary mode switch and extra keystrokes.

Let me break it down--

In live (or blind cue, etc), "Group 1 copy to Group 2" (which already exists) copies level information.  All well and good, and very useful.
In Group view, the exact same command, "Group 1 copy to Group 2" (which already exists) replaces the channel list.  So as things stand now, the user is trusted to understand that the same command has two different functions depending on context, and must learn to keep them straight.

In live (or blind cue, etc), "Group 1 copy to Group 3" (which does not exist) gives an error and does nothing.  "Group 1 move to Group 3" (which does not exist) gives an error and does nothing.
In blind group view, the exact same commands copy or move the channel list into a new group.  This is the only "place" in the software where these commands function at all with a not-yet-existent object.  Where would the confusion come from letting this work in live instead of throwing an error?  What ambiguity is being avoided?  The context of choosing an empty group slot makes it clear what the user wants to achieve.

Maybe this is yet another quirk of how the workflow on film/tv shoots differs from theatrical use--I make extensive use of group DS tiles throughout the day, for a quick graphical handle to channels I might only need for a few hours.  It is extremely useful (and FAST) to create these groups by clicking on an unoccupied tile in the group DS display.  As the day progresses, those tiles can get moved around and redefined many times, so being able to quickly rearrange them is important.  Being prevented from doing this in live adds unnecessary steps and slows things down.

Matthew Rohn
IATSE Local 52

This is a feature I would like to see as well, and I don't understand why it's forbidden either.

To borrow and extend the above analogy, this isn't trying to get apple juice from an orange--it's asking "why is it impossible to make apple juice except in this one room?"

To be clear, I'm only talking about what happens when you want to copy or move a group into a non-existent group.  Doing it in live or any other place except blind group view throws command errors, so I don't see any possible ambiguity or confusion--the user's intent is clear from selecting a non-existent group as the object of the command.  All enabling this would entail is removing the command line error when in other modes.  The only thing achieved by restricting this action to group view is an unnecessary mode switch and extra keystrokes.

Let me break it down--

In live (or blind cue, etc), "Group 1 copy to Group 2" (which already exists) copies level information.  All well and good, and very useful.
In Group view, the exact same command, "Group 1 copy to Group 2" (which already exists) replaces the channel list.  So as things stand now, the user is trusted to understand that the same command has two different functions depending on context, and must learn to keep them straight.

In live (or blind cue, etc), "Group 1 copy to Group 3" (which does not exist) gives an error and does nothing.  "Group 1 move to Group 3" (which does not exist) gives an error and does nothing.
In blind group view, the exact same commands copy or move the channel list into a new group.  This is the only "place" in the software where these commands function at all with a not-yet-existent object.  Where would the confusion come from letting this work in live instead of throwing an error?  What ambiguity is being avoided?  The context of choosing an empty group slot makes it clear what the user wants to achieve.

Maybe this is yet another quirk of how the workflow on film/tv shoots differs from theatrical use--I make extensive use of group DS tiles throughout the day, for a quick graphical handle to channels I might only need for a few hours.  It is extremely useful (and FAST) to create these groups by clicking on an unoccupied tile in the group DS display.  As the day progresses, those tiles can get moved around and redefined many times, so being able to quickly rearrange them is important.  Being prevented from doing this in live adds unnecessary steps and slows things down.

Matthew Rohn
IATSE Local 52

My point is not to hash over what is, about which I have no confusion or misunderstanding, but to suggest what should be.

And thank you for the macro suggestion, but it is not anywhere close to being faster or more efficient than "click DS tile, tap Copy To once or twice, click nearby empty DS tile".

In my opinion, the paramount design criterion for any technology is that it should serve the user's needs. What makes "sense" to a computer is whatever it has been programmed to do. What's "right" is whatever gets me to my goal in the quickest and most intuitive fashion. If there's a choice between preventing a function based on a philosophical design concept, and enabling a useful and intuitive feature that increases my speed and efficiency, I think the latter should win hands down. And I'll wager that most people who press buttons on lighting consoles as their jobs have enough going on upstairs that they can deal with whatever supposed slight rule-breaking such a function might entail. And I'll further wager that there are already numerous examples in the software where the rules are broken in a similar way in the service of utility.

Not to belabor this already well-beaten horse, but as a little more background so you can understand where I'm coming from--

Operating a console while lighting an edited, narrative TV show entails a different work process than creating or operating a theatrical show, and maybe this is an area where something that perhaps makes a little more sense in a theatrical context makes a little less sense for the way we work. Our day-to-day work involves continuously changing levels on the fly, building looks that might be used for 30 minutes to a few hours at most and which will, under normal circumstances, never be played back. The vast majority of the work is done in Live with manual data, and while we're lighting a shot, taking more than one or two seconds per adjustment is moving too slow. For that reason, any housekeeping I need to do has to be similarly fast so I'm ready for the next adjustment. It's quick and easy for me to record specials into groups on the DS display in live, so ten minutes later when the gaffer says "bring the window baby up 15 points", I can make the change nearly immediately without having to remember or type in the channel number. As the day progresses, I add, remove, change, and rearrange those tiles many times according to the needs of each setup. And when the setup or scene is done they get deleted, so the finer points of data management practices are irrelevant. Being able to move group DS tiles in live on the fly would be a very useful time-saving feature.

I am not sure what's more valuable here, user intuition or computer logic. If it is proven that multiple user have tried to achieve something in a given way and it doesn't interfere with existing functionality otherwise, there is absolutely no harm in implementing the function. You are always free to write a macro to do it the 'correct' way if you think that is better...

hydrogen said:

Now, I will say that I've always wondered why we can use both "copy to" and "recall from" to transfer levels between items (and why they sometimes have different behaviors...) Maybe it would make sense to change copy to/move to to move the target around, and recall from to grab the values, but that would be a surprise to a lot of people who currently expect something else.

Copy to and Recall From are different because they leave you with different channels selected at the end of the operation.  Sometimes you want to "put" data into another channel but leave the source channel selected.  Sometimes you want to "grab" data from another channel and leave the target channel selected.  It's all about which direction you are working/thinking at that moment, and what operation you are planning on doing next.  We need to have both functions work for channel-level commands.

Recall From and Copy To should behave the same with channel-level functions.  Where do you see different behaviors?

On the bigger issue of moving & copying the groups themselves, it's critical to maintain that all functions applied to groups in Live or Blind apply to the contents of those groups and not the groups themselves.  "Group 1 Copy To Group 2" is an incredibly powerful function, and I use it every day.  While "Group 1 Move to Group 2" currently throws a syntax error, moving move commands (in blind) or manual data (in live) are features that many of us would love to see.

Toggling an edit mode on direct selects would be one way to add some flexibility here, but I'm not sure this would satisfy Matthew or the others who are asking to be able to move/copy groups in Live.  And, isn't pressing [Group][Group] before you move or copy groups with the DS tiles already effectively the same thing as entering an "Edit" mode?