Dan Nigrin

To the Cycling elves, as you are feverishly working on Max 5:

Feature Request #1: Ability to group/ungroup clusters of UI (or any?) objects.

Feature Request #2: When selecting a patcher to use in a bpatcher, 

allow one to select a named object in that patcher, to whose size the 

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 

Feature Request #1:  Ability to group/ungroup clusters of UI (or any?) objects.

Feature Request #2:  When selecting a patcher to use in a bpatcher, 
allow one to select a named object in that patcher, to whose size the 
bpatcher snaps to.

Thanks,
Dan
-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


2-ui-related-feature-requests

Is max 5 under heavy development right now?

Yes, they're working on max 5 now. I don't really know much about it, pity.

I might use the first requested feature, and it certainly wouldn't hurt people who don't use it.

The second feature I have more doubts about. What you want to do can be made in a way (for example, an empty jsui object with a getSize function in it. Use the output to script the bpatcher size) I tried it out, here's the jsui, save as sizer.js:

I agree, it's a lot more work, and you'll have to make the jsui the same size as the gui element. However, i'm not entirely sure if just convenience is enough reason for a separate object or function in Max (yes, idealist).

I wouldn't mind if cycling made the second feature also (i'd use it), but I don't think it will be high on their priority list. There are a couple other things about bpatcher which are more important in my opinion.

function getSize(){
outlet(0, sketch.size);
} 

I agree, it's a lot more work, and you'll have to make the jsui the same size as the gui element. However, i'm not entirely sure if just convenience is enough reason for a separate object or function in Max (yes, idealist). 

I wouldn't mind if cycling made the second feature also (i'd use it), but I don't think it will be high on their priority list. There are a couple other things about bpatcher which are more important in my opinion.


I'm fairly certain the 2nd feature is already implemented as JS in jamoma.

>I wouldn't mind if cycling made the second feature also (i'd use 

>it), but I don't think it will be high on their priority list. There 

>are a couple other things about bpatcher which are more important in 

Thanks for the little JSUI hack, nice trick.

My thought re: this feature request was that it would hopefully be a 

relatively easy thing for Cycling to implement. I agree it's simply 

for convenience, but in general, when I find myself doing things over 

and over again in Max, it strikes me that the overall usability will 

increase a lot if that little convenience is there...

>I wouldn't mind if cycling made the second feature also (i'd use 
>it), but I don't think it will be high on their priority list. There 
>are a couple other things about bpatcher which are more important in 
>my opinion.

My thought re: this feature request was that it would hopefully be a 
relatively easy thing for Cycling to implement.  I agree it's simply 
for convenience, but in general, when I find myself doing things over 
and over again in Max, it strikes me that the overall usability will 
increase a lot if that little convenience is there...

> Feature Request #1: Ability to group/ungroup clusters of UI (or

> Feature Request #2: When selecting a patcher to use in a bpatcher, 

> allow one to select a named object in that patcher, to whose size the

> My thought re: this feature request was that it would hopefully be a 

> relatively easy thing for Cycling to implement. I agree it's simply

> for convenience, but in general, when I find myself doing things over

> and over again in Max, it strikes me that the overall usability will 

> increase a lot if that little convenience is there...

Is it possible, that you didn't come across prototypes yet?

Whenever I have a bpatcher that I use more often, I create a bpatcher 

prototype, and that is much much more convenient than your request...

But for the bpatcher I have a feature request: an object that allows to 

resize objects inside the bpatcher according to the size of the 

bpatcher: for example have a slider adapt to the size of the bpatcher.

Then if the first request for grouping is implemented, this could be 

This is probably also possible with js though...

Dan Nigrin schrieb:
> Feature Request #1:  Ability to group/ungroup clusters of UI (or
> any?) objects.

> Feature Request #2:  When selecting a patcher to use in a bpatcher, 
> allow one to select a named object in that patcher, to whose size the
> bpatcher snaps to.

> My thought re: this feature request was that it would hopefully be a 
> relatively easy thing for Cycling to implement.  I agree it's simply
> for convenience, but in general, when I find myself doing things over
> and over again in Max, it strikes me that the overall usability will 
> increase a lot if that little convenience is there...

Is it possible, that you didn't come across prototypes yet?
Whenever I have a bpatcher that I use more often, I create a bpatcher 
prototype, and that is much much more convenient than your request...

