attn c74 thispoly~ misbehaviour

Jul 25, 2011 at 5:12am

attn c74 thispoly~ misbehaviour

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

#58171
Jul 25, 2011 at 5:54am

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

#208912
Jul 25, 2011 at 9:42am

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

#208913
Jul 25, 2011 at 9:47am

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

#208914
Jul 25, 2011 at 10:31am

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…

– Pasted Max Patch, click to expand. –
#208915
Jul 25, 2011 at 11:07am

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!

– Pasted Max Patch, click to expand. –
#208916
Jul 25, 2011 at 1:29pm

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

#208917
Aug 13, 2011 at 12:17pm

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

– Pasted Max Patch, click to expand. –
#208918
Aug 13, 2011 at 5:25pm

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.

#208919
Aug 14, 2011 at 2:06am

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 .

#208920
Aug 14, 2011 at 3:27am

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?

– Pasted Max Patch, click to expand. –
#208921
Aug 15, 2011 at 12:42am

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

#208922

You must be logged in to reply to this topic.