ddw_music

(Not sure if this belongs here or under Max/MSP -- I'll start here, as it's not really a user question -- I already solved my problem -- more of a gripe.)

I'm curious... what is the reason why messages to [in 2] [in 3] etc. in poly~ go only to the first instance by default?

It makes more sense to me that one would want to address the entire poly~ complex as the normal case, and that addressing a single instance would be a special case that would require the user to send (target 

). Instead, if you're using inputs 2, 3... for initialization, you have to remember to send (target 0) as the first thing. Huh? Why?

Just wondering if this is something that has a really strong rationale, or if it's one where the programmers needed to decide on a default behavior and they chose the wrong one, and now we're stuck because it would break patches if they changed it. (Choosing only one instance is necessarily arbitrary, and arbitrary defaults are often questionable.)

(Sorry for a critical post... but, after spending a couple of hours figuring out why my poly~ was sounding only one note at a time, it strikes me that this is just too easy a mistake, and it could have been avoided by a better choice of default from the devs.)

It makes more sense to me that one would want to address the entire poly~ complex as the normal case, and that addressing a single instance would be a special case that would require the user to send (target n). Instead, if you're using inputs 2, 3... for initialization, you have to remember to send (target 0) as the first thing. Huh? Why?

poly-why-is-target-0-not-the-default-behavior

it is probably not the most common case that you want to use target 0.

loadbang it, then you can not forget it. :)

i do not believe exclusive 'target 0' use is the most common use for poly~ (even though it is for me, funnily enough), it being a... "poly~" object and all...

I almost never use "target 0". Whenever I need to send messages to all instances at once I use send/receive pairs: a [send] in the main patch, and a [receive] inside the poly~ patch. This way I don't need to explicity switch targets.

@target 0 -- didn't know about that (documented anywhere?). Send/receive pairs are also not a bad idea.

But my other point was not so much about what is the most common use, but rather, whether the current behavior is the most intuitive. Maybe I should rephrase the question --

Is it the most common usage of poly~ that one would want to direct messages to instance number 1 to the exclusion of others?

I would guess the answer is "no" -- it may be the most common usage to send (target n) and then follow this with messages to other inputs. Which kind of makes my point -- if you have to send a target message anyway, then why is the default behavior to assume you want (target 1)?

If I were designing it, I would have the messages go to all instances until you tell poly~ otherwise. Note that this would make no difference to the "most common usage" because you already have to send the target message in that usage! So you don't lose any functionality -- the most common case is no less convenient -- and the default behavior doesn't do anything counterintuitive like arbitrarily choose one instance and ignore the others.

From that perspective, forcing the user to know about scantily documented initialization arguments or to use send/receive are clever workarounds for a poor design decision in the beginning. That's okay... all software depends on workarounds somewhere or another... but neither do I feel inclined to call a workaround a proper solution. :)

@ddw_music, i actually agree with many of your points, and largely they are just issues that cannot be solved now because of backwards compatibility etc. there are many of those issues in max because of the nature of the lengthy evolution of the beast. however, i just could not let these comments past as it irks me when people do not use the excellent documentation system in max:

"@target 0 -- didn't know about that (documented anywhere?)"

"forcing the user to know about scantily documented initialization arguments"

it is accepted wisdom in max that 1) you alt-click an object to learn more and 2) you then click the reference link to learn more more. personally i find this @target feature to be very well documented indeed. it is sitting there in the reference helpfile. "forcing the user to know about" this? no, asking the user to be not-lazy. in max, there are quite a few things not documented, and it is infuriating, but most of the time details are sitting there waiting to be read, in easily accessible places. sure, the entire documentation system could do with a professional proofreader's eyes to correct all the horrible grammar and sometimes dodgy spelling, but the facts are there.

"@target 0 -- didn't know about that (documented anywhere?)"
"forcing the user to know about scantily documented initialization arguments"

it is accepted wisdom in max that 1) you alt-click an object to learn more and 2) you then click the reference link to learn more more. personally i find this @target feature to be very well documented indeed. it is sitting there in the reference helpfile. "forcing the user to know about" this? no, asking the user to be not-lazy. in max, there are quite a few things not documented, and it is infuriating, but most of the time details are sitting there waiting to be read, in easily accessible places. sure, the entire documentation system could do with a professional proofreader's eyes to correct all the horrible grammar and sometimes dodgy spelling, but the facts are there.


