Francois Weber

you can see how max 5 use arguments in 'bpatcher'

CommentBug : The main patch
Untitled1 : a Max 5 abstract
Untitled2 : a Max 4.6.3 abstract

you can see how max 5 use arguments in 'bpatcher'
Is it a bug ?

comment-in-bpatcher

On 3 mai 08, at 11:47, Francois Weber wrote:

> you can see how max 5 use arguments in 'bpatcher'

Actually no, it's a feature. In Max 5 the contents of the comment is 

not evaluated anymore. You'll have to use message box instead if you 

> Hi,
>
> I join A zip file with 3 patchers
>
> CommentBug : The main patch
> Untitled1 : a Max 5 abstract
> Untitled2 : a Max 4.6.3 abstract
>
> you can see how max 5 use arguments in 'bpatcher'
> Is it a bug ?

Actually no, it's a feature. In Max 5 the contents of the comment is  
not evaluated anymore. You'll have to use message box instead if you  
want to display it.

Ok for the comment object, but what about argument like #1_FXW in 'Embed in parent' mode ?

On May 3, 2008, at 2:47 AM, Francois Weber wrote:

Apparently, it was quirk of the Max 4 parser that the #1 arguments 

I know it's a drag to have to modify your patchers, but instead of 

using comments in Max 5 for things I need to be substituted like this, 

I've been using message boxes with the background set to transparent.

On May 3, 2008, at 2:47 AM, Francois Weber wrote:
> you can see how max 5 use arguments in 'bpatcher'
> Is it a bug ?

Apparently, it was quirk of the Max 4 parser that the #1 arguments  
were ever substituted at all.

I know it's a drag to have to modify your patchers, but instead of  
using comments in Max 5 for things I need to be substituted like this,  
I've been using message boxes with the background set to transparent.

Chris Muir
cbm@well.com	
http://www.xfade.com

> I know it's a drag to have to modify your patchers, but instead of 

> using comments in Max 5 for things I need to be substituted like 

> this, I've been using message boxes with the background set to 

> I know it's a drag to have to modify your patchers, but instead of  
> using comments in Max 5 for things I need to be substituted like  
> this, I've been using message boxes with the background set to  
> transparent.

Ok for the comment object, I understand...

but what about argument like #1_FXW in other objects with 'Embed in parent' mode ? '(look at my main patch...)

Ok for the comment object, I understand...
but what about argument like #1_FXW in other objects with 'Embed in parent' mode ? '(look at my main patch...)

On May 3, 2008, at 5:06 AM, Francois Weber wrote:

> Ok for the comment object, but what about argument like #1_FXW in 

Yeah, that looks like it might be a bug, I guess, although the rules 

for arguments to embedded subpatchers has always been a a bit of a 

On May 3, 2008, at 5:06 AM, Francois Weber wrote:
> Ok for the comment object, but what about argument like #1_FXW in  
> 'Embed in parent' mode ?

Yeah, that looks like it might be a bug, I guess, although the rules  
for arguments to embedded subpatchers has always been a a bit of a  
mystery to me.

On May 3, 2008, at 5:08 PM, Chris Muir wrote:

> Yeah, that looks like it might be a bug, I guess, although the rules 

> for arguments to embedded subpatchers has always been a a bit of a 

By "bit of a mystery" I don't mean that I don't know they work, more 

of a mystery of why they were designed that way in the first place, 

but that's lost in time, like tears in rain.

On May 3, 2008, at 5:08 PM, Chris Muir wrote:
> Yeah, that looks like it might be a bug, I guess, although the rules  
> for arguments to embedded subpatchers has always been a a bit of a  
> mystery to me.

By "bit of a mystery" I don't mean that I don't know they work, more  
of a mystery of why they were designed that way in the first place,  
but that's lost in time, like tears in rain.

The more I think about this the more I think it's just Max 5 being 

consistent with how it treats arguments to subpatchers. You wouldn't 

expect arguments to be passed to a subpatcher embedded in a parent 

patcher, and this is sort of the same thing.

The more I think about this the more I think it's just Max 5 being  
consistent with how it treats arguments to subpatchers. You wouldn't  
expect arguments to be passed to a subpatcher embedded in a parent  
patcher, and this is sort of the same thing.

Comment in Bpatcher