Forums > MaxMSP

16 Gate Timing Problem

April 22, 2013 | 11:26 pm

We are trying to make a basic mixer that can individually control the 16 channels. We are trying to set up Mute Individual, and Mute All buttons but are having trouble because the gates for channels 1 and 2 are closing before the mute messages can go through. Is there any way to fix this problem? Or an object to assist us with it?

The patch is attached to this post.


April 23, 2013 | 10:52 am

I’d suggest getting your logic sorted out with a stripped-down version of the patch (say, three channels).

I’m not seeing "timing" issues, per se, but problems with right-to-left ordering. But you’re more likely to get help with debugging with a stripped-down patch focussing on one task at a time.

Also, there are some problems in the Solo On/Off section. The fact that the big select object is not completely hooked up, that’s the smallest issue. The logic from the "Solo On" button down to the [select 1 2 ... 16] object is confused. Once you’ve set the content of the message box from the connected umenu, you might just as well use a [trigger b] object instead of the [if]. What’s the point of that [if] object?

Good luck with your project, and regards to your teacher! (who probably knows many of us)


April 23, 2013 | 3:49 pm

Thanks for the reply. We are new to max (which is probably obvious). We are meeting in a few hours and will get to work on this. In the mean time. Are gates a good way to go about this? Or are there more efficient ways that wont need us to hook up so many patch cords?


April 23, 2013 | 4:43 pm

The plain vanilla [gate] object has a slightly smaller footprint than the Graphic Gates, at least in terms of memory and (possibly) performance (although the latter is a microscopic concern). However, while you’re learning to use Max, the Graphic Gates give you visual feedback about what’s going on. So I would stick with them for now, and look at replacing them when you’ve got a better idea of what you’re doing in Max.

You can also look at [route], which could potentially reduce the number of objects in your patch.

Let me come back to the recommendation to start with a three-channel patch. You can sort out practically all of the situations you need to deal with in your larger project, but with less clutter (and fewer corrections to make every time you find a problem). Also, once you’ve got your head around how to build a single working channel in this configuration, you can encapsulate it into a single sub-patcher (the [p] object) or an abstraction (a .maxpat file than you can use over and over again).

Also, pay close attention to the right-to-left ordering thing. I know it seems quite a strange idea when you’re new to Max, but it’s actually a pretty brilliant system. However, it does take getting used to and will bite you when you’re not careful.

Good luck!


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