Did some more testing and nothing. Messages are making it to the poly, messages are making it inside the poly. Initially muting it from the outside (mute 0 1) doesn't help. There appears to be absolutely no rhyme or reason to it. It either works, or it doesn't....
This is inside a pretty big max patch, and there are 8 instances (total) of this section, but they all fail, or don't, the same way. It never happens that one instance works, but another doesn't. They all work, or none work.
I don't see anything obvious. Something that I've noticed when using groove~ inside poly~ patches is the need to loadmess the "stop" message to it, since it will automatically play when DSP turns on.
Is there a reason you're not using trapezoid~ with groove~? (and configuring your looppoints via groove~?) I ask because then you could use the right outlet of groove~ with ==~ 1 and edge~ to signal done. Where possible I link playback and envelope so there's less possible timing issues. Again, I don't see anything that looks like it shouldn't work, though I don't have your trapezoidal envelope file.
You might also try providing a default value to the sig~ and line~ going into groove~ so it's non-zero. (sig~ 1)
- Is it possible that you're generating any 0 duration events? You might try looking at poly~'s mute/busy values.
- What happens when you turn on voice-stealing? If this takes care of it, it usually means you have a condition where something isn't ending.
Not using trapezoid~ as the enveloped cycle~ is handling windowing, and the line~ driving it handles the muting.
I've changed the default values of sig/line, but that didn't seem to have an impact either.
No 0 duration events coming in. Voice stealing doesn't help, and by looking at one instance, the busy flag (output of thispoly) is always on.
I did however, discover the problem (I think).
For some reason, cycle~ isn't outputting anything (sometimes), unless I dig into the poly and manually load the window into it.
Sometimes it just works on it's own. But if it's not working, that seems to force it to work. This doesn't make sense either....
What makes all of this weirder is that this same poly is used elsewhere in my patch, and I've never had a problem with it there.
Seems promising! Dozens of testings on both my machines, as well as Max restarts, and it's yet to fail again (using wave~)!!
What kind of cycle~ problems have you had in the past Dave? I'm in the middle of a bug report for cycle~, but finding it tricky to reduce down the main part of my patch that has this while keeping it functional (so many abstracted abstractions, with centralized analysis elsewhere in the patch etc...)
I remember I had some trouble with replacing the buffer~ contents. Cycle~ wouldn't always update the new buffer~ contents. Since then I regularly use wave~ instead. But it's been a while since I had this problem. So I'm not sure if it's a bug.
The issue you're having with cycle~ might be related to the different length of cycle~ as of Max 6. It used to be 512 samples, but I think it's bigger now (16384, IIRC).
The other unexpected thing that can happen with cycle~ is that the phase inlet happens in addition to the internal phase accumulator of cycle~, rather than replacing it. (try sending phasor~ 500 into the right inlet, and set cycle~'s frequency to 500) I like using that combo as a way of demonstrating to students the linkage between phase and frequency.