|
|
May 3, 2010 at 8:51pm
Weird behaviour of "target" message with Poly~
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 at 3:05am
did you try it with [poly~ foo 1] or with [poly~ foo]?
[poly~ foo 1] should behave normal.
|
|
|
May 4, 2010 at 9:43am
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 at 10:47am
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…
|
|
|
May 4, 2010 at 2:13pm
@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 at 6:43pm
can anyone else confirm? or explain if this is how it should behave…
|
|
|
May 7, 2010 at 4:41pm
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 at 6:31pm
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
|
|
|
May 7, 2010 at 7:03pm
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 at 8:34pm
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 at 11:23am
|
|
|
May 8, 2010 at 2:38pm
And the next release’s documentation should make the state of affairs clearer.
|
