Brian H.

Is there some rule that an attribute in [patcherargs] can't start with an integer?

When I send the message "1 interval 500" to [route 1], it passes fine. When I send the same message (with "@") from [patcherargs], it doesn't match [route 1].

Hi,
Is there some rule that an attribute in [patcherargs] can't start with an integer?
When I send the message "1 interval 500" to [route 1], it passes fine.  When I send the same message (with "@") from [patcherargs], it doesn't match [route 1].

Hi,
Is there some rule that an attribute in [patcherargs] can't start with an integer?
When I send the message "1 interval 500" to [route 1]

-patcherargs-attributes

patcherargs sometimes outputs "basic" at the beginning of the list.

Don't ask me why, I realised it when playing arround with the help file.

Where this "basic" came from I can't say, there was no object named so

or aything else in the patcher, also reference does not mention it anywhere.

Screen shot 2018-07-31 at 13.14.07.png

But if the object gets copied to another patcher, it started outputing expected string , I mean integer as first list member.

Screen shot 2018-07-31 at 13.15.16.png

patcherargs sometimes outputs "basic" at the beginning of the list.
Don't ask me why, I realised it when playing arround with the help file.
Where this "basic" came from I can't say, there was no object named so
or aything else in the patcher, also reference does not mention it anywhere.

But if the object gets copied to another patcher, it started outputing  expected string , I mean integer as first list member.


"basic" comes from a subpatcher name (tab name). The subpatcher is a [p basic] in enclosing patcher (normally hidden, but you can get there right clicking on the tab bar and enabling "Show Root Patcher on Tab"). Hence the first argument is "basic" and replaces default "1".

"basic" comes from a subpatcher name (tab name). The subpatcher is a [p basic] in enclosing patcher (normally hidden, but you can get there right clicking on the tab bar and enabling "Show Root Patcher on Tab"). Hence the first argument is "basic" and replaces default "1".
hth

Anyway, for me just another nonosense ....

If it says 1 in patcherargs it shoud spitt 1 out

Thank's for the info.
Anyway, for me just another nonosense ....
If it says 1 in patcherargs it shoud spitt 1 out


No. It gets its values from a box instantiating given subpatcher/abstraction in enclosing patcher. If there are no arguments (or less than provided in [patcherargs]), [patcherarg] returns its arguments as default values.

Otherwise it would work like a crumpled [pack] object.

No. It gets its values from a box instantiating given subpatcher/abstraction in enclosing patcher. If there are no arguments (or less than provided in [patcherargs]), [patcherarg] returns its arguments as default values.
Otherwise it would work like a crumpled [pack] object.

I can see why that happens with subpatchers- albeit kind of annoying. Also, since a list technically start with a symbol, [route] is bound to choke on it. I really wish they’d just make it consistent.

But i’m not seeing why it wouldn’t output “@1 foo“ in an abstraction, as i’d expect. I also tried re-creating the object.

I can see why that happens with subpatchers- albeit kind of annoying.  Also, since a list technically start with a symbol, [route] is bound to choke on it.  I really wish they’d just make it consistent.

But i’m not seeing why it wouldn’t output “@1 foo“ in an abstraction, as i’d expect.  I also tried re-creating the object.

Apparently, [patcherargs] thinks the attribute is a symbol (?). I don't get it– [route] doesn't treat it that way. Does that make sense to anyone?

Apparently, [patcherargs] thinks the attribute is a symbol (?).  I don't get it– [route] doesn't treat it that way.  Does that make sense to anyone?



if you use "@" attribute notation, check the second outlet of [patcherargs]. This object filters all @ttributes and send them separately. Numbers used as attribute names are converted to symbols (hence double quote marks in routepass object).

Hi Brian, 
if you use "@" attribute notation, check the second outlet of [patcherargs]. This object filters  all @ttributes and send them separately. Numbers used as attribute names are converted to symbols (hence double quote marks in routepass object).

Yeah, I see that now. Is there any logic to this? I don't see it documented, which is frustrating. I had to do this kludge– any easier ways?

Yeah, I see that now.  Is there any logic to this?  I don't see it documented, which is frustrating.  I had to do this kludge– any easier ways?


I must admit this is rather strange usage of attributes/attribute convention. Attributes are more like keys in a dictionary than indexes in an array. It seems you want to address separate voices/layers from arguments of created abstraction. I would just go this way:

In most cases when dealing with many voices, parameters are sent as messages after object creation. Object boxes with lots of arguments and attributes are hard to maintain.

I must admit this is rather strange usage of attributes/attribute convention. Attributes are more like keys in a dictionary than indexes in an array. It seems you want to address separate voices/layers from arguments of created abstraction. I would just go this way:


 In most cases when dealing with many voices, parameters are sent as messages after object creation. Object boxes with lots of arguments and attributes are hard to maintain. 

This is good for me to know– when my logic does not overlap with Max's. Yes, you are correct about my purpose. It seems like initializing with arguments is more efficient than the other method, if you know what you want already. It's also less things in the patch, and less messing with [loadbang]. It's true that arguments get cumbersome, so it's the lesser-of-two-evils.

I guess just adding a prefix, as in your example, is the cleanest way. I just thought it wasn't really necessary, but might not be a bad thing.

I'm a little irked that there is no mention of this [patcherargs] behavior with [int] attributes in the docs.

This is good for me to know– when my logic does not overlap with Max's.  Yes, you are correct about my purpose.  It seems like initializing with arguments is more efficient than the other method, if you know what you want already.  It's also less things in the patch, and less messing with [loadbang].  It's true that arguments get cumbersome, so it's the lesser-of-two-evils.

I guess just adding a prefix, as in your example, is the cleanest way.  I just thought it wasn't really necessary, but might not be a bad thing.

[patcherargs] attributes...