understanding thispoly~ @automute 1
Hi everyone,
I’m excited about the new @automute attribute for thispoly~, but I’m having trouble getting it to work.
I’m using it in combination with the @activeout attribute of curve~ in the patch below.
If I understand correctly, thispoly~ should automatically unmute an instance when it receives a note or midinote message, and then automatically mute the instance after it detects two silent vectors coming from line~ or curve~. Is that right?
In my patch, I can see that the second outlet of curve~ is outputting zero, but the instance stays active and doesn’t mute automatically. Am I missing something?
Thanks for your help,
Florent
Are there any example patches using the @automute attribute that demonstrate best practices?
My patch above is based on the help files, but clearly I’m doing something wrong!
Is the example from the poly~ help file actually muting the instances of poly~ ez-synth-automute?
I’m having a hard time understanding and implementing the automute attribute.
Hi! Have you figured it out? Seeing a similar issue using curve~ and thispoly @automute is unresponsive. I am using target instead of note though.
are you using Max 9.09 ?
"poly~: fixed automute handling at low signal vector sizes"
Am using 9.0.9. I checked and it actually does work with note/midinote messages now, just not when targeting specific voices
No, I still haven’t figured it out. From the tests I ran this summer, thispoly~ doesn’t report an instance’s state from its second outlet when @automute 1 is enabled, which makes it hard to know whether it’s actually working. For me, that’s a dealbreaker since I use the mute/unmute flag to drive a lot of stuff in my poly~ patches.
It’s a shame because this feature sounded promising, and I constantly run into issues using curve~ inside poly~ in a Max for Live device. I’ve actually stopped muting voices altogether at this point, which kind of defeats the purpose of using poly~ in the first place.
you could delay the end of curve bang to thispoly~ by a little bit to force report its state. Very clunky though and the delay time should be vector size dependent but I can't find the exact relation
FWIW, I've never found either @automute or the old-school way of using a signal to determine busy state of a poly~ instance to be terribly reliable, especially in the context of complex poly~ situations. As a matter or fact, in one of the few patches I have that used it, I just had to switch to using 1/0 messages to thispoly~, since all of my instances stopped turning off. naturally, trying to make a simple example works just fine....
\M
It’s interesting, in my poly~ patcher, the main issue is that some instances don’t turn on. Somehow curve~ behaves unpredictably, and debugging these things is incredibly tricky since poly~ itself is already an abstraction that I’m using inside a Max for Live device. There are too many layers of encapsulation, it becomes painfully time-consuming to trace what’s happening.
I just hope that one day I’ll have a ridiculously powerful computer so I can stop worrying about turning poly~ instances on and off altogether!
have you tried turning instances manually on with a "mute 0" message to thispoly~?
like say a note comes in, you send it to a [t l b] and the bang triggers a mute 0 and after that the note get's processed? this works pretty reliably for me.