pattr feature request: multiple bindings

Nov 29, 2006 at 10:44am

pattr feature request: multiple bindings

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

#28955
Nov 29, 2006 at 11:27am

What about a GUI object (abstraction in bpatcher) that contains the various number boxes and has only 1 in- and 1 outlet?

Cheers,
Mattijs

#89470
Nov 29, 2006 at 11:31am

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.

#89471
Nov 29, 2006 at 11:54am

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
>

#89472
Nov 29, 2006 at 4:06pm

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.
>

#89473
Nov 30, 2006 at 7:06am

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

#89474

You must be logged in to reply to this topic.