Having major issues with timing on this patch I'm working on.

Basically: eight samples of indeterminate length are loaded into buffers. The buffers are chained together, so for instance in order for the second buffer to be triggered, The first buffer can not have been triggered. Each time a buffer is triggered it will play a small portion of its contents, and the chances of it being triggered again decrease. All buffers are sent through a gate, which if open, allows another sound to be triggered once the one playing finishes. Each buffer can be triggered ten times, and when the last buffer is triggered the final time, it sends a bang to reset values and begin the process again.

Expected Behavior: Final buffer subpatch sends bang out of third outlet; Gate is closed, reset message is sent to subpatches, gate is opened, bang is sent to trigger the first buffer again.

Observed Behavior: Bang is sent. All buffers trigger near instantaneously. Gate closes, but does not reopen.

-Increasing the involved delay objects to ridiculous lengths

-Putting a delay between the last buffer's bang and the reset message (stack overflow)

-Moving objects all over to see if it had something to do with how Max gives objects precedence.

I've tried:
-Increasing the involved delay objects to ridiculous lengths
-Putting a delay between the last buffer's bang and the reset message (stack overflow)
-Moving objects all over to see if it had something to do with how Max gives objects precedence.

timing-issues-cacophony

I didn't dig very deep into your patch. But all those delays I don't particularly like. I have always been told that delays are "evil" (slight exaggeration maybe) and should be used sparingly.

First thing I would do is get rid of as many as I can. For example all the delays inside your [p shallnotpass] subpatches can be exchanged for the bang from the right outlet from the line~ object. The line~ will give you bang each time the line is finished, and by the looks of it that's what you are after.

Also, the delays on the surface seem to be easily removed by taking a quick look at order of operations. Look into [trigger] for that one.

Gotta get back to work. Hope that helps somewhat.

First thing I would do is get rid of as many as I can. For example all the delays inside your [p shallnotpass] subpatches can be exchanged for the bang from the right outlet from the line~ object. The line~ will give you bang each time the line is finished, and by the looks of it that's what you are after.
Also, the delays on the surface seem to be easily removed by taking a quick look at order of operations. Look into [trigger] for that one.

Gotta get back to work. Hope that helps somewhat.


Good call on the line~ bang, made things a good bit cleaner. I replaced the string of delays in the main patch with a 4 bang trigger. Didn't fix my issue, but it hasn't made it any worse (and it looks nicer).

Okay, I've sorted out the issue I had with the reset...Trouble is, now I'm having a different, stupider problem.

The audio is stopping periodically. Each segment is supposed to be triggered by the end of the segment before it, via the bang that comes out of the shallnotpass patcher's leftmost outlet. the signal must be getting lost somewhere, but I have no idea where.

Patcher is attached, since I figure we don't need another huge block of code on this page.

A) cut things out of your patch until you isolate the problem.

B) post it and we'll tell you what's going on.

I'm dun gone tell ya somethin' fer yer own good: your patch is insane. It's ok to patch together spaghetti for yourself but asking strangers to read it won't yield good answers.

One thing I can reliably say is this: waiting for a sound to end to bang and trigger another sound sometimes ok but won't yield anything close to exact timing.

*opens timingissues.maxpat*
*blinks with xylophone effect*

A) cut things out of your patch until you isolate the problem.
B) post it and we'll tell you what's going on.

I'm dun gone tell ya somethin' fer yer own good: your patch is insane.  It's ok to patch together spaghetti for yourself but asking strangers to read it won't yield good answers.

One thing I can reliably say is this: waiting for a sound to end to bang and trigger another sound sometimes ok but won't yield anything close to exact timing.


copy/paste redundancy like that is a bad sign. you need multiple buffers, of course, but other than that, you should look to simplify.

copy/paste redundancy like that is a bad sign.  you need multiple buffers, of course, but other than that, you should look to simplify.

I'm sorting out a new version that basically uses coll objects for everything, and looks a hell of a lot cleaner. So far I've nailed down the probability aspect and loading the samples. Once I've sorted out playback I'll post it here, for advice on form or (hopefully not) help with any critical errors.

Timing issues = cacophony