[PD] Number atom box limits overstepped

[Ico Bukvic]

Pd-L2Ork offers this as a user-settable property.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu

ci.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Thu, May 11, 2023, 04:23 Peter P. <peterparker at fastmail.com> wrote:

> * João Pais <jmmmpais at gmail.com> [2023-05-11 09:18]:
> > Hello list,
> >
> > after all this time, I just noticed something which I'm not sure if it
> was
> > always like that or it changed without me noticing it: in atom boxes one
> can
> > define the lower/upper limits, which work when dragging with the mouse,
> but
> > don't work when inputting a number or sending a message - the numbers go
> > further. Since usually these limits are there to make sure that unwanted
> > information doesn't go further, wouldn't it make sense to make those
> limits
> > work on all cases?
> >
> > For what it's worth, I checked on Max and that's the behaviour there. It
> > seems strange to say "here are the limits, but in this and that situation
> > they're ignored".
> I guess the idea is that number boxes are transparent with regard to
> messages input into them, and that they will not act on the data
> according to something set (and hidden) in the properties dialog. You
> have a [clip] object for this functionality, with the added plus of
> making its function well visible.
>
> Peter
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20230511/fd1f8644/attachment.htm>