It's a feature that is also present in maya- it is called "auto frame" there:
http://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-ABB47176-9119-47F2-8466-6FA19C427F9F-htm.html

"Auto Frame
Automatically adjusts the graph view to fit the display of the animation curves associated with a selected object or objects."

This is useful because the software automatically frames the curves of an object/channel. When you switch between two different control objects, in a lot of cases their f-curves can vary a lot in size. The animator has to then constantly frame them or adjust the graph view in order to see the entire f-curve. Having to do this repetitively adds a laborious distraction to the workflow of the animator.

Auto-frame removes the need to do that constantly and thus removes one of the boring repetitive things that must be done in the workflow.

Here is more from a great animation book by eric luhta:
Cheating in Maya for Animators by Eric Luhta

"Enabling View> Auto Frame will automatically focus on any attribute(s) you select, without having to hit the F key every time."

The need to hide f-curves is a specific to blender request. Curves of channels that are not selected also have select-able keyframes on them. So very often when working in Blender, the animator selects other channels by mistake when trying to select a keyframe or box select keyframes on the curve that they are working on. In Maya and other software channels that are not selected do not show their curves in the graph, unless you "Pin" them.
In blender one has to manually hide them by default.

If you would like to, you can split the auto-focus feature from the "Hide unselected channel curves" feature with a another tick box. :)
Also you could add the option to auto-focus the curves based on the play range that is set by the user.
In any case this patch seems to now wonderfully do what me and Farh requested at blender artist. It does save tons of time! If you havent used it in other software, please give it a try. :)

would it be possible to get a Linux64 or windows64 build to test on?

I really hope it makes it to trunk!

Oh I also forgot to ask. It's not showing it in the gif file. Does it also work on multiple selected channels?

I understand the need for the feature but I don't like all these checkboxes in the view menu; I think it should be more visible/switchable.

The functionality is like 'Solo' in sound editors, where you only have the Solo'd track/s . Two suggestions

a- add another icon to the channels. If any are solo'd they become exclusive (not based on selection) Multiple channels could get 'solo' and there should be an 'unsolo all' operator somewhere so you don't have to hunt for it.

b- just have the solo based on selection, but make a very visible button (or hotkey or both) for it so it is easy to go back and forth.

c- don't have the option, but make control clicking or double clicking on the visibility buttons hide all other channels. You can then still click on more channels to have multiple channels visible. Or even: clicking on visibility icons is exclusive by default, and you have to shift click to make others simultaneously visible. You still need an intuitive way to make all channels visible.

for the bassamk suggestions I like B) the most since it is the simplest and most intuitive one of the three - just have a single toggle on/off solo mode button to enable the display-only-selected-channels-curves mode. These are suggestions for half of what is implemented here though - the solo-ing of an f-curve (hiding all curves that are not selected)

It would be best if the auto f-curve focus is a separate feature that is enabled with a tickbox in the view menu- the way it is currently.
It's just the most obvious place to find that feature and for me personally I wouldnt need to toggle it on and off very often. It will probably be on most of the time.

For the most part I think you have successfully implemented it. Now it's only a matter of splitting it into two separate on/off toggles.

One being a button (solo view mode - show only selected channels), another being a tick box in the view menu (Auto focus channels)

I haven't tested it, but judging by the demo it's looking almost perfect.

I personally like having it in a view menu as a toggle-able option, but I'm open to alternative ideas there.

Having it auto-frame my channel selection is SUPER useful and a good time saver. It's also helpful for situations when I want to select multiple channels that are similar and edit them together. So making sure that it auto-frames your whole selection is critical, not just one channel at a time (I think it does this, I just haven't tested it).

I'm a little fuzzy on Bassam's suggestions, so if I'm way off base here, I apologize. But what concerns me about some of the "solo" suggestions is that it sounds a little too convoluted, like I have to click a solo button for each channel I select? And then turn the solo button off when I'm done? If I'm understanding this correctly it sounds convoluted and kind of defeats the purpose of this feature. It should be either on or off as a global behavior of the graph editor. It's purpose is to be a time saver, so adding clicks to each operation is counter to the intent of the feature. Again, this may not have been what you meant with your suggestions, so let me know if I misinterpreted them.

Now concerning how it handles hiding of the unselected curves, for my personal workflow, I usually want all unselected curves to be hidden. If I don't want to work on a curve, then I don't want to see it. It just adds visual clutter to the graph editor when I want a clean workspace for the curves I want to edit. If I want to see all the curves at once, then I simply select them all and there they are.