But for the bpatcher I have a feature request: an object that allows to 
resize objects inside the bpatcher according to the size of the 
bpatcher: for example have a slider adapt to the size of the bpatcher.
Then if the first request for grouping is implemented, this could be 
enhanced to the spacing of the group...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Quote: jamez wrote on Tue, 10 April 2007 06:12

----------------------------------------------------

> Is max 5 under heavy development right now? 

i have a request too: a small update to the rangeslider

which lets us set a 24 bit background color instead of that

when i think about it, this ugly look of rangeslider once

caused a 110-ish breakthrough in things GUI design.

i started abusing other objects, makeing god use of ubutton,

Quote: jamez wrote on Tue, 10 April 2007 06:12
----------------------------------------------------
> Is max 5 under heavy development right now?  
----------------------------------------------------

i have a request too: a small update to the rangeslider
which lets us set a 24 bit background color instead of that
shit pixel look.

when i think about it, this ugly look of rangeslider once
caused a 110-ish breakthrough in things GUI design.
i started abusing other objects, makeing god use of ubutton,
and working with lcd.


> But for the bpatcher I have a feature request: an object that allows to 

> resize objects inside the bpatcher according to the size of the 

> bpatcher: for example have a slider adapt to the size of the bpatcher.

> Then if the first request for grouping is implemented, this could be 

> enhanced to the spacing of the group...

> This is probably also possible with js though...

thats possible with sending messages to (named) objects.

didnt someone here do such bpatchers sliders around 200 or so?

> But for the bpatcher I have a feature request: an object that allows to 
> resize objects inside the bpatcher according to the size of the 
> bpatcher: for example have a slider adapt to the size of the bpatcher.
> Then if the first request for grouping is implemented, this could be 
> enhanced to the spacing of the group...
>
> This is probably also possible with js though...

didnt someone here do such bpatchers sliders around 200 or so?


>>Feature Request #2: When selecting a patcher to use in a bpatcher, 

>>allow one to select a named object in that patcher, to whose size 

>Is it possible, that you didn't come across prototypes yet?

>Whenever I have a bpatcher that I use more often, I create a 

>bpatcher prototype, and that is much much more convenient than your 

Prototypes would help me if I always wanted to use a bpatcher with 

the same size, and using the same patcher that it is linked to. What 

I find myself doing is using lots of bpatchers, of all different 

sizes, and all of which use different underlying patchers. So a 

>But for the bpatcher I have a feature request: an object that allows 

>to resize objects inside the bpatcher according to the size of the 

>bpatcher: for example have a slider adapt to the size of the 

This is sort of the inverse of what I am asking for; you want to 

resize the underlying objects based on the size of the bpatcher, I 

