htonino

I was playing with the panel object. In one of the examples in the reference for this object a brgb message is sent to it using the prepend object. However, I am not able to find documentation for this message type for panel. Only the documentation for bgcolor mentions that "The bgcolor object's functionality is equivalent to a brgb message sent to thispatcher." So, what is the exact status of this brgb message and which objects accept this message type?

I was playing with the panel object. In one of the examples in the reference for this object a brgb message is sent to it using the prepend 

brgb-message

[panel] and [thispatcher] are two completely different objects.

objects which respond to brgb/frgb are lcd and jit.lcd and all GUI objects which can have a background color (panel, number, flonum, hint, waveform, scope, cellblock, filtergraph, spectroscope, signum, umenu, meter, function...)


[panel] and [thispatcher] are two completely different objects.

objects which respond to brgb/frgb are lcd and jit.lcd  and all GUI objects which can have a background color (panel, number, flonum, hint, waveform, scope, cellblock, filtergraph, spectroscope, signum, umenu, meter, function...)



Thanks for your reply, Roman, and clarifying which objects accept brgb (and frgb) messages. Of course, I understand that [panel] en [thispatcher] are different objects. But my point is that the documentation is not very clear about the brgb messages. Best, Hans

Thanks for  your reply, Roman, and clarifying which objects accept brgb (and frgb) messages. Of course, I understand that [panel] en [thispatcher] are different objects. But my point is that the documentation is not very clear about the brgb messages. Best, Hans

indeed, as it seems it is simply missing. 

https://docs.cycling74.com/max7/refpages/panel

or maybe there is even a good reason: they probably want new users to use "bgfillcolor" which supports transparency.

but brgb still works - undocumented - and if only for backwards compatibilty of old patches.

that the reference uses "brgb" in the example screenshot must be filed under "fun facts".


indeed, as it seems it is simply missing. 

https://docs.cycling74.com/max7/refpages/panel

should not, but can happen.

or maybe there is even a good reason: they probably want new users to use "bgfillcolor" which supports transparency.
but brgb still works - undocumented - and if only for backwards compatibilty of old patches.

that the reference uses "brgb" in the example screenshot must be filed under "fun facts".


One can set a line between max 4 and newer versions

in terms of GUI and messages that control it.

There are many leftovers that one can use halfway,

word about compatibility to older patches is a joke,

it simply does not work, or ends in wrong colors, unreadable menus etc. 

Messages to objects in "current" max versions

should be evaluated using attrui object connected to the object of interest.

One can set a line between max 4 and newer versions
in terms of GUI and messages that control it.
There are many leftovers that one can use halfway,
word about compatibility to older patches is a joke,
it simply does not work, or ends in wrong colors, unreadable menus etc.  
Messages to objects in "current" max versions
should be evaluated using attrui object connected to the object of interest.


Thanks for your answers. I found [attrui] already.

oh yeah, attrui is the way to get around these quirks, it never lies.

but go on using "old" messages, they wont be deprecated so soon. (this is one of the things which are really great with max)

what i hate is when sizes of objects change (mainly numbers, because it is not so easy to program your own numberboxes), the same issue is present with everything about fonts.

colors did until now (4-to-7 scenario) work fine for me - with meter~ as the main exception. (i have patches like "110.fix.meter~" in my max 4 install since a while, which are sending the required later-than-v4 messages to the object.)


oh yeah, attrui is the way to get around these quirks, it never lies.

but go on using "old" messages, they wont be deprecated so soon. (this is one of the things which are really great with max)

@source audio 

your experience is really that bad?

what i hate is when sizes of objects change (mainly numbers, because it is  not so easy to program your own numberboxes), the same issue is present with everything about fonts.

colors did until now (4-to-7 scenario) work fine for me - with meter~ as the main exception. (i have patches like "110.fix.meter~" in my max 4 install since a while, which are sending the required later-than-v4 messages to the object.)


Roman, my experience is really frustrating.

I allways used objects frame and color to signal the state in

which the function it executes currently is.

Indicating that using frame size, frame color, brgb, frgb color etc

messages is soooo helpful on the stage, one sees what is going on.

Now with all that fancy second gradient etc, no borders it is (sorry to say it that way) a bullshit.

Roman, my experience is really frustrating.
I allways used objects frame  and color to signal the state in
which the function it executes currently is.
Indicating that using frame size, frame color, brgb, frgb  color etc
messages is soooo helpful on the stage, one sees what is going on.
Now with all that fancy second gradient etc, no borders it is (sorry to say it that way) a bullshit.


okay i must say i hardly use panel - which others are problematic for you?

in waveform one of these rows of numbers is ON by default since max 6, but that can easily be changed.

another serious issue in 4.1 was (which i forgot to mention above) is that there is a bug where you have to (programmatically) place [fpic] at -1 -1 to have it at show up at 0 0. 

scripting the required repositioning of that after a custom version-check of the runtime seemed overkill - so i ended up using pctcntrl for background images. auto size, dont allow click, and off you go.:)


okay i must say i hardly use panel - which others are problematic for you?

in waveform one of these rows of numbers is ON by default since max 6, but that can easily be changed.

another serious issue in 4.1 was (which i forgot to mention above) is that there is a bug where you have to (programmatically) place [fpic] at -1 -1 to have it at show up at 0 0. 

scripting the required repositioning of that after a custom version-check of the runtime seemed overkill - so i ended up using pctcntrl for background images. auto size, dont allow click, and off you go.:)


My main problem was to port old projects for customers which

upgraded to OS versions not being able to run max 4.6

I mostly used umenu (ubumenu in old days) for buttons,

having all different function names inserted, and sending

So for example record button would sync to another loop

if held longer than 1000 ms, would change from Record

to Sync-Rec, change color from blue to orange, and so on.

Doing so in a large patch is just a loss of time.

A combo of panel, message and ubutton was another 

option, but You can imagine how much work that means

In the mean time I have ported most of the projects to max 6 and 7,

and simply refuse to update old projects to Max 8 including OS Catalina.

My main problem was  to port old projects for customers which
upgraded to OS versions not being able to run max 4.6
I mostly used umenu (ubumenu in old days) for buttons,
having all different function names inserted, and sending
GUI messages depending on the function.
So for example record button would sync to another loop
if held longer than 1000 ms, would change from Record
to Sync-Rec, change color from blue to orange, and so on.
Doing so in a large patch is just a loss of time.
A combo of panel, message and ubutton was another 
option, but You can imagine how much work that means
for many buttons ... 
In the mean time I have ported most of the projects to max 6 and 7,
and simply refuse to update old projects to Max 8  including OS Catalina.


i hope 8 didnt change much new things compared to 7, because i cant test 8 myself atm.