A growing list of Suggested Practices
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.
MaxMSP Suggested Practices
https://docs.google.com/document/d/1ABFwLldpr0BURmpcSEg5xZY781q35x4ByKMAREt6j3U/edit?usp=sharing
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.
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?
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!
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.
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.)
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