Eamonn Doyle

I'm being tormented by the eccentricities of comment formatting...

Wide comment boxes becoming narrower, other ones becoming super wide, and sometimes all but a line of text disappearing.

I know it's not a text layout tool, but for preparing lecture notes etc some slightly less 'colourful' behaviour would be oh so nice.

I'm on 4.5.5 - maybe this has been addressed in 4.6?

Hi;
I'm being tormented by the eccentricities of comment formatting...
Wide comment boxes becoming narrower, other ones becoming super wide, and sometimes all but a line of text disappearing.
I know it's not a text layout tool, but for preparing lecture notes etc some slightly less 'colourful' behaviour would be oh so nice.

comment-text-behaviour

Stretch your comment windows about 20 percent more to the right, so that switching computers/platforms/font sets doesn't make the text wrap (ditto for objects and message boxes). If this happens, it can make things cluttered, not just comment boxes.

Put a semicolon at the end of a comment sentence, *then* hit return. That line break has a lot more staying power.

Other than that...? ...you can real-time colorize the comment box with a script send frgb message? fun

Other than that...? ...you can real-time colorize the comment box with a script send  frgb message?  fun

Am 09.01.2007 um 11:24 schrieb Eamonn Doyle:

> I'm being tormented by the eccentricities of comment formatting...

> Wide comment boxes becoming narrower, other ones becoming super wide, 

> and sometimes all but a line of text disappearing.

do you know about the "2 byte compatible" checkbox in the inspector?

Don't know about your disappearing text, but it'll keep line breaks.

Am 09.01.2007 um 11:24 schrieb Eamonn Doyle:
> I'm being tormented by the eccentricities of comment formatting...
> Wide comment boxes becoming narrower, other ones becoming super wide, 
> and sometimes all but a line of text disappearing.

do you know about the "2 byte compatible" checkbox in the inspector?
Don't know about your disappearing text, but it'll keep line breaks.

On 9-Jan-2007, at 5:24, Eamonn Doyle wrote:

I can confirm that comment and message boxes have some erratic behavior.

First up: I know about Cmd-J (aka Fix Width), stretching the box 

manually, "2-byte compatible", using semi-cola to force line breaks, 

Nevertheless, since v4.5 or so I have experienced that I can put a 

multi-line comment box in a subpatcher, manually size it to what I 

want, close the subpatcher, and when the subpatcher is reopened the 

comment box has been magically resized, usually to about three times 

This behavior is unfortunately not regularly reproducible, I have 

found no three-step cookbook recipe which recreates the failure. 

Indeed, usually when I get the comment box back to the shape I want 

for a second time, it tends to stay that way. This is a bit like 

Lewis Carroll's Bellman in The Hunting of the Snark, just not quite 

as extreme. Annoying but irreplaceable, hence it's impossible to file 

> I'm on 4.5.5 - maybe this has been addressed in 4.6?

TTBOMK, no. Again, when I fix the "colorful" behavior, it seems to 

stay fixed. You just have to be more stubborn than Max.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

On 9-Jan-2007, at 5:24, Eamonn Doyle wrote:
> I'm being tormented by the eccentricities of comment formatting...

First up: I know about Cmd-J (aka Fix Width), stretching the box  
manually, "2-byte compatible", using semi-cola to force line breaks,  
etc. I really do.

