Forums > MaxMSP

Weird behaviour of "target" message with Poly~


EMV
May 3, 2010 | 8:51 pm

I found that with a Poly set to only one voice, this one voice is always the destination of data sent to the poly object, regardless of what "target #" is sent beforehand. Only "target -1", "target 0" and "target 1" behave as expected: -1 means the data goes nowhere, 0 means it goes to all (one) voices and 1 means it goes to voice one (the only one).

Put differently: with poly set to one voice, data is still received if I send "target 2" before sending the data.

You can check this with the poly~ help patch.

Is it supposed to be like this? Seems kinda strange…


May 4, 2010 | 3:05 am

did you try it with [poly~ foo 1] or with [poly~ foo]?

[poly~ foo 1] should behave normal.


May 4, 2010 | 9:43 am

i also found a similar situation where sending a message to a target which does not exist (> than number of voices in poly~) would lead to messages still being sent to other voices… even if, as Roman suggests, u add the number of voices as an argument to poly~.

which does seem strange!


May 4, 2010 | 10:47 am

here’s a test patch to demonstrate the issue, archive contains both main patch and poly patch. imo, it would be more logical if poly would ignore target messages beyond its voice count, rather than sending messages to the last voice available…

Attachments:
  1. poly_targetbug.zip


EMV
May 4, 2010 | 2:13 pm

@justin:

Yes, that is exactly what I mean. I just tested it with a voice count of 1. With 2 voices, it seems to work as it should.

@roman: both [poly~ foo 1] and

[poly~ foo 3] getting sent the "voices 1" message show this targeting bug. I checked that it is indeed set to 1 voice by sending "open 2", which gives an error because there is only one voice.


May 6, 2010 | 6:43 pm

can anyone else confirm? or explain if this is how it should behave…


May 7, 2010 | 4:41 pm

This is a feature, not a bug.

If you are dynamically changing the number of voices in the first place, then deal with the max target value at the same time if you want to avoid this functionality.

-Ben


May 7, 2010 | 6:31 pm

thanks ben.

could u provide an explanation for the feature… when would this scenario be useful? for the moment, i’ve been working around it. just thought it was bit strange!

j



EMV
May 7, 2010 | 7:03 pm

Although I can understand that it might be intentional (though like justin I can’t think of useful applications), it is inconsistent behaviour that is undocumented.

Anyway, thanks for clearing that up.


May 7, 2010 | 8:34 pm

I can definitely see both sides to this, but one way of thinking about it is if you are sending the target message in the first place, why would poly~ think you didn’t want it to do anything?

With this feature, it assumes that you still want to do something.

Sounds like you have found a suitable workaround. In the end it is a subjective design decision, but one that I’m sure was made a very long time ago, and at this point many patches have been constructed with this in mind.

What we can do is make sure it is better documented, which I’ll make sure happens.

-Ben


May 8, 2010 | 11:23 am

thanks ben


May 8, 2010 | 2:38 pm

And the next release’s documentation should make the state of affairs clearer.


Viewing 12 posts - 1 through 12 (of 12 total)