nanoArchae

So I'm implementing a patch that's meant to accept a command string via a message, parse the arguments, and then send a series of messages to a play~ object.

For example, the initial message might look something like "snare 100 200 127 255 3" meaning the 'snare' buffer~ should be played for 200 ms, starting at 100 ms into the buffer, starting at half volume (127) and ending at full volume (255), and this should loop 3 times. Actually, I've already managed to get that type of thing working, but what I'm implementing involves a lot more variables and dynamics. This is still the basis however. The point is that I have a lot of looping, changing variables, math operations, and order-important evaluation going on in my current method (which is some byzantine mess of cords) and it's increasingly difficult to understand, modify, et c.

My question is: is there a conventional way to maintain state and variables in Max? My background is in textual programming languages, and I can't help but to think in terms of for loops, while loops, conditionals statements, small math operations, all of which I have been able to emulate in Max individually, but when I go to implement these seemingly simple algorithms, I end up with these giant confusing cord orgies, totally inelegant, constantly worrying about what is going to get evaluated first, and I'm often unable to figure out what I even did the previous day.

Is there any sort of object that I can use to get, set, compare, and manipulate variables via messages? This post is getting lengthy and tangential, but I envision something that I can send a message to like "x = 5" to assign a value to x, or "x = x + 1" or any other math operation, or "get x" which would send the value of x through its outlet, or "clear" which would clear the symbol table, et c. Does anything like that exist? Are there any other methods commonly used?

Any tips are much appreciated. Thank you in advance!

advice-with-maintaining-state-data-structs

I'll check that out, robtherich. Thank you.

p.s. I apologize for the dupe post, mods.

On Oct 18, 2007, at 4:57 PM, Robert Ramirez wrote:

Adjust the order of arguments in your message so that the right to left ordering of unpack's output works for you.

Yeap, the unpack definitely helps parse. I've found pattrhub is nice too. Thanks guys

Take a look at the value, pv, and pvar objects. Value functions similar to a global variable so it might provide a familiar way of working for you.

Re: patch readability. I often use a single inlet to a subpatch followed by a route object. For your example you could have a [route sample offset volume_begin volume_end repeat] then prepend each of your values with the appropriate attribute name. (This approach was recently mentioned in the oo programming for max thread...worth checking out.) Note this doesn't magically solve the order-of-operation issues, but it can make it easier to understand which message does what.

Re: patch readability. I often use a single inlet to a subpatch followed by a route object. For your example you could have a [route sample offset volume_begin volume_end repeat] then prepend   each of your values with the appropriate attribute name. (This approach was recently mentioned in the oo programming for max thread...worth checking out.) Note this doesn't magically solve the order-of-operation issues, but it can make it easier to understand which message does what.


Advice with maintaining state / data structs