Nevertheless, since v4.5 or so I have experienced that I can put a  
multi-line comment box in a subpatcher, manually size it to what I  
want, close the subpatcher, and when the subpatcher is reopened the  
comment box has been magically resized, usually to about three times  
the width of my screen.-(

This behavior is unfortunately not regularly reproducible, I have  
found no three-step cookbook recipe which recreates the failure.  
Indeed, usually when I get the comment box back to the shape I want  
for a second time, it tends to stay that way. This is a bit like  
Lewis Carroll's Bellman in The Hunting of the Snark, just not quite  
as extreme. Annoying but irreplaceable, hence it's impossible to file  
a proper bug report.

TTBOMK, no. Again, when I fix the "colorful" behavior, it seems to  
stay fixed. You just have to be more stubborn than Max.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

> Hi; I'm being tormented by the eccentricities of comment 

> formatting... Wide comment boxes becoming narrower, other ones 

> becoming super wide, and sometimes all but a line of text 

> disappearing. I know it's not a text layout tool, but for preparing 

> lecture notes etc some slightly less 'colourful' behaviour would be 

I am sure you refer to message boxes and not to comments. Comments do

not have this behaviour, at least if you check two-byte compatibility in

It's absolutely annoying the way message boxes are reformatting without

being asked (because they try to keep the number of lines constant).

Before 4.5 it was working. It's still breaking a lot of my old patches

All patches which deal with changing content are absolutely messed up

(always if its displaying a file path for example).

I consider this a severe bug, worth to correct before Max 5.0

> This behavior is unfortunately not regularly reproducible, I have

> found no three-step cookbook recipe which recreates the failure.

but thats what the change since 4.5 was intended to be, keep the number 

of lines constant (which makes sense for a very limited number of cases).

Unfortunately it even doesn't recognise that, after it once had been 

saved. If you changed the numbers of lines by changing the text by hand 

or resize the box and reopen, it will snap to the old number of lines. 

My workaround: if I change a message box, I copy and then paste-replace 

Did I mention that this is very annoying?...

Another non consitent behaviour is when I script message boxes with the 

message: If I define the size in the script, and the message exceeds the 

defined size, it will sometimes wrap (as I'd expect it to do) and 

sometimes insist on staying on one line. The same patch, nothing else 

changed will have both behaviours. The patch is big, on small ones its 

I'd like to hear a comment of the bug departement if this behaviour will

change, or if C74 would like to keep it ugly. (In the latter case do not

Eamonn Doyle wrote:
> Hi; I'm being tormented by the eccentricities of comment 
> formatting... Wide comment boxes becoming narrower, other ones 
> becoming super wide, and sometimes all but a line of text 
> disappearing. I know it's not a text layout tool, but for preparing 
> lecture notes etc some slightly less 'colourful' behaviour would be 
> oh so nice.

I am sure you refer to message boxes and not to comments. Comments do
not have this behaviour, at least if you check two-byte compatibility in
the inspector, but message boxes do...

It's absolutely annoying the way message boxes are reformatting without
being asked (because they try to keep the number of lines constant).
Before 4.5 it was working. It's still breaking a lot of my old patches
without a chance of a workaround!!!
All patches which deal with changing content are absolutely messed up
(always if its displaying a file path for example).
I reported and complained a lot, I know.
I consider this a severe bug, worth to correct before Max 5.0

Peter Castine wrote:
> This behavior is unfortunately not regularly reproducible, I have
> found no three-step cookbook recipe which recreates the failure.

Below it is,
but thats what the change since 4.5 was intended to be, keep the number 
of lines constant (which makes sense for a very limited number of cases).
Unfortunately it even doesn't recognise that, after it once had been 
saved. If you changed the numbers of lines by changing the text by hand 
or resize the box and reopen, it will snap to the old number of lines. 
My workaround: if I change a message box, I copy and then paste-replace 
it again.
Did I mention that this is very annoying?...

Another non consitent behaviour is when I script message boxes with the 
message: If I define the size in the script, and the message exceeds the 
defined size, it will sometimes wrap (as I'd expect it to do) and 
sometimes insist on staying on one line. The same patch, nothing else 
changed will have both behaviours. The patch is big, on small ones its 
more consistant...

I'd like to hear a comment of the bug departement if this behaviour will
change, or if C74 would like to keep it ugly. (In the latter case do not
expect me to stop complaining... ;-)

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


On 11-Jan-2007, at 6:30, Stefan Tiedje wrote:

> I am sure you refer to message boxes and not to comments. Comments do

> not have this behaviour, at least if you check two-byte 

I have experienced mysterious resizings with Comment Boxes. Really, 

comment boxes. (But, yes, I've had the magic ever-expanding message 

2-byte compatibility seems to help, but it is nevertheless 

frustrating to set a comment box to a given width, close the patch 

(or subpatcher), re-open it only to find that Max has resized it. I 

suspect this may be a problem with parameters in linecount messages.

I know, I know, I need to get a reproducable set of steps to track 

> I am sure you refer to message boxes and not to comments. Comments do
> not have this behaviour, at least if you check two-byte  
> compatibility in
> the inspector, but message boxes do...

I have experienced mysterious resizings with Comment Boxes. Really,  
comment boxes. (But, yes, I've had the magic ever-expanding message  
box effect, too.)

2-byte compatibility seems to help, but it is nevertheless  
frustrating to set a comment box to a given width, close the patch  
(or subpatcher), re-open it only to find that Max has resized it. I  
suspect this may be a problem with parameters in linecount messages.

I know, I know, I need to get a reproducable set of steps to track  
this one down. I'll try.

Make a message box with back-slashed linefeeds. Make a second message box

by duplicating the first. Make one change in the second box. Save the

reopen. The line feeds in the second are gone.

On 1/11/07 1:26 PM, "Peter Castine" wrote:

> On 11-Jan-2007, at 6:30, Stefan Tiedje wrote:

>> I am sure you refer to message boxes and not to comments. Comments do

>> not have this behaviour, at least if you check two-byte

>> the inspector, but message boxes do...

> I have experienced mysterious resizings with Comment Boxes. Really,

> comment boxes. (But, yes, I've had the magic ever-expanding message

> 2-byte compatibility seems to help, but it is nevertheless

> frustrating to set a comment box to a given width, close the patch

> (or subpatcher), re-open it only to find that Max has resized it. I

> suspect this may be a problem with parameters in linecount messages.

> I know, I know, I need to get a reproducable set of steps to track

> Peter Castine +--> Litter Power & Litter Bundle for Jitter

> Interface Building for |home | chez nous|

> Max/MSP Extremely cool |bei uns | i nostri|

Make a message box with back-slashed linefeeds.  Make a second message box
by duplicating the first.  Make one change in the second box. Save the
reopen.  The line feeds in the second are gone.

On 1/11/07 1:26 PM, "Peter Castine"  wrote:

> On 11-Jan-2007, at 6:30, Stefan Tiedje wrote:
>
>> I am sure you refer to message boxes and not to comments. Comments do
>> not have this behaviour, at least if you check two-byte
>> compatibility in
>> the inspector, but message boxes do...
>
> I have experienced mysterious resizings with Comment Boxes. Really,
> comment boxes. (But, yes, I've had the magic ever-expanding message
> box effect, too.)
>
> 2-byte compatibility seems to help, but it is nevertheless
> frustrating to set a comment box to a given width, close the patch
> (or subpatcher), re-open it only to find that Max has resized it. I
> suspect this may be a problem with parameters in linecount messages.
>
> I know, I know, I need to get a reproducable set of steps to track
> this one down. I'll try.
>
> -- P. 
>
>
> --------------    http://www.bek.no/~pcastine/Litter/    -------------
> Peter Castine             +--> Litter Power & Litter Bundle for Jitter
>                                 Universal Binaries on the way
> iCE:  Sequencing,  Recording &
>        Interface  Building  for                   |home    | chez nous|
>        Max/MSP   Extremely cool                   |bei uns |  i nostri|
>        http://www.dspaudio.com/                   http://www.castine.de
>
>

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

Quote: Peter Castine wrote on Thu, 11 January 2007 10:26

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

> I have experienced mysterious resizings with Comment Boxes. Really

I have had the exact same behaviour: closing a subpatcher and re-opening it made the comment resize itself. Fix it once, and it sticks.

Quote: Peter Castine wrote on Thu, 11 January 2007 10:26
----------------------------------------------------

> I have experienced mysterious resizings with Comment Boxes. Really  

It sticks as long as you don't edit it. Change it and you lose all of the

line feeds when you save. Same with message and textedit.

On 1/11/07 3:54 PM, "Arne Eigenfeldt" wrote:

> Quote: Peter Castine wrote on Thu, 11 January 2007 10:26

> ----------------------------------------------------

>> I have experienced mysterious resizings with Comment Boxes. Really

> I have had the exact same behaviour: closing a subpatcher and re-opening it

> made the comment resize itself. Fix it once, and it sticks.

It sticks as long as you don't edit it.  Change it and you lose all of the
line feeds when you save.  Same with message and textedit.

On 1/11/07 3:54 PM, "Arne Eigenfeldt"  wrote:

>
> Quote: Peter Castine wrote on Thu, 11 January 2007 10:26
> ----------------------------------------------------
>
>> I have experienced mysterious resizings with Comment Boxes. Really
>
> I have had the exact same behaviour: closing a subpatcher and re-opening it
> made the comment resize itself. Fix it once, and it sticks.
>
> And it seems sporadic.

On Jan 11, 2007, at 1:22 PM, Gary Lee Nelson wrote:

> It sticks as long as you don't edit it. Change it and you lose all 

> line feeds when you save. Same with message and textedit.

FWIW, atom parsing (which is what this elimination of whitespace is 

due to) is only guaranteed to be avoidable using two byte compatible 

> It sticks as long as you don't edit it.  Change it and you lose all  
> of the
> line feeds when you save.  Same with message and textedit.

FWIW, atom parsing (which is what this elimination of whitespace is  
due to) is only guaranteed to be avoidable using two byte compatible  
comments.

Yes, that is covered in the manual but there does not seem to be a two-byte

option for messages or textedit. If you put returns in a message then edit

the message, the returns are lost. In a textedit you can edit but the

returns are gone when next you load the patch. This is 4.6 on an Intel

On 1/11/07 5:06 PM, "Joshua Kit Clayton" wrote:

> On Jan 11, 2007, at 1:22 PM, Gary Lee Nelson wrote:

>> It sticks as long as you don't edit it. Change it and you lose all

>> line feeds when you save. Same with message and textedit.

> FWIW, atom parsing (which is what this elimination of whitespace is

> due to) is only guaranteed to be avoidable using two byte compatible

Yes, that is covered in the manual but there does not seem to be a two-byte
option for messages or textedit.  If you put returns in a message then edit
the message, the returns are lost.  In a textedit you can edit but the
returns are gone when next you load the patch.  This is 4.6 on an Intel
book.

On 1/11/07 5:06 PM, "Joshua Kit Clayton"  wrote:

>
> On Jan 11, 2007, at 1:22 PM, Gary Lee Nelson wrote:
>
>> It sticks as long as you don't edit it.  Change it and you lose all
>> of the
>> line feeds when you save.  Same with message and textedit.
>
> FWIW, atom parsing (which is what this elimination of whitespace is
> due to) is only guaranteed to be avoidable using two byte compatible
> comments.
>
> -Joshua
>
>
>

On 11-Jan-2007, at 15:08, Gary Lee Nelson wrote:

> Make a message box with back-slashed linefeeds. Make a second 

> by duplicating the first. Make one change in the second box. Save the

> reopen. The line feeds in the second are gone.

This I am also (!) aware of, and this one I understand. It's as 

Joshua says, every time you edit text, the text gets re-parsed and 

non-escaped whitespace is collapsed to a single blank. Annoying but, 

What I've been referring to is filling a comment box (comment box, 

comment box, what I tell you three times is true!) with a nice long 

chunky text, like a full paragraph, something akin to the paragraph 

you are currently reading. No line feeds, no carriage returns, just a 

long-winded, verbose, prolix, lengthy, protracted, long-drawn-out, 

overlong, rambling, circumlocutory, periphrastic, pleonastic, 

loquacious, garrulous, voluble text like the one you see here. Then I 

grab the lower right hand corner of the comment box (comment box, 

comment box) and resize it so the comment box (we're talking about 

comment boxes, right?) is only 200 pixels wide and flows over, oh, I 

dunno, two dozen lines or something. OK, now close the subpatcher and 

re-open it. And what do you have then? Max has gone and turned it 

into a two thousand pixel wide single-line comment box.

Anyone sez I shouldn' write long texts gets a punchinnanose.

Arne understood me the first time through. Next beer's on me, Arne.

On 11-Jan-2007, at 15:08, Gary Lee Nelson wrote:
> Make a message box with back-slashed linefeeds.  Make a second  
> message box
> by duplicating the first.  Make one change in the second box. Save the
> reopen.  The line feeds in the second are gone.

This I am also (!) aware of, and this one I understand. It's as  
Joshua says, every time you edit text, the text gets re-parsed and  
non-escaped whitespace is collapsed to a single blank. Annoying but,  
in a perverse sort of way, consistent.

What I've been referring to is filling a comment box (comment box,  
comment box, what I tell you three times is true!) with a nice long  
chunky text, like a full paragraph, something akin to the paragraph  
you are currently reading. No line feeds, no carriage returns, just a  
long-winded, verbose, prolix, lengthy, protracted, long-drawn-out,  
overlong, rambling, circumlocutory, periphrastic, pleonastic,  
loquacious, garrulous, voluble text like the one you see here. Then I  
grab the lower right hand corner of the comment box (comment box,  
comment box) and resize it so the comment box (we're talking about  
comment boxes, right?) is only 200 pixels wide and flows over, oh, I  
dunno, two dozen lines or something. OK, now close the subpatcher and  
re-open it. And what do you have then? Max has gone and turned it  
into a two thousand pixel wide single-line comment box.

Let me clarify. Who cares about comment boxes? Once I write them, I seldom

edit them. Messages and textedit, on the other hand, are fluid in my world

One of the hallmarks of the Macintosh interface is that text editing is

built into the kernel, ROM, whatever. It is CONSISTENT from application to

application. It is a pain in the neck to scan a large textedit box to

visually parse run-on message sequences that were initially nicely formatted

as lines ending with commas (for separator , message which works great

BTW). I don't want to punch anyone's nose but this is not why I use

computers. It is, in fact, very annoying and should be fixed. I am

finishing a commission on a piece that has nearly 100 scripts expressed as

messages sequences in textedits that are stored and recalled with pattr. If

I change a tempo from 120 to 121, 50+ messages flock like lemmings. What a

On 1/11/07 9:14 PM, "Peter Castine" wrote:

> On 11-Jan-2007, at 15:08, Gary Lee Nelson wrote:

>> Make a message box with back-slashed linefeeds. Make a second

>> by duplicating the first. Make one change in the second box. Save the

>> reopen. The line feeds in the second are gone.

> This I am also (!) aware of, and this one I understand. It's as

> Joshua says, every time you edit text, the text gets re-parsed and

> non-escaped whitespace is collapsed to a single blank. Annoying but,

> What I've been referring to is filling a comment box (comment box,

comment / text behaviour