[PD-dev] displaying when an arg has been overridden

[Luke Iannini (pd)]

In response to Frank's last message (I went to dinner and haven't read
the rest yet):
Argument accepted.  It would also cause trouble for saving patches, as
it would introduce the assumption that the last value received would
be saved.

Alternately though it might be nice to at least "bracket" the defaults
somehow to separate them from the object name a little more.  And I
also agree with Hans that color is always neglected in many
applications, and could be used to great utility in Pd.  As an
example, coloring the patch cords when data is being sent would reduce
the necessity of attaching bangs to monitor activity.

On 6/24/06, padawan12 <padawan12 at obiwannabe.co.uk> wrote:
> All great ideas. This really needs a separate mode, kinda "debug" mode as
> Georg mentioned. Problem with updating values in the object is they might
> be extrememly large or small. How to display that is a problem, we don't
> want objects shrinking and growing in length, yet truncating values might
> be misleading.
>
> An couple of ideas I had for debug are:
>
> to have a "sniff" cursor. When you hold it on a connection or outlet it
> displays a small box with the type and values of data flowing in the
> pipe in a time ordered list. When you release the mouse it freezes and
> the box remains until you do something to dispose of it.
>
>  [object that does something]
>   |          |             |
>   |          |             |
>   |          |             X<-[ type: float value 1.3425e-11 ]
>                               [ type: bang  value: null      ]
>                               [ type: symbol value: "clicked"]
>
> Extending this principle, I quite often want to sniff audio signals
> as I work down a flow, a cursor mode that just grabs what is there
> straight to the DAC (or video window for you GEM freaks) would be
> mighty useful. Actually having it route to a named send~/receive~
> would be best so I could decide how to handle it with a compressor
> or pop it up on an attenuated desk channel. Right now I find the
> only way to debug is to make and break lots of temporary connections.
>
> Another idea is taken straight from standard fare code debugging, to
> have a single step or breakpoint. Right now I do this with a conditional
> that bangs a [;dsp 0] but for obvious reasons it's less than ideal.
>
> Just crazy thoughts...
> Andy
>
>
> On Sat, 24 Jun 2006 02:09:01 +0000
> carmen <_ at whats-your.name> wrote:
>
> > > 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)|
> >   -=---------
> >
> > 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(
> >
> > cc
> >
> > _______________________________________________
> > PD-dev mailing list
> > PD-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>