lists@lowfrequency.or

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 

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 

If anyone has other solutions, I'd love to hear them.

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.

pattr-feature-request-multiple-bindings

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

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 

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 

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 

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.

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 

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.

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


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.

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?

> Interactive audiovisual sampling soft- and hardware

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.

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


Thanks for your reply. FWIW, I do agree with you that the 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.

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 

> 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 

> 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 

> 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 

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"? ;)

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


> 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 

> 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 

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

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.  

> 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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


pattr feature request: multiple bindings