want to size the bpatcher based on the underlying named object (or if 

request #1 is satisfied, named group of objects).

>>Feature Request #2:  When selecting a patcher to use in a bpatcher, 
>>allow one to select a named object in that patcher, to whose size 
>>the
>>bpatcher snaps to.
>
>I don't see the need of that.
>
>Is it possible, that you didn't come across prototypes yet?
>Whenever I have a bpatcher that I use more often, I create a 
>bpatcher prototype, and that is much much more convenient than your 
>request...

Prototypes would help me if I always wanted to use a bpatcher with 
the same size, and using the same patcher that it is linked to.  What 
I find myself doing is using lots of bpatchers, of all different 
sizes, and all of which use different underlying patchers.  So a 
prototype won't help.

>But for the bpatcher I have a feature request: an object that allows 
>to resize objects inside the bpatcher according to the size of the 
>bpatcher: for example have a slider adapt to the size of the 
>bpatcher.

This is sort of the inverse of what I am asking for; you want to 
resize the underlying objects based on the size of the bpatcher, I 
want to size the bpatcher based on the underlying named object (or if 
request #1 is satisfied, named group of objects).

Dan
-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


Did you have a look at Matt Aidekman's jsui objects ? If I remember well, there's something called bpatch tab which may help. I wanted to have a closer look at it to make some panels which would fit the size of a patcher but don't have the time these days. I think Matt's solution could be a good start if not the solution.

Quote: Dan Nigrin wrote on Sat, 14 April 2007 13:55

> This is sort of the inverse of what I am asking for; you want to 

> resize the underlying objects based on the size of the bpatcher, I 

> want to size the bpatcher based on the underlying named object (or if 

> request #1 is satisfied, named group of objects).

Quote: Dan Nigrin wrote on Sat, 14 April 2007 13:55
----------------------------------------------------
>
> This is sort of the inverse of what I am asking for; you want to 
> resize the underlying objects based on the size of the bpatcher, I 
> want to size the bpatcher based on the underlying named object (or if 
> request #1 is satisfied, named group of objects).
>
> Dan


Sorry. Couldn't find the site while writing the message but finally found it. Here :

Quote: jln wrote on Sat, 14 April 2007 15:31

> Did you have a look at Matt Aidekman's jsui objects ?

Quote: jln wrote on Sat, 14 April 2007 15:31
----------------------------------------------------
> Did you have a look at Matt Aidekman's jsui objects ?


>Did you have a look at Matt Aidekman's jsui objects ? If I remember 

>well, there's something called bpatch tab which may help. I wanted 

>to have a closer look at it to make some panels which would fit the 

>size of a patcher but don't have the time these days. I think Matt's 

>solution could be a good start if not the solution.

Thanks - I've looked at Matt's stuff before, but will re-look at again.

At 3:31 PM +0200 4/14/07, jln wrote:
>Did you have a look at Matt Aidekman's jsui objects ? If I remember 
>well, there's something called bpatch tab which may help. I wanted 
>to have a closer look at it to make some panels which would fit the 
>size of a patcher but don't have the time these days. I think Matt's 
>solution could be a good start if not the solution.

> thats possible with sending messages to (named) objects.

> didnt someone here do such bpatchers sliders around 200 or so?

It was about getting the size of the bpatcher if you change it while 

patching, not about resizing the internal sliders, thats trivial once 

Roman Thilenius schrieb:
> thats possible with sending messages to (named) objects.
>
> didnt someone here do such bpatchers sliders around 200 or so?

It was about getting the size of the bpatcher if you change it while 
patching, not about resizing the internal sliders, thats trivial once 
you have that info...

> Prototypes would help me if I always wanted to use a bpatcher with the 

> same size, and using the same patcher that it is linked to. What I find 

> myself doing is using lots of bpatchers, of all different sizes, and all 

> of which use different underlying patchers. So a prototype won't help.

But what is the advantage, to type in the name of an object is so much 

more time consuming than just adjusting the size, and moving the 

viewpoint with cmd-shift with the mouse, also no need to prepare the 

Maybe you come across the problem that you're changing the origin of a 

patcher while developing, therefore there is the command "restore 

Dan Nigrin schrieb:
> Prototypes would help me if I always wanted to use a bpatcher with the 
> same size, and using the same patcher that it is linked to.  What I find 
> myself doing is using lots of bpatchers, of all different sizes, and all 
> of which use different underlying patchers.  So a prototype won't help.

But what is the advantage, to type in the name of an object is so much 
more time consuming than just adjusting the size, and moving the 
viewpoint with cmd-shift with the mouse, also no need to prepare the 
patcher with anchors...

Maybe you come across the problem that you're changing the origin of a 
patcher while developing, therefore there is the command "restore 
origin" in the view menu...

At 11:08 AM +0200 4/16/07, Stefan Tiedje wrote:

>>Prototypes would help me if I always wanted to use a bpatcher with 

>>the same size, and using the same patcher that it is linked to. 

>>What I find myself doing is using lots of bpatchers, of all 

>>different sizes, and all of which use different underlying 

>But what is the advantage, to type in the name of an object is so 

>much more time consuming than just adjusting the size, and moving 

>the viewpoint with cmd-shift with the mouse, also no need to prepare 

The advantage would come for me when I frequently adjust the size of 

the "target" object (the one I want to be displayed in the bpatcher) 

as I am developing. So just naming that object, and specifying it 

once in the proposed bpatcher inspector field where I could supply 

this name) would always keep the bpatcher size "in sync" with the 

size of the object, with no extra work...

>Maybe you come across the problem that you're changing the origin of 

>a patcher while developing, therefore there is the command "restore 

Yes, but see above - even if I don't move the origin when editing the 

patcher, I still have to do frequent resizes of the bpatcher 

At 11:08 AM +0200 4/16/07, Stefan Tiedje wrote:
>Dan Nigrin schrieb:
>>Prototypes would help me if I always wanted to use a bpatcher with 
>>the same size, and using the same patcher that it is linked to. 
>>What I find myself doing is using lots of bpatchers, of all 
>>different sizes, and all of which use different underlying 
>>patchers.  So a prototype won't help.
>
>But what is the advantage, to type in the name of an object is so 
>much more time consuming than just adjusting the size, and moving 
>the viewpoint with cmd-shift with the mouse, also no need to prepare 
>the patcher with anchors...

The advantage would come for me when I frequently adjust the size of 
the "target" object (the one I want to be displayed in the bpatcher) 
as I am developing.  So just naming that object, and specifying it 
once in the proposed bpatcher inspector field where I could supply 
this name) would always keep the bpatcher size "in sync" with the 
size of the object, with no extra work...

>Maybe you come across the problem that you're changing the origin of 
>a patcher while developing, therefore there is the command "restore 
>origin" in the view menu...

Yes, but see above - even if I don't move the origin when editing the 
patcher, I still have to do frequent resizes of the bpatcher 
currently...

Quote: Stefan Tiedje wrote on Mon, 16 April 2007 03:07

> > thats possible with sending messages to (named) objects.

> > didnt someone here do such bpatchers sliders around 200 or so?

> It was about getting the size of the bpatcher if you change it while 

> patching, not about resizing the internal sliders, thats trivial once 

yeah i got t hat wrong, but now i dont get dan

Quote: Stefan Tiedje wrote on Mon, 16 April 2007 03:07
----------------------------------------------------
> Roman Thilenius schrieb:
> > thats possible with sending messages to (named) objects.
> >
> > didnt someone here do such bpatchers sliders around 200 or so?
>
> It was about getting the size of the bpatcher if you change it while 
> patching, not about resizing the internal sliders, thats trivial once 
> you have that info...
>
> Stefan

yeah i got t hat wrong, but now i dont get dan


>yeah i got t hat wrong, but now i dont get danZs request anymore. :)

>what is so much work about resizing a bpatcher by hand? ...

I use many bpatchers, often very close together (e.g. vertical faders 

used in a "mixing board" kind of layout). I don't like to have my 

bpatcher's bounds extend far beyond the UI elements contained in the 

underlying patcher, because then it makes precise alignment between 

those multiple bpatchers more difficult. Therefore, I like to keep 

my bpatchers very "tight" around the underlying graphic elements. 

Doing that precisely is a pain, and I often make mistakes of a pixel 

or two, and that screws up the look of my layouts. Thus my request.

>yeah i got t hat wrong, but now i dont get danZs request anymore. :)
>
>what is so much work about resizing a bpatcher by hand? ...

