What's the most difficult part of Max you've had to wrap your head around?
I pose this question as past or present. What was the hardest thing you had to understand when studying it? I find for me, at least currently, understanding it broadly and how to use it, is easy. Becoming familiar with it's many objects is difficult and tedious. I've even considered making flash cards but... how many damn cards would that be. I want to sit down and sketch out ideas but I feel like I would need to read through every object to make sure I know what's available and how to use it. Maybe I'm approaching this incorrectly. Your thoughts?
All the (largely undocumented) 'extra' stuff you need to do with any audio recording/playback stuff. ie declicking type things
And the pattr system
Thought: work through the tutorials. Try things out along the way. And, the tutorial topic that seems least relevant to you the first time through may become the most important in your later work. So, even if you feel like skimming, don't skim too much.-)
Once you've got an idea of the breadth of Max/MSP/Jitter objects, take your problems and try to recognize an object (or group of objects) relevant to the problem at hand. Check out the .maxhelp file. Do *not* skip this step early on—the help system gives pointers to related object that may be more appropriate to the problem you're trying to solve. This is where you get more into the depth of Max objects.
Repeat.
In addition to the excellent advice you have received from Peter Castine, I would also point out that the arrival of the new Cycling '74 Wiki offers you some additional pedagogical opportunities.
An approach to teaching and learning Max has been developed in-house over the course of a number of workshops called "The 20 Objects," which organizes one's exposure to Max by way of a small number of objects (and object "helpers") that most Max programmers use all the time. Some people have found it to be an approach that works for them. You can find those materials here:
The Wiki also contains a recently revised collection of MSP tutorials which track the major revision of the Max tutorials we undertook a few years back - as is the case with the current Max tutorials, they are organized by the type of work being done. You will find them here:
You may find them to be useful for your needs. As a personal aside, I believe that Peter's advice about not skimming the most basic parts of learning how Max handles messages and does the most basic of things should be written in large multistory neon letters.
For me:
*when you just start out.. right to left and hot and cold inlets... getting everything to execute in the right order
* a little later, more timing, eg how [delay] and [wait] affect execution
* definitely the 'hidden' things: Max for Live could do with a lot more explanation for sure
I haven't got my head arround pattr and dict yet, they seem very useful but I haven't managed to incorporate them, every time I want to 'quickly' include them I find I need to spend more time to first understand them.
All the advice above is spot on. Also: allow yourself time to learn this: accept that your first patches may be a bit clumsy and inefficient, a year later they will be a lot better. The great thing about Max is that those first clumsy and inefficient patches can already be useful, fun and pretty much blow you away for the sheer possibillities
Some years of teaching showed to me that it's hard for beginners to accept that an argument is not visually modified in an object upon reception of a new value in the corresponding inlet.
My personal hardest times with Max happen when I want to combine all those magnificent things which work nicely alone but not so well when put together: nice GUI with bpatchers, dynamic circuits and CPU management with poly~, presets and presets of presets with pattr, remote connections, etc. I would like to see much more consideration for global integration in the development of Max. Consider this example : function is great to draw envelopes, zigzag~ is super to play envelopes and manipulate them, and poly~ is great to create a polyphonic synth. Now try to to create a GUI with a function to draw an envelope and then send it to the zigzag~ you have in every voice of the poly~ used as sound engine. Could be easier, no ? And please please please do not suggest to use adsr~ in place of zigzag~ (adsr belongs to history of synthesis, leave it there).
Dealing with discrepancies is another problem : why should one use "open" to load a soundfile with sfplay~ and "read","replace"or "import"with buffer~ ? Integration again...
Forgetting the names of objects is Nature's way of getting you to learn about new ones :-)
What I like about Max is that there are usually many different ways to do the same thing, so there is no need to try and remember what every object does - usually you can find your way there within a few .help files.
It's true that there are discrepancies, but I'm glad that Cycling have always tried to maintain backwards compatibility, and not changed things that would break old patches.
That's probably a bit selfish, as it means that Max is made a little harder for newcomers to learn in order to keep us old farts happy, but you'll be glad of it one day ;-)
As a non-programmer, though, I do struggle with some of the objects that use C syntax like expr, sprintf etc. - I wouldn't even go near something like regexp!
Cheers
Roger
I think we all love Max otherwise we wouldn't be here :-)
I would love to see some more comparisons between alternatives to help choose the right tool (eg https://cycling74.com/forums/bag-bucket-capture-coll-funbuff-offer-table-dict)
and, though I love how max is easy to learn and quite immediate to get results, at times I would like a more abstract or academic explanation - like the ones on threading and scheduler priority are quite helpful.