@ddw_music - perhaps it would be helpful for me to point out here that the @ refers to an attribute, and that *all* attributes can be initialised with @attribute value.

It is not documented separately because it is a general feature of max - documented elsewhere - you might want to check out the docs on attributes, which can be set with messages, but also through other means.

As tot he target 0 - personally I agree - I work this way and tag messages with a number which I strip (which is faster and less messy than maintaining send/receive pairs - however, it is very unlikely to be changed, so best to get used to it. As to "most common usage" - probably a case of YMMV, so who can really know?

@ddw_music - perhaps it would be helpful for me to point out here that the @ refers to an attribute, and that *all* attributes can be initialised with @attribute value. 

As tot he target 0 - personally I agree - I work this way and tag messages with a number which I strip (which is faster and less messy than maintaining send/receive pairs - however, it is very unlikely to be changed, so best to get used to it. As to "most common usage" - probably a case of YMMV, so who can really know?


Like pid and AlexHarker, I would take issue with the notion that @target is "scantily documented". I'll grant that there is so much documentation that sometimes one is required to use some ingenuity to find any one item. Here are a few suggestions.

https://cycling74.com/docs/max5/vignettes/core/attributes_intro.html

https://cycling74.com/docs/max5/tutorials/jit-tut/jitterwhatareattributes.html

2) Some attributes are common to all Max objects. They're listed here:

https://cycling74.com/docs/max5/refpages/max-ref/jbox.html

3) In an unlocked patcher you can click on the left inlet of any object to get a list of its attributes and messages.

4) The reference page for each object lists and explains that object's attributes.

That said, here a few observations of my own:

1) When you click on the left inlet of poly~ to see its list of attributes, the 'target' attribute is listed as having a default value of 0. That is incorrect; the default value appears to be 1, as you observed. That should be fixed.

2) I personally think, like you, that 0 is a better default value. So perhaps instead of fixing the documentation, the Cyclng '74 could consider changing it to 0. But...

3) Any time one considers changing a behavior of Max, one has to consider that such a change might cause existing Max patches to malfunction. Such changes usually run that risk, and are therefore avoided. So...

4) The easiest solution is to use @target 0, as pid suggested.

Like pid and AlexHarker, I would take issue with the notion that @target is "scantily documented". I'll grant that there is so much documentation that sometimes one is required to use some ingenuity to find any one item. Here are a few suggestions.
1) Read about attributes:
    https://cycling74.com/docs/max5/vignettes/core/attributes_intro.html
    https://cycling74.com/docs/max5/tutorials/jit-tut/jitterwhatareattributes.html
2) Some attributes are common to all Max objects. They're listed here:
    https://cycling74.com/docs/max5/refpages/max-ref/jbox.html
3) In an unlocked patcher you can click on the left inlet of any object to get a list of its attributes and messages.
4) The reference page for each object lists and explains that object's attributes.

That said, here a few observations of my own:
1) When you click on the left inlet of poly~ to see its list of attributes, the 'target' attribute is listed as having a default value of 0. That is incorrect; the default value appears to be 1, as you observed. That should be fixed.
2) I personally think, like you, that 0 is a better default value. So perhaps instead of fixing the documentation, the Cyclng '74 could consider changing it to 0. But...
3) Any time one considers changing a behavior of Max, one has to consider that such a change might cause existing Max patches to malfunction. Such changes usually run that risk, and are therefore avoided. So...
4) The easiest solution is to use @target 0, as pid suggested.


Thanks to all for the clarifications about attributes. That's a feature which, for the moment, has been above the cutoff frequency of my low pass filter -- by which I mean, whenever you're approaching a relatively unfamiliar piece of software, you make decisions about which are the critical documents to read and which are finer points for later. I went along for quite some time without needing to know what attributes are or how to initialize them in the object box's text. Now I need to know. Thanks for the pointers.

I also understand about backward compatibility -- similar issues come up in SuperCollider-land.

poly~ -- why is (target 0) not the default behavior?