Forums > MaxMSP

Timing issues = cacophony

Aug 19 2010 | 9:48 pm

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.

The reset is where I’m having problems.

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.

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.

Any help would be greatly appreciated.


-- Pasted Max Patch, click to expand. --

Aug 20 2010 | 12:01 am

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.

Aug 20 2010 | 5:34 am

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

-- Pasted Max Patch, click to expand. --

Aug 23 2010 | 7:40 pm

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.

Aug 24 2010 | 12:01 pm

*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.

Aug 24 2010 | 12:05 pm

one more thing.

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


Aug 25 2010 | 2:12 am

Point taken.

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.

Viewing 7 posts - 1 through 7 (of 7 total)

Forums > MaxMSP