"MoveTo" Parameter from Sub to Cues

Why?

I'm not trying to be an ass... just not sure we want to make requests for things that don't make sense to have the development team do. There are hundreds if not thousands of items on the todo list and this one does not make sense. Why would you need to move a value from a sub to a cue. Just copy the data and if you are done using the sub delete it or remove the value from it. I know that is a two step process.

Sorry, but that is no real answer on principal lacks and undefined holes in the console syntax.

That wasn't supposed to be an answer. I think it is a genuine question to find out how much this "hole" impacts is daily. There are plenty of channel commands that do take copy but not move, but since there are other things that can't be done, not even with a work around, but this one can ( I guess it takes for more buttons), it's a question of setting a priority

Actually there are a number of problems with inconsistent syntax and this console. I can't group # move to group # in live but I can in the group list. Delete has to be first everywhere in the console except in patch I can go channel # part 2 delete. In any target list (color color, preset preset) the console defaults to that parameter so that if I start to type a number it assumes I mean a color palette or a preset. But not in groups. That default is channel. And don't get me started on fixture editor, partial show merges (seriously, in the advanced merge window, enter doesn't terminate the text input and move to the next tab but instead dumps you back into live and closes out the merge window) Having just tried to help a Hog programmer jump to an ION, I have experienced first hand the frustration of a new programmer's reaction to the idiosyncrasies of the EOS's syntax.

While there are many inconsistencies, one of them is dictated by logic, and it's one that makes up a big part of your list: it's the behavior of group... Group is a selection tool and as such is always -except in the group list- treated as selection. There is stuff that couldn't be done if group everywhere but in Live and blind didn't behave the way it does now. it mostly comes down to the absence of a Channel hardkey. But yes, delete before or after the object bites me every other day...

You can use "copy to"

Another missing grammar, in Live "Group x MoveTo Group y", working only in group list, why?

but what do you want that syntax to do? are you moving attributes from channels in groups to group y? Are you changing the channels in group x and group y? group is a special case because in live it is used to select channels and then do something with them. The group list display exists to give you a place to manipulate groups and their contents. I use group move in patch to move channel numbers around.

In the group list I use this command to renumber groups. The content of the group are only a selection of channels, no attributes.

There will come a time, when moveto in Live is implemented to move values from a selection to another selection. Juggling groups is done in group list display.

i don't want to have to go to group list to re-arrange my direct selects. and if i do go to the group list page to move stuff around, then I want the default to be groups and not channels. i just want everything that can be stored in a direct select to act the same way. I don't want to have to think, oh i'm manipulating groups i have to do i this way. now i want to manipulate presets so i have to do it that way. and don't even get me started on effects. but this is all esoteric anyway. i mostly chimed in cause i thought sstaub deserved a better, less snippy response than what he got.

My questions may seem snippy but groups have to be different because they are a selection tool.  

If groups acted like all the other targets we would not be able to use the group to collect and move data between other targets. If that is the case why do we have groups? 

example... I want to copy the data onstage from group 1 to group 2.  If the group direct selects act like preset direct selects and I press group 1 copy to group 2 I have now copied the contents of group 1 to 2... how do I go about copying the data from the channel within group 1 to the channels within group 2.   ETC could make the copy to button just be useful for manipulating record targets and rely on the recall from to move data between channels... that would be an option but sometimes I like to use copy to and sometimes I like to use recall from... depends on the situation.  I don't want to have to think... am I trying to alter channel information or target information?  

If the group list defaulted to group how are you going to change any of the contents?  There is no Channel button.... should ETC add a channel button?  Groups aren't like the other targets.

I have been using the Eos console line for almost its entire life.  It has continued to grow and expand it functionality without sacrificing the ease of use I rely on daily.  There are reasons for all of the things that you find annoying.  Some of those reasons may simply be that there has not been time to code the specific functionality into the program yet.  

I don't ask questions back to be snippy.  I ask to try to find out suggestions that may help.  Just saying you want all the direct selects to act the same does not take into account all the different targets that can be in direct selects.  

don't forget, if ETC implemented every "I want" from all the operators, programmers, and designers in the world we would have a console that does not function. We all have things we want it to do and we want it to do those things right now.  

Please keep posting requests, just don't expect us to agree with you all the time...  Programmers are a opinionated bunch. :) Most of us aren't trying to personally attack you we just have very strong feelings about the tools we use.

The way to clean up all the list syntaxes is to add an {edit} key to all List displays.  That once and for all removes the ambiguity from what the operators intentions are and side steps the lack of channel key.  Personally I'd be fine with it - but it would be difficult to create consensus on this issue.