However, there are some cases where an animator may want to see unselected curves in the background while editing his selected curves. Blender already has a toggle-able option to only show editable keys on selected curves, which is useful. So perhaps this auto-focus feature can have 2 options. One to frame up selections, and one to hide unselected curves or not. When used in conjunction with existing options, it's possible to auto-frame selections while still seeing unselected curves (that are un-editable since their keyframes are not visible). This would be the most flexible approach, but have the drawback of adding one more option to the UI or view menu, unless there is a way to combine something somewhere, I'm not sure at the moment.

I agree with fahr that bassamk's suggestions sound way to convoluted/unclear.

I assumed that they were aimed at only the hiding of f-curves part of the behavior and not the auto-focus part.
Thus why I suggested to split the current implementation into two features that are a global mode of operation (like it is atm) and can be switched on/off:

• Auto focus selected channel(s) - toggle on/off in the view menu
• show only selected channels curves - toggle on/off with a single button - as suggested by bassamk

I also agree with Fahr that it should not be something that you manually switch on per individual channel, but more like a global behavior/mode of operation(the way it is implemented atm). It really does defeat the whole point of the feature - which is to remove the need for the animator to do boring manual labor to set up their working environment. Instead the software, when enabled so should do all this work for the user automatically.

If this makes it to trunk, it will improve animation workflow ALOT. By which I mean that it can boost productivity by at least 20%
The less you make your artist click and do boring repetitive technical work to get their view right, the more of that time can be spent actually animating.

My opinion: if you stick it as a checkbox in a submenu as a mode a big percentage of animators aren't gonna find it. Just like they don't find/get confused by the gagillion checkboxes already there.
Even I am finding the current state of that menu confusing to say the least - how do the different options interact with each other, etc.

This is imo bad design. We already have channel visibility toggles, instead of enhancing this, we are rushing into a new *mode* that totally overrides these. I agree the functionality is great, but you're just thinking of your own workflow and ignoring the climbing complexity of the program.

Some questions:

• once you enable this mode, those eye icons in the channels will be *lying* to the user.
• if you make them tell the truth (i.e. shut eye if a channel is not selected) some users are gonna open files and wonder why the visibility icons are not displaying.
• accessing visiblity in a bloody menu sorrounded by a zillion checkboxes is slow. For many people's workflow, this is something you want to toggle on and off fast.
• adding a mode on top of visibility is adding two layers of visibility with some kind of logic and between them - this is too much complexity for what should be a simple task.

Finally:

• I like the functionality, but making it a mode and sticking it in a menu is at best burying it, and at worst, creating a booby trap for new users. Honestly that menu has already gotten out of hand, lets not make it worse.

Final comment:

A design that works with the existing visibility buttons/properties can also be made to work with with the lock and mute buttons, allowing us to have exclusive mutes and locks, which is also desirable functionality.

You don't have to like my existing suggestions, they're there to point out there's more than one way to do this - I'm just totally against adding yet another mode/property/view menu toggle. And I love the functionality, We should just find a better way of doing it.

I partially agree with you - it wont be found initially by new users. But that is normal with any other software. You seem to also have a personal preference of disliking that menu and wanting some things moved out of it - to another place.

That seems like a task for another bug report- since it is creating new work.
For the time being I am concerned with getting this functionality inside blender - approved for trunk.

The view menu is at the moment the most consistent place to put it right now. It already does contain a tick box that sort of sets the graph editor to a mode (lock time to other windows)

I disagree with you that the "view" icons will be lying. If you look at the gif, channels that are not selected have their view icons toggled off automatically. So they are properly communicating to the user that they are not visible with the icon.

In case the user gets confused as to why they are automatically getting hidden, then it would be obvious for them for as long as they were the ones to switch on this behavior from the view menu.

It can be a tick box somewhere in the graph editor interface (mockup needed) if you dont like the view menu.
I am not against your proposal of the placement.

I am against:

• forcing the need for extra actions- such as an extra click or holding of a button
• complicating of the feature, whose purpose is to make things automatic and reduce the need to do extra work

every click you make, every button you press is multiplied by the number of times you switch to a new channel. It all adds up.
This feature is here to completely remove the need for extra clicks and button presses for the user when switched on.

Please, try using it in Maya. it in the view menu there as well. The design team there knew exactly why and how to implement it. When Auto-frame is on, you dont have to do anything at all. It just frames your selected channels and hides the ones that are not selected.