I use many bpatchers, often very close together (e.g. vertical faders 
used in a "mixing board" kind of layout).  I don't like to have my 
bpatcher's bounds extend far beyond the UI elements contained in the 
underlying patcher, because then it makes precise alignment between 
those multiple bpatchers more difficult.  Therefore, I like to keep 
my bpatchers very "tight" around the underlying graphic elements. 
Doing that precisely is a pain, and I often make mistakes of a pixel 
or two, and that screws up the look of my layouts.  Thus my request.

At 9:07 PM -0400 4/16/07, Dan Nigrin wrote:

>Doing that precisely is a pain, and I often make mistakes of a pixel or two, and that screws up the look of my layouts. Thus my request.

While this isn't really what you asked for, don't forget text mode. If you're handy with a text editor, particularly one like BBEdit which has good search & replace, you can make wholesale changes fairly easily.

If you look at a line that creates a bpatcher:

first two numbers after the bpatcher are position [e.g. 200 234]

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

At 9:07 PM -0400 4/16/07, Dan Nigrin wrote:
>Doing that precisely is a pain, and I often make mistakes of a pixel or two, and that screws up the look of my layouts.  Thus my request.

first two numbers after the bpatcher are position [e.g. 200 234]
second two are size [160 150]
third two are offset [-10 -55]
Name of patcher [PatcherName.pat]
flags [0]
Patcher args [arg1 arg2]

-- 
Chris Muir           | "There are many futures and only one status quo.
cbm@well.com         |  This is why conservatives mostly agree,
http://www.xfade.com |  and radicals always argue." - Brian Eno


danmed true Dan that it is getting difficult with many

since i use a non-apple mouse on some machines i know

how it can hurt when pixel-excat editing doesnt work,

especially in maxmsp and photoshop i regulary shout at

my mouse when it refuses to let me move something to 

the suggested method to edit the bpatcher size using a

text editor seems close to a perfect solution ... but

it brings up the question how search-and-replace in

"text mode" could be done more easy while programming

i would use (external) text editing much more often if 

it would not always require you to save as text, close 

the patch, edit the text in bbedit, open the patch again 

and save it over its last version ... thats 5 annoying 

if there would be a funtion inside maxmsp called

"seach for "20" in all lines starting with "#P bpatcher" "

2 UI-related feature requests