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