Poly~ not unmuting?

    Feb 06 2013 | 4:19 pm
    I'm pulling my hair out with this. It seems to work about 30-40% of the time, and I can't figure out what's wrong.
    Name this as "concat~"
    This is the part right above it:
    (this second part is nested inside an abstraction that populates the arguments)

    • Feb 06 2013 | 6:14 pm
      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.
    • Feb 06 2013 | 8:48 pm
      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.
    • Feb 07 2013 | 8:54 am
      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.
    • Feb 08 2013 | 7:57 am
      You can try wave~ instead of cycle~. I remember I ran into problems with cycle~ before too.
    • Feb 08 2013 | 10:20 am
      I'll try that. After my last test I thought maybe that cycle~ wouldn't load of the dsp was muted, but loading the wavetable before muting the DSP doesn't help.
      So it'd be just this instead? (I've never used wave~ this way)
    • Feb 08 2013 | 5:53 pm
      I also tried just naming cycle~ with the buffer, as I'm not changing it at all. Still intermittent....
      Super frustrating!
      Also can't seem to figure out how to drive wave~ with line~ (or using it as a cycle~ replacement).
      (I submitted a bug report about cycle~)
    • Feb 08 2013 | 7:53 pm
      You connected line~ to wave~ correctly.
    • Feb 08 2013 | 8:43 pm
      It doesn't seem to be doing anything though.
      Here it is isolated down.
    • Feb 08 2013 | 9:10 pm
      You have to set the end point for wave~(in ms), otherwise it uses the whole buffer~. You could alternately use the sizeinsamps attribute to change the buffer size to 512, which I would recommend.
    • Feb 08 2013 | 9:28 pm
      That's it. I still wonder if this solves your problem.
    • Feb 09 2013 | 1:29 pm
      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...)
    • Feb 09 2013 | 3:27 pm
      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.
    • Feb 09 2013 | 5:36 pm
      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.
    • Feb 09 2013 | 8:47 pm
      Interesting. For the purposes of the patch wave~ is working gangbusters so I'll just use that instead of cycle~ from now on and hopefully it's not more CPU intensive.