<?xml version='1.0' encoding='UTF-8'?>

<?xml-stylesheet href="./_c74_tut.xsl" type="text/xsl"?>

<chapter name="Max Basic Tutorial 16: Remote Messaging">

<setdocpatch name="16mRemoteMessaging" patch="16mRemoteMessaging.maxpat"/>
<previous name="basicchapter15">Abstractions</previous>
<next name="basicchapter17">Data Structures and Probability</next>
<parent name="00_maxindex">Max Tutorials</parent>

<indexinfo category="Basics" title="Remote Messaging">Sending messages without patchcords</indexinfo>

<h1>Tutorial 16: Remote Messaging</h1>

<h2>Introduction</h2>

<p>So far in these tutorials, all messages between objects have been sent using patch cords.  Here we investigate another way to transfer messages between objects – by using the <i>remote messaging</i> mechanism built into Max.  There are specific objects for this called, <o>send</o> and <o>receive</o>, as well as methods for sending a <o>message</o> box's contents to an object. Finally, we use some objects that allow the storage of variable data and can share values throughout complex patches.</p>

<p>As our designs get more complex, we need to take advantage of more techniques to modularize and compartmentalize our patches, making them easier to understand, maintain and extend. When our patches contain a lot of objects, long winding patch cord connections can cause unnecessary visual complexity.  Using tools that allow message passing without patch cords can clean up our patches without changing how they operate.</p>

<p>To open the tutorial patch, click on the <b>Open Tutorial</b> button in the upper right-hand corner of the documentation window.</p>

<h2>Playing with <o>send</o> and <o>receive</o></h2>
<techdetail>
	<m>Technical note:</m> Many of the objects in the tutorial patch are colored to help you find related pairs of objects, but color has nothing to do with routing messages.
</techdetail>
<p>The most common way to send messages without patch cords is through the use of the <o>send</o> and <o>receive</o> objects.  If we look at the tutorial patcher, the top left part of the patch shows a pairing of <o>send</o> and <o>receive</o> objects that pass an integer value.  When we change the top <o>number</o> box, the integer value is passed to the <o>send</o> <m>fred</m> object. This value is “broadcast” throughout the Max environment, and can be “received” by any <o>receive</o> object with the name <m>fred</m>. In this case, the <o>receive</o> <m>fred</m> object immediately below gets the message, and outputs it to be displayed in the attached <o>number</o> box.</p>

<p>Since a message is broadcast by <i>name,</i> any <o>receive</o> object sharing the <o>send</o> object's <m>name</m> can receive the message.  Hence, you can have more than one <o>receive</o> object for a message, and more than one <o>send</o> object sending messages using a single <m>name</m>.  In our test patch, the <o>slider</o> system connected to the <o>send </o> <m>bob</m> object does just that – it sends the value (set with either the <o>slider</o> or the <o>number</o> box) to all <o>receive</o> objects of <m>bob</m> messages.  At the lower right of the patch are two different <o>receive </o> <m>bob</m> objects: one connected to a <o>slider</o> system, while another is connected directly to a <o>number</o> box.  Changing the top <o>slider</o> value changes both of the receiving values simultaneously.</p>

<p>When working with pairs of <o>send</o> and <o>receive</o> objects, it’s important to realize that the message will be grabbed by any <o>receive</o> object anywhere in the Max environment – even in another patcher.  To test this, open a new patcher (selecting <b>New Patcher</b> from the <b>File</b> menu). Add a new object, and enter <o>receive </o> <m>bob</m>.  Connect the output of the <o>receive</o> object to a <o>number</o> box, then return to the tutorial patch.  If you change our test <o>slider</o>, you will see the output received in the new patch as well as all other <o>receive </o> <m>bob</m> objects in the main patcher.</p>

<p>When working with other people’s patches, you may see objects named “s” or “r”.  Since the <o>send</o> and <o>receive</o> objects are so popular, they have <i>alias</i> (or shorthand) names of “s” and “r” respectively.  In addition to being easier to type, these shortcut names also allow you to keep the object small!</p>

<h2>Working with <m>;</m> and <o>forward</o></h2>

<p>Another common use of remote messaging is to send the contents of a <o>message</o> box to one or more <o>receive</o> objects. Rather than always having to connect <o>message</o> boxes to <o>send</o> objects, there is a special format of the <o>message</o> box that can directly send messages to <o>receive</o> objects.  This involves placing a semicolon (<m>;</m>) and the <m>name</m> of a <o>receive</o> object in front of the message.  Thus, <m>; bob 155</m> is the equivalent of sending the value <m>155</m> to any <o>receive</o> object named <m>bob</m>.</p>

<p>The large gold <m>message</m> box at the bottom-left of the patch is an example of direct message sending.  Four messages are generated: two are sent to <m>lcd1</m> destinations, and two are sent to <m>lcd2</m> destinations.  If you click on the <o>message</o> box, you will see that the two <o>lcd</o> objects each receive the appropriate draw commands through their respective <o>receive</o> objects - the top <o>lcd</o> (<m>lcd1</m>) draws a blue circle; the bottom <o>lcd</o> (<m>lcd2</m>) draws a green rectangle.</p>

