attn c74 thispoly~ misbehaviour

Floating Point's icon

if I send thispoly~ a bang it will report instance number. good.
but if I send a mute 0/1 message the instance is also reported. annoying-- it shouldn't do this

also if I make another instance of thispoly~ in the same abstraction (to be used in a poly~) then this other instance will report it's instance number when the first instance is banged, even though it is not connected to anything

maybe this is a bug

Chris Muir's icon

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

Floating Point's icon

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

Chris Muir's icon

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

Floating Point's icon

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:

Max Patch
Copy patch and select New From Clipboard in Max.

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...

mudang's icon

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

Max Patch
Copy patch and select New From Clipboard in Max.

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

Floating Point's icon

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

willyc's icon

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.

Max Patch
Copy patch and select New From Clipboard in Max.

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

Chris Muir's icon

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.

Floating Point's icon

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 .

Chris Muir's icon

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.

Max Patch
Copy patch and select New From Clipboard in Max.

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

Floating Point's icon

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