pattr feature request: multiple bindings


    Nov 29 2006 | 10:44 am
    Hi,
    I have a feature request for pattr. What happens a lot is I use a
    pattr to store a list, and a series of numberboxes to edit those list
    values. This is very clunky, because I need to connect all the
    numberboxes to a pack object that goes into the pattr, and coming out
    of pattr need an unpack object and then multiple [prepend set]
    objects coming from those outlets and back into the original
    numberboxes. What might make my life easier would be to specify a
    list of GUI objects in the @bindto of pattr, and then have pattr
    automatically understand that what I want it to store is a list of
    values corresponding to each of those GUI objects, in the order in
    which I typed them.
    Of course, I could create a separate pattr for each GUI object, but I
    don't like doing that because then I have pattrs all over my patches,
    and cluttering up the clientwindow and storagewindow of
    pattrstorage. Data gets unwieldy very fast, and lists are useful for
    keeping things readable.
    If anyone has other solutions, I'd love to hear them.
    Best
    Evan

    • Nov 29 2006 | 11:27 am
      What about a GUI object (abstraction in bpatcher) that contains the various number boxes and has only 1 in- and 1 outlet?
      Cheers,
      Mattijs
    • Nov 29 2006 | 11:31 am
      Thanks for your input. I understand why you want such a feature, but
      I feel like it's unnecessary, since with a little patching, you can
      do what you want. My personal feeling about Max objects is that they
      should be as dumb and simple as possible, and only anticipate user
      needs to the extent that this basic functionality is easy to use.
      This is why Max is made up of lots of little objects which are pieced
      together to create useful structures.
      Every so often there's a push from various users to start packing
      lots of "intelligent" functionality into objects, or to turn simple
      patches into objects ("why isn't there an object that separates a
      number into its constituting digits?", for instance). From my
      perspective, this should be resisted. If there is a case where
      something is actually impossible, I'm all for adding objects or
      features. But in cases where something is merely inconvenient, I'm
      less sympathetic.
      To your suggestion: If Max had the means to dynamically create lists
      from the values of named objects, that would be interesting. For
      instance, in a message box: [ $my::named::object ], or
      [ $my::named::object $my::other::object ]. Or even [ $some::value *
      $other::value ] (this gets complicated, though -- what happens when
      the values contain more than 1 number, or a symbol?). These are
      features that don't exist yet, but that we've thought about and
      discussed at various points. Maybe you'll see them in a future
      version. But, then again, maybe not...
      Anyway, we do appreciate your input and your interest in improving
      Max. By all means feel free to fight for your favorite missing
      features: we pay attention and take note, even if our priorities and
      ideas for future directions aren't always a perfect fit with yours.
      jb
      Am 29.11.2006 um 11:44 schrieb evan.raskob [lists]:
      > I have a feature request for pattr. What happens a lot is I use a
      > pattr to store a list, and a series of numberboxes to edit those
      > list values. This is very clunky, because I need to connect all
      > the numberboxes to a pack object that goes into the pattr, and
      > coming out of pattr need an unpack object and then multiple
      > [prepend set] objects coming from those outlets and back into the
      > original numberboxes. What might make my life easier would be to
      > specify a list of GUI objects in the @bindto of pattr, and then
      > have pattr automatically understand that what I want it to store is
      > a list of values corresponding to each of those GUI objects, in the
      > order in which I typed them.
    • Nov 29 2006 | 11:54 am
      that's a good idea.
      still, i bet doing it all inside pattr would be more efficient and
      easy to use. but for now, i may just go with your idea.
      thanks
      evan
      On Nov 29, 2006, at 11:27 AM, Mattijs Kneppers wrote:
      >
      > What about a GUI object (abstraction in bpatcher) that contains the
      > various number boxes and has only 1 in- and 1 outlet?
      >
      > Cheers,
      > Mattijs
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Interactive audiovisual sampling soft- and hardware
      >
    • Nov 29 2006 | 4:06 pm
      Thanks for your reply. FWIW, I do agree with you that the basic
      objects should be *basic*.
      I like the idea of Max dynamically creating lists out of max objects
      via message boxes. It raises a lot of question, and adds that
      possibility of recursion, which is always complicated but sometimes
      very beautifully simple. I don't have anything else useful or
      practical to add to that discussion right now, though.
      Kind of related - there has always been this part of me that feels
      limited by the "physicalness" of max objects (not counting poly~ and
      javascript), which sometimes feels like a strange limitation on what
      are otherwise virtual objects. Sometimes that distinction make
      sense, though, as when I'm modeling actual, physical things. Maybe
      defining recursive (objects of objects) are a way around that. Like
      defining a "list of all lists that aren't part of any list"? ;)
      Looking forward to seeing what you guys have been cooking up.
      cheers
      evan
      On Nov 29, 2006, at 11:31 AM, Jeremy Bernstein wrote:
      > Thanks for your input. I understand why you want such a feature,
      > but I feel like it's unnecessary, since with a little patching, you
      > can do what you want. My personal feeling about Max objects is that
      > they should be as dumb and simple as possible, and only anticipate
      > user needs to the extent that this basic functionality is easy to
      > use. This is why Max is made up of lots of little objects which are
      > pieced together to create useful structures.
      >
      > Every so often there's a push from various users to start packing
      > lots of "intelligent" functionality into objects, or to turn simple
      > patches into objects ("why isn't there an object that separates a
      > number into its constituting digits?", for instance). From my
      > perspective, this should be resisted. If there is a case where
      > something is actually impossible, I'm all for adding objects or
      > features. But in cases where something is merely inconvenient, I'm
      > less sympathetic.
      >
      > To your suggestion: If Max had the means to dynamically create
      > lists from the values of named objects, that would be interesting.
      > For instance, in a message box: [ $my::named::object ], or
      > [ $my::named::object $my::other::object ]. Or even [ $some::value *
      > $other::value ] (this gets complicated, though -- what happens when
      > the values contain more than 1 number, or a symbol?). These are
      > features that don't exist yet, but that we've thought about and
      > discussed at various points. Maybe you'll see them in a future
      > version. But, then again, maybe not...
      >
      > Anyway, we do appreciate your input and your interest in improving
      > Max. By all means feel free to fight for your favorite missing
      > features: we pay attention and take note, even if our priorities
      > and ideas for future directions aren't always a perfect fit with
      > yours.
      >
      > jb
      >
      > Am 29.11.2006 um 11:44 schrieb evan.raskob [lists]:
      >
      >> I have a feature request for pattr. What happens a lot is I use a
      >> pattr to store a list, and a series of numberboxes to edit those
      >> list values. This is very clunky, because I need to connect all
      >> the numberboxes to a pack object that goes into the pattr, and
      >> coming out of pattr need an unpack object and then multiple
      >> [prepend set] objects coming from those outlets and back into the
      >> original numberboxes. What might make my life easier would be to
      >> specify a list of GUI objects in the @bindto of pattr, and then
      >> have pattr automatically understand that what I want it to store
      >> is a list of values corresponding to each of those GUI objects, in
      >> the order in which I typed them.
      >
    • Nov 30 2006 | 7:06 am
      evan.raskob [lists] wrote:
      > Of course, I could create a separate pattr for each GUI object, but I
      > don't like doing that because then I have pattrs all over my patches,
      But almost all GUI object can bind directly to autopattr, no need for
      pattr objects.
      > and cluttering up the clientwindow and storagewindow of pattrstorage.
      Of course that would remain, but I wouldn't mind...
      > Data gets unwieldy very fast, and lists are useful for keeping things
      > readable.
      If the way of thinking is lists, I use multislider, and if the way of
      thinking is single parameters, even if I combine them into a list, I'd
      store them seperately with number boxes for example...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com