In fact I dont see the point of showing all the channels that are not selected. They create visual clutter and their keyframes get in the way of the keyframes of the channel that I am editing. I think that is bad design in blender. But I guess that is a preference on my part because i got used to the good life when using maya.

I agree that menu is getting big. And I also agree that the existing visibility icons should NEVER lie to the user. So no arguemnts there. This auto system should work in tandem with what's already there.

But I also think that having the auto-frame feature automatically set those visibility toggles on the channels is the whole point. Since this is not a setting that's likely to be a default, a new user will never see their channels hiding and showing on their own, so there will be no confusion. And someone who activates this feature should know what they are doing and not freak out when they subsequently select a channel and all the others hide.

This also works because once the user selects their channel(s), they can then make small overrides by clicking on those visibility icons if they wish. The auto-frame feature only performs a hide/show whenever you select a channel right? So I can futz around with the visibility toggles afterwards and the auto-frame feature will not override this until I actually select another channel? This would be the desired behavior (for me, at least).

As far as how it's organized in the menus and in the code, you guys are much more qualified than I in that arena. I won't debate that aspect of things.

And, for the record, having this in the view menu is logical, and while it is getting big, I really don't care becuase its a menu where I go for all things related to working with the view of the graph editor. Placing this as an icon in the graph editor window would be MORE clutter, and useless, since this a "set-it-and-forget-it" feature. Icons should be for frequently used options.

I would like to clarify the reason I want this implementation to be split into two features:
Auto frame in maya does not hide the curves.It only frames them.

Showing only the selected curves is the default behavior in maya- whether you have auto frame on or not.

So these are in fact two features in one at the moment. It makes sense to me to have them split- for more flexibility.
But I dont mind if they are one as Fahr wants as well.

They don't have to be all-in-one. I'm all for flexibility, especially since blender's user base is so wide and diverse. I strongly appreciate the wide array of options that are provided to the user.

Sorry for not comming back to this earlier, but answering takes time and I prefer spending my free time with coding. Hopefully that excuses it ;P

Testbuilds:

• Linux (64 Bit)
• Windows (64 Bit)

In these builds I'm using some special logic for the Toggle All operator (A-key) so that it only selects all visible channels if Auto-Focus Channels is activated. Otherwise, it would always make all curves visible and thereby override the user set visibilities. This may sound like a good idea, but for me it doesn't feel "right" tbh. Feedback welcome :)

@Joshua Leung (aligorith), added inline comment. I'm all ear for better solutions.

@Todor Imreorov (blurymind), yes it works with multiple selected channels (I finished and uploaded the patch at ~4AM, so the information in the .gif and the description ended up being a bit meager ;) Sry about that )

@prout reprout (all), So reading through the discussion, it seems we agree to split this into two options? I'd propose calling them "Focus Channels on Selection" and "Auto-Hide Unselected Channels" (btw, as @Chad Gleason (fahr) said, you can always override the visibility state on your own, it is only changed automatically if you select a channel).
Now the question is: Where to place them? Here my proposal would be to move them into the View Properties panel of the Properties region. I know it's not a really good solution, but at least we don't enlarge the View menu again.

Hi, I gave the test build a go and have a few notes :)

First of all, awesome work so far. There is one thing I noticed.

Note1:
When you select a channel container ( for example "Location" contains "x location", "y location", "z location"), it hides all of it's sub channels ("x location", "y location", "z location"))
It should do the opposite of that. When you select a channel container, it should show (applies to auto-focus logic as well) all of the channels that are contained in it.

I made a screencap:

This applies to rotation channels container and any other channels container.
It also applies to when you select the top hierarchy "Object name" channel container. The idea is when you select a channel container- make all of it's children visible. Right now it's just showing nothing when you select it.
:)

Note2: Would it be possible to remove the auto focus animation that blender does in this case? Just show the curves without the fancy focus animation transition.

Note3: "Auto-Hide Unselected Channels" could be renamed to "Show only selected channels". It's shorter and easier to read imo. Both names work just fine anyways- so this is not a biggie

Sorry to be so late to the game.

Watching the gif, there are actually two different behaviors lumped in together.

The first behavior is one that I specifically avoided when working with Aligorith on Sintel: when you select a channel it automatically hides all other channels. When working in Maya I find that behavior extremely annoying, because it couples selection with visibility. An example of how this is annoying:

1. I have a set of channels visible that I'm working with.
2. I select one of those channels from the channels list to delete it or do some other operation to it.
3. All the other channels are now hidden, and I have to manually re-select them again.

In short, I am strongly opposed to coupling selection and visibility (but please read on before you jump on me for that, because I have a proposal).

The second behavior demonstrated in the gif is the auto-framing behavior. I think this could potentially be useful, but again, coupling it with selection is IMO a poor UX choice, because (again) it is really annoying and counter-productive when making selections for other purposes.

So here's my proposal:
For both of these behaviors, I wonder if it wouldn't make sense to tie them to some kind of modifier-key+mouse-button combo. For example, ctrl-clicking the visibility icon could essentially act to "solo" the channel, and perhaps auto-frame it as well (or maybe that gets hooked up to a different combo). It could act as a kind of "I want to focus on this channel" command.

I'm not specifically suggesting ctrl-click as the best option. It's just an example. But something along these lines would give fast single-click access to the behavior demonstrated in the gif, without interfering with normal channel selection behavior.

All-in-all, I think the behavior is useful. But I strongly urge people to think about solutions that keep standard selection behavior decoupled from other behaviors. Selection shouldn't have side-effects.

Note: this currently seems more like a design task.

If this needs a lot more discussion - maybe good to make it into one, otherwise, would like to know when the code is ready for review.

If we cant get the auto-hide unselected channels behavior approved...

-Can we at least move forward the "Auto focus selected channels" behavior?
-Can we at least have the option of disabling the selection of keyframes that are on channels that are not selected by the user. That way at least they are not getting in the way constantly

@Todor Imreorov (blurymind) - please dont make this into some argument about why blender should/shouldnt copy other software.

Features need to be considered in the context of Blender, that other software works a certain way is interesting to know.

But frustrated outbursts like this aren't welcome as replies to patch review.

I am sorry, I tried to support the idea that it is a design that has its merits and it is in fact liked by many users :)

Yeah, I think the point is reached where there is too much design noise in the Revision. I'll open a design task for this the next days so we can discuss this further there (I personally don't have the impression that something has been decided yet).

Hi guys, sorry for being late to provide feedback. Cessen, I figured that some users would balk at this functionality. It's inevitable. But keep in mind that this is toggle feature that probably shouldn't be enabled by default. Coupling selection with hiding isn't neccessarily required either since you can break the functionality into 2 options in we must ("auto-frame" and "auto-hide").

But it must be re-iterated that this is very useful behavior for the graph editor because it can really speed up channel tweaking. If I have 5 channels across 3 objects that I want to tweak together, I DO NOT want to have to spend countless seconds/minutes manully hiding, framing and unselecting the 150 channels in the graph editor before I can make meaningful tweaks to the 5 I want to edit. This feature just lets me select my 5 channels and boom. It's all ready for me to edit. And when I want to select another 8 channels, or go back to the previous 5, everything is just a simple selection away and it will always be framed up and ready.

Now, of course, if there is a use case where this auto behavior is undesirable, one can simply turn the feature off until it is needed again. Adding this feature does not nullify the workflow of others, which is why I've been very confused as to why there is so much opposition.

I agree with Fahr. It's exactly why I prefer working with that feature on.

To add to this:
The whole point of having "auto-focus" is not having to press the "home" key to frame our curves every time we select a channel. If you add the need to hold a modifier key, you are not changing much in that. Instead of pressing it, the user has to hold a button then. This is defeating the whole point.

Also it will get even more convoluted when you need to select multiple channels and frame their curves this way. Then you would have to hold two modifier keys?

So it is not "Auto" at all then. Still manual

@Chad Gleason (fahr)

I've been thinking about this more, and I might have another solution. What if instead of tying this new mode to selection, we instead tie it to clicking the visibility icon?

In other words, instead of the mode changing selection behavior to do something non-selection-related, this new mode would change the behavior of clicking on the "eye" icon. When you click on the eye, it hides the other channels and frames the f-curve of the clicked channel.

This is a pretty minor change from the current patch: instead of clicking on the channel name, you click on the eye icon. And it preserves selection behavior so it can still be used for other purposes without having to constantly switch in and out of this "mode".

This also has the benefit of there being a visual icon that can be used to communicate the current mode. The eye icons could be changed to something else when this mode is enabled so it's not invisible which mode you're in.

