2 UI-related feature requests

Apr 10, 2007 at 11:33am

2 UI-related feature requests

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

#31279
Apr 10, 2007 at 12:12pm

Is max 5 under heavy development right now?

#101420
Apr 10, 2007 at 2:32pm

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:

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

and then use a bpatcher with this in it:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 46 187 32 196617 print;
#P newex 83 164 178 196617 sprintf script size mybpatcher %i %i;
#P newex 83 187 112 196617 send Main-Thispatcher;
#P user jsui 57 121 330 26 1 0 0 sizer.js;
#P newex 83 82 87 196617 loadmess getSize;
#P fasten 3 0 4 0 88 184 51 184;
#P connect 3 0 2 0;
#P connect 1 0 3 0;
#P connect 0 0 1 0;
#P window clipboard copycount 5;

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.

#101421
Apr 10, 2007 at 2:57pm

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

#101422
Apr 10, 2007 at 3:35pm

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

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…

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

#101423
Apr 10, 2007 at 3:55pm

#101424
Apr 14, 2007 at 4:36am

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

Yes agreed…

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

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

This is probably also possible with js though…

Stefan


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

#101425
Apr 14, 2007 at 10:52am

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

no jamez, they make max 6 first.

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.

#101426
Apr 14, 2007 at 10:56am

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

#101427
Apr 14, 2007 at 11:55am

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

#101428
Apr 14, 2007 at 1:31pm

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.

Best,
Julien.

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

#101429
Apr 14, 2007 at 1:41pm

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

http://www.estatesound.com/matsui.html

Best,
Julien

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

#101430
Apr 14, 2007 at 2:45pm

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.

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

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

#101431
Apr 16, 2007 at 9:07am

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


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

#101432
Apr 16, 2007 at 9:08am

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…

Stefan


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

#101433
Apr 16, 2007 at 11:55am

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…

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

#101434
Apr 16, 2007 at 7:54pm

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

#101435
Apr 17, 2007 at 1:07am

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

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

#101436
Apr 17, 2007 at 2:39am

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:

#P bpatcher 200 234 160 150 -10 -55 PatcherName.pat 0 arg1 arg2;

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]

-C


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

#101437
Apr 17, 2007 at 4:40am

#101438
Apr 17, 2007 at 9:02am

#101439
Apr 17, 2007 at 9:32am

okay, so i see now why this request.

danmed true Dan that it is getting difficult with many
very small bpatchers.
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
“1217/433″

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
in max in general.

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

if there would be a funtion inside maxmsp called
“seach for “20″ in all lines starting with “#P bpatcher” “
that would make things easier.

#101440
Apr 17, 2007 at 12:41pm

I agree with Roman, that although Chris’ suggestion to use a text
editor to tweak the bpatchers’ sizes is a good one, it’s too clunky
for me to think about using on a regular basis.

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

#101441
Apr 18, 2007 at 11:23am

Dan Nigrin schrieb:
> I agree with Roman, that although Chris’ suggestion to use a text editor
> to tweak the bpatchers’ sizes is a good one, it’s too clunky for me to
> think about using on a regular basis.

I think this whole request should be easily achievable with js, place
two named objects, lets say upleft and loweright, let the js find their
positions, then resize its parent according to that info. No more
restore origin necessary after that….

I would not trigger the resizing on loadbang though, this is only
necessary while patching, once its set, its fine, trigger with a global
[r esizebpatchers] or something…

I am not fluid enough in js to do it in five minutes, but with the
existing examples it should be possible to hack it together…

Stefan


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

#101442
Apr 18, 2007 at 10:09pm

Quote: Stefan Tiedje wrote on Wed, 18 April 2007 23:23
—————————————————-
> I think this whole request should be easily achievable with
> js, place two named objects, lets say upleft and loweright,
> let the js find their positions, then resize its parent
> according to that info.

Further: connect a patchergs object to the js object.
Then the named object(s) to use as size reference could then be inherited from @TL and @BR attributes supplied to the bpatcher. So you’re not dependent on specific names…

#101443
Apr 19, 2007 at 10:05am

John Pitcairn schrieb:
> Further: connect a patchergs object to the js object. Then the named
> object(s) to use as size reference could then be inherited from @TL
> and @BR attributes supplied to the bpatcher. So you’re not dependent
> on specific names…

but naming two objects in the main patcher once, is much less hassle
than adding arguments to a bpatcher…
And specific names don’t hurt at all for this purpose…

Stefan


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

#101444

You must be logged in to reply to this topic.