<p>Another common need we might have is to send messages to one of several destinations based on some logical criteria.  This can be done using switching logic (e.g. the <o>gate</o> object connected to different <o>send</o> objects).  However, we can also use the <o>forward</o> object to route messages to selected locations.  Just above our green <o>message</o> box example is a <o>forward</o> object with supporting logic.</p>

<p>You can select which named destination should receive the messages from <o>forward</o>: the <m>send</m> message, sent to the <o>forward</o> object, will set the destination name for any incoming messages.  Once a destination has been set, all messages will be routed appropriately.  If we click on the <m>send lcd1</m> message, changes to the <o>number</o> box will cause a colored rectangle to be created in the first <o>lcd</o> object.  If we click on the <m>send lcd2</m> message, it changes the output destination of the <o>forward</o> object to the <o>receive</o> <m>lcd2</m> object.  Now, any changes to the <o>number</o> box will cause the creation of a rectangle in the second <o>lcd</o> object.</p>

<p>By a similar token, a <o>receive</o> object with <i>no</i> arguments can be used to receive messages from any named <o>send</o> or appropriately configured <o>forward</o> or <o>message</o> box.  The <m>set</m> message to the <o>receive</o> object allows it to "switch names", so to speak, so that it can listen to different parts of the patcher.  Next to our <o>forward</o> object is one such <o>receive</o> object.  By switching it between listening to <m>bob</m> and <m>fred</m> (using the <o>message</o> boxes) and then manipulating the <o>number</o> box and <o>slider</o> object sending to those names, we can see how this works.  Setting the <o>receive</o> to a <m>name</m> that doesn't exist (e.g. <m>none</m>) will disconnect it from listening to anything in our patch.  Note that in order for a <o>receive</o> object to be "switchable", it needs to be created <i>without</i> an argument (otherwise it has no inlet).</p>

<h2>The <o>int</o>, <o>float</o>, and <o>value</o> objects</h2>

<p>Sometimes, when working with patch programming, we need a place to stash a value until we need to use it.  While we could use integer and floating-point <o>number</o> boxes, those objects have the possibility of having the user change the value through their UI.  In order to provide simple variable storage and recall, there are a set of objects specifically used for this purpose.  The <o>int</o> and <o>float</o> objects can act as temporary storage of values; values coming in the <i>left</i> inlet are stored and sent out the outlet immediately, while values coming in the <i>right</i> inlet are stored without output.  If you want to retrieve the value stored in an <o>int</o> or <o>float</o> object, you need to send a <m>bang</m> message (such as from a <o>button</o> object) into the left inlet.</p>

<p>One of the advantages of the <o>int</o> and <o>float</o> objects is that you can initialize the value without using any other message.  The argument provided with the object gives it an initial value; there is no need to set these up with <o>loadbang</o> messages or other functions.  If we look at the <o>int</o> and <o>float</o> objects to the right of our patch, we can see how they work. They do not send their value when the patch is loaded; sending a <m>bang</m> into them with the <o>button</o> objects outputs their initialized value.  Once we start entering numbers into them from the <o>number</o> boxes, those new values are stored inside the objects until we <m>bang</m> them again.</p>

<p>In our patch, just below the <o>int</o> and <o>float</o> object, we find a pair of objects called <o>value</o>. The <o>value</o> object is like a combination of an <o>int</o>/<o>float</o> object and a <o>send</o>/<o>receive</o> pair – each of the <o>value</o> objects has a <m>name</m> (in this case, <m>joe</m>), and any values placed in one of the objects is shared with all of the other <o>value</o> objects with that <m>name</m>.  One thing to notice is that sending a message into a <o>value</o> object does not trigger output – you need to explicitly force output by sending a <m>bang</m> message to the object.  In our test patch, change the value of one object then <m>bang</m> the other: you will see that the value is magically transferred from one to the other.</p>

<p>Unlike the <o>int</o> and <o>float</o> objects, the <m>value</m> object can take messages of <i>any</i> type; symbols, integers and floats can all be stored by the <o>value</o> object, as can a list. While this is convenient, it also means that you need to be careful about the objects that you connect to a <o>value</o> object to display the output. Our test patch has <o>number</o> boxes connected to the value objects; however, it might be better to connect a <o>message</o> object (by the right inlet) or other display object that can accept a diverse set of values.</p>

<h2>Summary</h2>

<p>Being able to send messages without having to connect patch cords can give us more flexibility in patch layout, and can also allow us to produce and route  messages throughout very complex patches.  The <o>send</o> and <o>receive</o> objects are the most common way of passing messages around a patch, but the use of <m>;</m> notation in <o>message</o> boxes and the use of the <o>forward</o> object for routing can help minimize the visual complexity of our work. Finally, we saw how values can be stored in the <o>int</o> and <o>float</o> objects, and how a <o>value</o> object can be used to both store and forward data that is sent into it.  All of these objects and techniques are important for working with complex patching systems.</p>

<seealsolist>
<seealso name="send">Send messages without patch cords</seealso>
<seealso name="receive">Receive messages without patch cords</seealso>
<seealso name="forward">Send remote message to a variety of objects</seealso>
<seealso name="int">Store an integer</seealso>
<seealso name="float">Store a float</seealso>
<seealso name="value">Share stored values among several objects</seealso>
</seealsolist>

</chapter>