Would that be acceptable? I should say, I'm still not 100% happy with this solution, because it still doesn't feel like a clean, well-integrated UX design to me. But I think this would be a reasonable compromise...? And, frankly, the f-curves editor has already accumulated a fair bit of cruft as Bassm pointed out. So it could probably use a good UX spring-cleaning at some point anyway. We can figure out how to more nicely integrate all the current functionality (including this proposed functionality) UX-wise later during such a 'cleaning'. The f-curves editor is such a critical component of animation workflow that it is, of course, important to get right!

Now, of course, if there is a use case where this auto behavior is undesirable, one can simply turn the feature off until it is needed again. Adding this feature does not nullify the workflow of others, which is why I've been very confused as to why there is so much opposition.

I'm a big fan of this quote by Antoine de Saint-Exupery:

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

IMO it is highly applicable to UX design as well.

Blender has historically had an enormous problem with throwing more and more options/modes at UX problems. A single option/mode isn't a big deal, but cumulatively they become a usability hazard and create a lot of cognitive overhead for the user (i.e. always having to keep in your head what options/modes are currently set, rather than using that brain power for the task at hand). I think Bassam and I are both concerned about option/mode bloat for that reason. And much like passing laws in politics, once options are in place they are exceedingly difficult to remove even if that later turns out to be the best (or least-bad) decision.

Note that neither me nor Bassam are saying that the functionality isn't useful. Rather, we're trying to find different ways to go about it that (hopefully) result in a cleaner, more unified user experience. I think both of us are also trying to start a conversation to hopefully come up with even better solutions than what either of us have proposed.

@Todor Imreorov (blurymind):

The whole point of having "auto-focus" is not having to press the "home" key to frame our curves every time we select a channel. If you add the need to hold a modifier key, you are not changing much in that. Instead of pressing it, the user has to hold a button then. This is defeating the whole point.

That seems rather hyperbolic to me. Reaching for the Home key after a click and Ctrl-clicking are very different.

Case in point: 3d view navigation in Blender involves frequent use of both the Ctrl and Shift keys. And in Maya etc. it involves use of the Alt key. I would hardly consider those to be high-overhead mouse/hotkey combos. You're hands are generally near the modifier keys anyway, and muscle-memory makes their usage extremely efficient.

Reaching for the home key, on the other hand, takes far more time and involves full hand-eye coordination because you're reaching across the entire keyboard.

Ugh, that's very sad to hear Severin. Hopefully this can be picked up again in the near future.

@Nathan Vegdahl (cessen)
I don't want to sound close minded, I'm certainly not. And I appreciate the desire not to clutter up an interface that already feels pretty cluttered at times.

However, my stance is to maintain the purpose of the mode, however it may be implemented. The purpose of the mode is allow a form of selection and curve editing that is comfortable and effortless. An alternate way to edit, if you will. Your suggestion requires me to approach the graph editor in a less intuitive manner. Instead of selecting channels, I'm selecting the eye icons and holding down a modifier key at the same time. Not a big deal really, but not really intuitive. Additionally, it adds a lot of additional wrist strain and potential confusion when I know that this is ONLY way I'm going to be editing in the graph editor. Seriously, if this feature was in master it would be the most common way I use the graph editor. I've been a Maya animator for years and 90% of the time, I have this mode checked on. So in my case, almost every time I edit in the graph editor, I am now forced to hold down additional modifier keys for every channel I click on.

I'm not saying that we should implement it just because it's in Maya, but this feature has been tried and tested and it's preferred by many animators I know (its also not the only way to edit there, either). In Maya, its a toggle mode in a settings menu loaded with other options and no one complains. Keep in mind, this mode is in a blender menu that's specifically for graph editor view settings. I only go to this menu when I want to edit view settings. I really dont care if the settings menu is cluttered as long as each option does something meaningful. The only area where i hate clutter is if the settings are not logically organized or I have too many buttons out in the UI. This setting would not really adversely affect those areas.

So I guess the short version, is that I think this feature is already implemented correctly and the option is in the most logical spot. What really needs to be addressed is the cluttered view menu in the graph editor. Really, all it needs is a little nesting and clean up. Right now there is not one nested menu in there. It's just a long list of individual options. It's frustrating to see this feature get axed at the finish line because of fear of menu clutter. Please add the feature, and then we can address the menu clutter next.

Just my 2 cents. I really do appreciate the discussion. I hope I'm not coming off as some know-it-all because I have great humility and respect for what you and the devs have accomplished.

well then,
lets just continue the conversation at https://developer.blender.org/T43933