Zitat von carmen _@whats-your.name:
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
under your scheme, if the patch is even remotely alive, much of it is going to turn red right after opening
what about displaying the init value in black, and the current value in red or green, depending on whether its rising or falling
eg _=___=___ | osc~ 440| | 557| | (hz)| -=---------
hmm, that is a good example: [osc~]s inlet is basically a signal inlet: if you send a message [float 557( to it, it actually receives a signal with all samples set to 557.0f. should we display all values for the entire sample block or just the first value?
or something (i even forget if osc~ has one outlet its been so long since i touched pd) clicking on 440 would reset it (so you dont need to cluter the patch with an extra [440(
do i understand you correctly, that you want to replace a clickeable area which is 100% controllable by the user by another clickable area which is predefined in order to make things less cluttered?
you can do a lot of things with gop objects. for a (non-working) example see the attachment; this example brings to my mind, that it would be far more important to make abstractions equal to externals and vice versa (e.g. the "default signal" is missing in abstractions)
in understand the need for an "inspector" of the current value. personally i would prefer to inspect things on demand over a permanent notice of what goes on in my patch (in the best of worlds i know what is going on)
mfga.sdr IOhannes