The above suggestion was updated with an example image

The arrows in the accompanying picture indicate the direction in
which the applied force extends, either push, or pull, rather than the
obscure method currently employed.

As a secondary note, for anyone with a mechanical background,
although a spring *can be used for both push and pull, springs are
manufactured specifically for each use, almost exclusively so...It is
not good science or programming to confuse matters, whether by
arbitrary decision or by ignorance of the underlying mechanisms.

re: this post. it's been over a month and the development team has been completely silent.

regarding band ID for the sliders:

one could "glow" the band when/while it's controls are in focus to
simplify the system using the highliting feature already present ingame
and currently only used to id selected residues and side chains. This
might be the easiest method to use...I think lol

alternatively, mouseover functions could be used to do much the
same, where a pop up on the control tells you it's use and a companion
marker pops up to show the target band.

regarding the example control window shown in the pics above
(original post), the second one was created after Judecca suggested
that the up/down arrows were a bit confusing. I tend to agree and
applied the markers that he suggested to me although they may need to
be tidied to make them sharper/more infocus.

Looks like a good thing to add once the Inventory system is set up. ;)

Although, given how complicated the suggested solution is, I wonder if there is a deeper underlying problem to the interface that should be discovered and addressed. If constant-strength rubber bands are not sufficient for the problems you are trying to solve, perhaps the most elegant and appropriate solution would look nothing like rubber bands at all. Where do you imagine you'd need real-time rubber band control?

and I quote:

" An example purpose would be anchoring helices. In this example, a
"player" could dynamically balance the spring force exerted upon the
helix in direction X by applying a band, starting a wiggle, and
adjusting the band strength in realtime until equilibrium is achieved.

Note: one would then note the strength setting, apply undo, set the band and wiggle...voila...

A logical conclusion one might make about secondary effects of this
display/control option would be the realtime control of band strength
towards direct compact(ion) or repulsion of a given structure."

like "new best" (recent best), other players will find ways to use
it that I have not thought of. Steve Pletsch and ZedicusZorander...
just reported that they were already able to use it to reduce the
mental load while doing rebuilds by using a set and forget approach by
purposefully lowering the score, setting recent best, and then
rebuilding for a time...then coming back and hitting restore recent
best.....a brilliant use I had not specifically anticipated but was
fortunately covered by the suggestion i have been forwarding for the
last six plus months.

Aside from the two specific examples I used above, I have a gut
feeling that will be the case for realtime bands once they are in the
hands of the player, just as I once did for band direction control and
other concepts (the dreaded R bug is all my fault for instance, because
i originated and recommended the idea for realtime band removal). But
it has also become a fundamental corner stone of certain folding
strategies (i think that's the word they use...strategies...although
i'm not sure if it's end game or mid game or whatever stage they've
named)

the idea of continuously variable strength/etc is really quite
simple...it is robotics at the very core. in this case...molecular
robotics. apply strength to overcome inertia, then back off...apply a
force of sufficient magnitude to hold but not exceed an inertial damper
like sheer size or stress as an anchor...these are transparent I
believe. One could even easily envision downstream addition of
modulation sources for the purposes of dithering, ie, stiction control.
The jiggle you know?... sq.sine.tri amplitude.freq, impulse duty
cycle...blah blah blah......all pretty basic stuff. Although I don't
expect you to construct a function generator lol (hmm though it
wouldn't actually be very hard really...code is already out there for
the taking in publicly owned algorithm trusts...)

I think the basic construct of the rubber band is a
perfectly good method for describing the basic function and purpose. I
just think its ability could be improved and therefore, folds. 

And I'm not so sure it's really very complicated.

The
variables, for the most part, already exist. The development
environment should include a layout tool for creation of windows and
abilities to assign modal.non modal status for moveability of the
window. The sliders are already in play and simply need moving to the
window. the governing equation should be nothing more than a magnitude
and sign already.  the ability to turn on and off is already evidenced
in the present slider control (disable).  yes, applying some highlite
function would constitute additional footwork, as would some of the
other details, but I think that when you analyze what's already done
and what needs to happen to actualize the concept, it's more a matter
of creating a series of duplicate controls in a non modal window of
appropriate dimension and linking their control variables to the
existing variable names and or indices.

I'm not saying there
isn't work involved, just that most of the ground work has been laid at
the lowest level of code already by the development team, or we would
not have any control of the rubber bands in the present iteration of
the software...

 there..that was far more information jabber babble banter than you expected desired, wasn't it?

Closing.