(2.92) Is there a way to temporarily disable a driver without erasing it, BUT also adjust the parameter the driver is attached to manually?
(Previous ‘answers’ seem to indicate that the disable/mute function has this shortcoming of not allowing you to change the underlying parameter when the driver is disabled.)
Using nodes usually is more flexible but it depends of what needs to be driven and by what. I just recommend you to try out Animation nodes, its great.
Disabling the driver doesn’t make anything un-editable. (And if it did, edit then disable-- if its disabled, you’re not tuning to eye anyways.)
Open a driver editor viewport. Select your object. Select your driver, on the left hand margin of the driver editor. Next to your driver, there’s a checkbox, with a tool tip labelled something like “contribute to f-curve.” Uncheck that box. If desired, continue on to edit your driver (probably, using the sidebar on the driver editor viewport.)
In this case, I’d like to toggle between the driven state and the undriven state to take a quick look at the undriven value at different points in the timeline, so as to better adjust the expression within the driver.
Basically, I want to skip any typing from toggling back and forth, since there’s a PITA expression inside the driver.
So, does this “contribute to f-curve” box essentially function as a enable/disable toggle?
+++++ EDIT
This link shows a ‘speaker’ icon that apparently “mutes/unmutes” a driver, but it’s a further down the rabbit hole than I know how to follow.
I post it just as a point of interest. (Also, it’s from 2017 so it may not apply any longer.)
You should try it out and see.
OK, the checkbox seems to have replaced the little speaker (which IMO was cuter). There IS a behavior that I find surprising, but neutral, and that other users may find convenient and/or useful:
it seems that when you disable the driver, whatever the last evaluated value for that particular frame is retained in the parameter as a constant. IOW, the driver stops working but the last evaluated value stays. SO, users must be aware of what frame they are on before clicking that box willy-nilly. AND, do NOT expect to see a visible change in something’s behavior when toggling the checkbox (that was what was throwing me).
If that’s the case I can see how it might be (very?) useful in settling on a particular value before deleting a driver.
I’m still a little blurry on the difference between the little wrench and the checkbox but I’m sure (ha!) it’ll all be clear eventually.
If you have keyframes for the object, the object will be reset to keyframed values. If you don’t, disabling the driver doesn’t do anything to restore a position (or whatever)-- there is no position to restore without keyframes, only where it is.
But a user might (did) expect that a value manually entered in the field before the driver was applied would re-appear when the driver is disabled.
Of course! I’m not going to deny anyone their expectations 