Actually, I think that the report on mute is a good thing. It allow for further management of voices / polyphony.

chris, ok, fair enough-- but to get around that I created another instance of thispoly~ and it would also output in parallel to the thispoly~ that was being queried, even though it wasn't sent a message or bang directly.

edit: also this behaviour (outputs instance number when muted) is not documented-- probably should be

What are you trying to accomplish? Perhaps you should post the patch that you are having trouble with.

well i needed to get the instance number independent of mute messages, so I wanted two thispoly~ objects (one for muting/unmuting & setting busy state, and the other for querying what a particular instance was doing at a particular point in time), but in the meantime i've devised a workaround-- the problem, or inconsistency, is illustrated here:

edit: my first post is misleading-- the dual [thispoly~] output only occurs with the (mute) message, not with the (bang)-- I can kind of understand the logic, but it would also be more consistent if only the instance that is sent a message is able to respond...

As an easy workaround you can use the [grab] object. This will prevent the connected [thispoly~] from outputting the instance number.

Notice that any other dual [thispoly~] in the patch will still output!

thanks mudang-- my workaround was clumsy gating; using grab is more elegant. still, this 'inconsistent' behavior should be documented T

Personally I feel thispoly~ should NOT be outputting an instance number when sent mute messages.

Gating thispoly~'s output to remove rogue instance reports in response to a mute message indeed feels clumsy.

If one DID want instance reports after sending mutes, sending a 'bang' to thispoly~ after sending any mute message is trivial

As with any behavior that has been in place for a long time, a change would mean that many old patches might break. Since this is not a bug, but just the way poly~ has always worked, I really doubt that it will change.

the fact that 2 or more instances of the same thispoly~ output in response to (mute) when sent to only one of the instances, while only the instance being banged responds to (bang) is inconsistent and appears unintended, and therefore possibly a (fairly benign) bug.

Fixing this behaviour would not necessarily break existing patches (they could be easily modified if the tiny percentage of patches do break), but would make patching less of a headache and less of a time-waster.

Consistency of behaviour is something that has been occasionally overlooked in the history of the development of max. leading to unfortunate legacies (such as gate)-- I think it is better to fix inconsistencies at the expense of a few patches not working properly, than having idiosyncracies that are unexplained and waste enormous amounts of patch time 'debugging' and then trying to work around .

I guess I'm still not understanding the use case for this, but at any rate, thispoly~ is designed to reflect the state of specific instance of a poly~ patcher. If there are two thispoly~ in a patcher, and of them didn't reflect the state I would find that somewhat inconsistent. It's sort of like the ezadc and ezdac, which change to reflect the state of the MSP system.

Couldn't you just put a change on the thispoly~ output?

Chris I just needed to keep track of the last voice used, so the poly~ sends out its instance number when it's activated, so I thought the easiest way to do this was have a (mute 0) going to one instance of thispoly~, and (mute 1) going to a different one, so that the responses of thispoly~ to the (mute 0) and (mute 1) messages were split. In retrospect there are a number of (simple) solutions, using [grab], [gate], or in your example [change], but even though the workarounds to the thispoly~ behaviour are simple, it was annoying to me at the time, because I mistakenly assumed a certain behaviour, based on the principal of encapsulation, and therefore had a bit of trouble working out why my otherwise fabulous patch wasn't working...

I don't think the ezedac example necessarily applies here because it sets and gets system-wide global states, whereas thispoly~ is local to its enclosing poly~ instance; but I understand it is probably working according to a planned scheme/paradigm/protocol, and is therefore 'not a bug'.

Thanks for your input btw, appreciated