Gregory Taylor

When I started this series of short "advice" pieces to Max/MSP/Jitter beginners, I also decided to ask a number of my friends and colleagues about what 

 ideas of what good advice might be so that you won't be left with just 

There was one piece of advice I wouldn't really give, but it's been showing up in every other set of answers I've gotten back, so I've decided to honor it by mentioning it here:

I expect that the idea behind this piece of advice is that you'll learn Max/MSP/Jitter more thoroughly if, when you're starting out, you try to create your own little patches that solve some problem you encounter rather than relying on having someone else write an external that does the task. Some teachers actually require that you do this when you take a beginning Max course from them, even.

The part of this advice that I am in some agreement with goes like this: It is 

 easy to fall into the habit of dependency when you're first learning Max (that is, to beg and borrow patches from others rather than spending the time to think about a problem and to solve it yourself) that 

 that coaxes you away from borrowing the work of others will, in the long run, make you a better Max programmer.

 one of the things that separates "power users" from the faceless Max masses...they build while others beg. :-)

I'm personally a lot less doctrinaire about this. First, it's true that it's simply faster and more efficient to have an external that does some types of things in Max as opposed to a large and complex subpatch. And it's true that searching something like the 

 will also demonstrate that there might not only be several solutions to a Max programming problem, but that there will often be more than one Max external out there that does something similar. Similarly, the same might be said of other people's subpatches. From time to time, it's been useful to me to see the kinds of solutions that other people come up with. In some cases, I think that one is always tempted to somehow believe that there is only one "right" way to solve any Max problem, and one of the interesting things that comes from working on a problem by yourself and 

 seeing other ways you might have solved the same problem is the realization that you're quite capable of coming up with interesting and idiosyncratic solutions on your own. But I am usually interested in seeing other people's work as my 

When I started this series of short "advice" pieces to Max/MSP/Jitter beginners, I also decided to ask a number of my friends and colleagues about what their ideas of what good advice might be so that you won't be left with just my admittedly biased advice set.

When you begin learning Max/MSP/Jitter, don't use any third-party objects (i.e., objects that someone else wrote that aren't a part of the standard distribution). If you need to do something that's not included in the "standard set," solve the problem by creating your own patches or abstractions.

The part of this advice that I am in some agreement with goes like this: It is so easy to fall into the habit of dependency when you're first learning Max (that is, to beg and borrow patches from others rather than spending the time to think about a problem and to solve it yourself) that anything that coaxes you away from borrowing the work of others will, in the long run, make you a better Max programmer.

Come to think of it, maybe that's one of the things that separates "power users" from the faceless Max masses...they build while others beg. :-)

I'm personally a lot less doctrinaire about this. First, it's true that it's simply faster and more efficient to have an external that does some types of things in Max as opposed to a large and complex subpatch. And it's true that searching something like the Max objects database will also demonstrate that there might not only be several solutions to a Max programming problem, but that there will often be more than one Max external out there that does something similar. Similarly, the same might be said of other people's subpatches. From time to time, it's been useful to me to see the kinds of solutions that other people come up with. In some cases, I think that one is always tempted to somehow believe that there is only one "right" way to solve any Max problem, and one of the interesting things that comes from working on a problem by yourself and then seeing other ways you might have solved the same problem is the realization that you're quite capable of coming up with interesting and idiosyncratic solutions on your own. But I am usually interested in seeing other people's work as my second resort.

When I started this series of short "advice" pieces to Max/MSP/Jitter beginners, I also decided to ask a number of my friends and colleagues about what their ideas of what good advice might be so that you won't be left with just my admittedly biased advice set...

Things OTHERS wish people had told THEM