Poly~ not unmuting?

Feb 6, 2013 at 4:19pm

Poly~ not unmuting?

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~”

– Pasted Max Patch, click to expand. –

This is the part right above it:

– Pasted Max Patch, click to expand. –

(this second part is nested inside an abstraction that populates the arguments)

#66380
Feb 6, 2013 at 6:14pm

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.

#238930
Feb 6, 2013 at 8:48pm

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.

#238931
Feb 7, 2013 at 8:54am

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.

#238932
Feb 8, 2013 at 7:57am

You can try wave~ instead of cycle~. I remember I ran into problems with cycle~ before too.

#238933
Feb 8, 2013 at 10:20am

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)

– Pasted Max Patch, click to expand. –
#238934
Feb 8, 2013 at 5:53pm

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~)

#238935
Feb 8, 2013 at 7:53pm

You connected line~ to wave~ correctly.

#238936
Feb 8, 2013 at 8:43pm

It doesn’t seem to be doing anything though.

Here it is isolated down.

– Pasted Max Patch, click to expand. –
#238937
Feb 8, 2013 at 9:10pm

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.

– Pasted Max Patch, click to expand. –
#238938
Feb 8, 2013 at 9:28pm

That’s it. I still wonder if this solves your problem.

#238939
Feb 9, 2013 at 1:29pm

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…)

#238940
Feb 9, 2013 at 3:27pm

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.

#238941
Feb 9, 2013 at 5:36pm

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.

#238942
Feb 9, 2013 at 8:47pm

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.

#238943

You must be logged in to reply to this topic.