poly~ outlets temporarily spike to 0. when another voice becomes active?
I'm working with poly~ in a configuration where each of 10 voices gets its own audio outlet 1-10 (well, 0-9 really), but they share a single inlet. (The out~ object of each voice is recreated through scripting with their appropriate outlet assignment on load. This is for having static mappings of 'notes' to voices)
Voice activation/muting is controlled inside each voice, and a voice is turned On/Off via a message sequence like this to poly~:
target 1,
1. (on)
target 1,
0. (off)
Inside each voice, everything works fine as far as sending 'mute' messages to thispoly~.
But *sometimes* when I have a voice held on and another voice comes in, as in this message sequence:
target 1,
1. (voice 1 on)
target 2,
1. (voice 2 on) <<<<<<<
...the poly~ outlet for voice 1 has a blip. By that I mean from voice 1's outlet, an edge~ object (just there for debugging purposes) outputs bangs from both it's outlets when voice 2 comes on, indicating a momentary value change from 1. to 0. and back to 1.
What I don't understand is that after putting the same edge~ debugging code immediately before the out~ object inside the the voice patch itself, it shows no change (as expected). I put other 'detector' bangs to show any changes to the mute messages in the voice, and they aren't doing anything at the time of the change, either (as expected). See the screenshot.
So what can cause [poly~] to have a hiccup in a voice's output that appears not to be caused by anything within the voice itself?
And to be clear, I've triple-checked (via printing the inputs and the all the 'mute' messages in the voices to thispoly~) that the messages are being sent as I claimed they were. There's nothing inside the voices muting them.
it could be that the problem ist caused by the following: when there is a signal of "0.7", and then DSP is turned off, the receiving object still has that value in its inlet "cached". (and in the case of an [out~ 1] object, would multiply the other signals with that dead signal´s value.)
so try to hook up signal numberboxes or [capture~] to each signal before the output and then see what happens after a voice is turned off.
Are you sure that thispoly~ instance number gets reported only once. when poly voices get created?
you delete and create/reassign out~
at that point.
Would explain that strange
behviour.
In that case inserting change
would solve the problem
@Roman: Thanks, I'll remember about [capture~] for debugging things like this in the future.
@Source Audio: Direct hit... Battleship sunk! [change] was exactly what I needed. Thank you :)
I very much appreciate getting fresh sets of eyes to look at things to remind me of what (bogus) assumptions I was making.
Ha,ha. glad to have helped sink that beast.
I guessed that because most max objects with multiple outlets output all if a single thing to report change