Random Thoughts About Teaching Max
One day a bunch Cycling '74 employees were hanging around the water cooler, talking about teaching Max. Here are a few of the gems.
Where To Start
What's more fun, a power saw or a hand saw?
So I like to focus on automatic stuff first. Metro in other words.
Before you are going to teach a group of people, spend some time around them.
Art students are *fascinated* by sound, they hunger for it, but they can't understand MSP until they've learned some Jitter first. First thing you have to do is show them their own face. Make them patch along with you patch to get the camera input and display it for them. You will hear the room sigh with delight as they click the "open" message and gaze at their digital reflection. Now you introduce jit.plur and let them play for 20 minutes. Suggest they update their Facebook profile. Once you get them back from outer ravespace you throw a peakamp~ into the mix and bam, they are new media artists.
Document your teaching path, and be serious about altering it based on student feedback. Not all student feedback comes in the form of a survey; a student that falls asleep is providing pointed feedback. The inability of students to understand the difference between a message box and an object box is also important feedback.
Try to structure things to provide individual time with people. This not only helps them personalize their experience with Max, but it also allows you to review their work
Check in with the student(s) constantly. "What message is coming out of this outlet?" Make sure they're actually getting it.
I also just want to highlight one idea Luke brought up -- peer review. When I took a MOOC the best thing about it was the enforced peer grading system in which getting "credit" for the class required me to evaluate the work of other students. Looking at their work was the perfect complement to the lectures. But I found some kind of formal enforcement of this process was necessary because the last thing I would naturally do is want to judge my peers. Once given a push I found it valuable and enjoyable. In the Coursera system the chance for abuse is minimized by the having 3-5 people have to look at your assignment.
Just make sure you know the rules and regulations of your institution though... The peer review thing is actually against the rules at UMKC, and having students grade each other's work will get you immediately fired for breaches of privacy.
Have your students patching constantly. Max is not conducive to lecturing; lectures only increase the time between patch creations, and hands-on time seems to be the best teacher of all.
make them patch early and often, and constantly reinforce the basics.
Max is something you do. A lot of it is muscle memory, of a sort. It's a tactile sort of programming. I start with buttons. Making lots of buttons. I use that as an opportunity to introduce the cast of characters in the sidebar. Change size, change color, connect 100 buttons and lock the patch and click. Which buttons flashed? Who got an error message? Lock and unlock the patch explicitly at least 20 times in the first 10 minutes. Tell them to do *everything you do. This helps you slow down and helps them get some lived hands-on experience.
For musicians, I like the assignment of making something ugly or broken. Get the students to focus on a goal where they can't fail aesthetically, so they can be more curious about how stuff works.
This is a Zen technique. Instead of judging whether something's good, go into it more. Be more curious. You are only assured of getting beginner's mind at the beginning. Embrace it.
Andrew and I taught the high school class at the office a few years back, and I came away thinking that having two instructors is essential if you have a group of any size. One person to be at the front of the room, and one person to float, see how people are doing, and just generally be available. It probably depends on the group, but it seemed to put people more at ease.
My approach (based on the fact that I'm usually teaching grad students) is to throw as much on the wall as I can and see what sticks. In that sense I teach the course as a survey.
I'll chase digressions if it has a chance of yielding something ("how does the FFT work?") but I always make it clear that they don't have to freak out about what I'm about to plunge into, and they can even tune out if it is too stressful. Other digressions I avoid like the plague ("how does the scheduler work?"): um, it's magic.
The required "mid-term exam". I buy a bunch of pizza, break them up into groups of 3 (I choose the groups), and then they have to put together a piece/performance. They have 90 minutes, and then the concert. The students who otherwise struggle are able, at a minimum, to see how the process from nothing to something.
I thought that teaching people to sketch processes on paper first would be a good idea, but in practice it never worked. Better to just get them patching ASAP. Sketching makes more sense when a specific large project idea comes along.
it really is surprising how often I will show people some fun Vizzie-based stuff and then dive into standard Max programming, and they are willing to take the leap with me.
- here are ten things you need to know about max. last touched in 2004, but still fairly relevant.: Media:tenthings.zip
- patching roadblocks could be solved by these questions, regarding any particular object's inlets: 1) what is the type of data coming in (and what is it supposed to be), 2) what is the rate of the data coming in (and what is it supposed to be), 3) what is the range of the data coming in (and what is it supposed to be).
- do the signal theory, but use max to teach it.
- get them addicted to spelunking around the c74 site and maxobjects.com for things to look at, try out and hijack.
- make them incorporate their own media (sounds, images, videos, 3d models, whatever) into any assignments or group work in-class so they feel invested in the outcome and don't feel it's just an exercise.
- there is always a way to inspire, and it's different with every student.
- Knowing how to add debug prints, number boxes, and pwindows.
Although a lot of people are attracted to Max because they want to avoid more traditional programming languages (myself included), I've always thought it would be a great addition to our documentation/web content to do a series of tutorials that focus on this very topic.
In my classes I found that the ugly music the students do with beginner's mind is always better than anything else they ever do during the rest of the class.
Watch your vocabulary and your speech patterns. Using phrases that are ultra-familiar to you, but unfamiliar to regular people ("... just like a biquad filter ..." or "... you need to change the scheduler ..."), proves that you are really smart - and that Max is really hard. Using contextually appropriate language can help some people, but can confuse others that aren't as invested in that context. Try to practice your speaking so you can avoid um's and ah's (this was a very difficult one for me). Slow down your speaking to whatever extent you can.
…plan everything…If you walk into a classroom without at least having an outline, you are going to do a disservice to the students. Outlines - along with occasional preset text and pre-made patches - prevent you from falling into bad habits, chasing rabbit trails or geeking out. Learn appropriate ways to say "We'll talk about that later": this often comes in the form of saying "We'll talk about that later" and actually following through on it rather quickly. This way, students know that you aren't brushing off their concerns or interests.
I never plan lessons unless I'm teaching someone else's class, but I've also taught the same class for 4 years. I have a general idea (Sampler or Feedback) and see what happens once I start talking and they start asking questions. I like to get across the idea that Max is open ended, and you can start with a simple idea and end up going completely weird on it. … I'll often do something and make like 5 or 10 copies of it and see what happens with a bunch of the same patch. I'll combine previous class patches with current class patches and see if it works. I'll copy, paste, and make lots of dumb mistakes, and cheat all over the place. All of it eventually leads to them asking questions and making mistakes of their own. Every group of students is different, with a different set of collective needs. Just focus on the people, getting them talking to each other and to you, and how to teach them becomes apparent.
Shoot to cover about 75% of the material you think you could cover; this will probably give you enough time to answer questions, spend time with individuals, and follow the occasional student-led rabbit trail.
Lately I'm obsessed with this idea of manipulating time for projects, both for myself and students. Forcing a finished product early on is very different from saying they can incrementally finish things over several weeks or turning them loose for a whole semester to finish a project. Each time-scale makes for different awarenesses and types of work. I usually give very short-term assignments at the beginning of the semester to force certain higher-level concepts like Performing, or Making Whatever Work, etc. I find if you make someone finish something stupid quickly, then they are far more prepared to *finish* something smart later.
Use people's experience to lead them to new experiences.