A growing list of Suggested Practices


    Feb 18 2019 | 5:31 pm
    I gathered some members of the Max community on Facebook to document their opinions on best practices within Max. In general there isn't a strong consensus on what "best" practices would be. However I believe gathering these different opinions can facilitate the sharing of ideas and maybe even debate on what is actually a good practice.
    This is a live Google document and that is open to everyone for contribution. I may eventually make a PDF document organizing the notes.

    • Feb 18 2019 | 6:06 pm
      Thank you for collecting this and sharing it. It looks to be an invaluable resource for seeing what others find to be good practices within Max.
    • Feb 18 2019 | 8:08 pm
      Thanks for this. I didn't know there was a penalty for using send and receive. I wonder what the difference is between them and a patch cable is?
    • Feb 18 2019 | 8:55 pm
      I second the wondering about send and receive! I had no idea it was inefficient.
      Thank you for putting this page together, it’s been insanely helpful!
    • Feb 18 2019 | 9:15 pm
      I wonder what the difference is between them and a patch cable is? it is two connections more; the ones to the send and from the receive object.
    • Feb 18 2019 | 9:18 pm
      Although send and receive are objects and therefore do incur some overhead beyond a simple patch cable, this overhead is generally going to be insignificant in the grander scheme of things, especially as these are used at control rate instead of signal rate. A few more low-level function calls. Unless you see a performance problem, I wouldn’t worry about it. (This is also standard programming practice: Do not optimise your code prematurely.)
      As for the comment somewhere in the document that send~ and receive~ incur a latency of one signal vector, the documentation for send~ specifically says (with my italics added):
      Note: The use of a send~ object introduces a delay of one signal vector in any send~- receive~ pair when a feedback loop is detected to allow for signal processing loops.
      As I read this, if there is no feedback loop, there is no additional latency. (But I must admit that I have not tested this to verify it.)
    • Feb 18 2019 | 10:37 pm
      As i understood it, the problem with using lots of send/receive pairs is not so much a problem of computing efficiency (as Ecuk says, in 99.99% of cases it will be insignificant) as much as a problem of code readability : if you send a value to a lot of receivers, you may lose track of everything that value will affect. Conversely, if you send from several source to the same receivers, you may have a lot of trouble understanding what is going on at some point. Another thing is if you reuse some of your code inside an abstraction, then instantiate that abstraction several times : if you didn't pay enough attention and the code you reuse includes casual send/receive, they will interfer between instances. Stuff like that are what is problematic about send/receive, not computing overhead