This situation – a single value with multiple UI representations – really calls for Model-View-Controller design. It takes a while to fully understand the design, but the payoff for understanding it is that, thereafter, you avoid many types of design mistakes and you can move more quickly toward a complex GUI and have fewer bugs along the way.
(If you’re trying to hack up the design by yourself, you’re unlikely to improve on MVC accidentally – trust me, it’s better to start with a solid design and adapt where needed.)
Last summer, this question came up and I wrote up a quick MVC demo: Good practice with repetitious GUI design - #2 by jamshark70 – which means I don’t have to rewrite it here 
One of the main design points is that you need an object to represent the value. You said “the midi function is called when a rotary moves, so polling the controller for a value isn’t a valid action to take” and this is true – polling a control device is a bad idea. A good idea is to have an object that holds the value – the Model. Then, anywhere in the code that has access to the Model object can read the current value from this object.
The Model is distinct from all control devices (including UI widgets).
Control devices simply, and only, set a new value in the Model. Control devices should not directly affect any other control device.
The Model broadcasts an update (.changed) – so it doesn’t have to know which GUI(s) is/are listening to it. “Controller” objects (“controller” here as an element of the design, not as a physical control device) register to receive these updates, and update the graphical display. If you are sending data to a MIDI controller, then… yep… the same design applies: a MVC Controller gets updates from the Model and sends MIDI.
For a long time, I’ve thought that GUIs should only be shown on top of functionality that is completely implemented in terms of code calls. GUIs (IMO) should never serve as essential glue. When you wrote “create a gui slider with an action to set the midi controller value, and set the mididef to update the gui slider, and they will mutually update each other,” IMO that’s a design error. A better design would be:
- MIDIdef calls
value =on the Model. - GUI slider calls
value =on the Model. - Model broadcasts and both the MIDI and GUI MVC Controller objects receive and forward.
Now, you can programmatically change the value from anywhere, with or without a GUI (and the GUI will update when it’s present).
Again, my opinion, take it or leave it, but I’ve been doing this for a long time… IMO, if it’s a very small, simple GUI, it’s fine to hack up a simpler design, but when things get more complicated (such as in my system, where I have an onscreen window with sliders being mirrored in an Open Stage Control interface on a tablet), if you want things to work cleanly, start with a solid design.
hjh