Getting Started

One of the things that's changed between Max and RNBO is the way that each environment uses symbols. Max uses symbols all over the place. Very often in Max you'll find yourself using a prepend object in order to format a message to a Max object, since this is the way that you tell the Max object to behave in one way or another in response to input. RNBO deals with symbols very differently, in fact strictly speaking there are no symbols in RNBO at all. However, you'll find that for almost every situation where you'd need a symbol in Max, there's a different way to solve the same problem without a symbol in RNBO.

Updating an Object

In Max you might have a patch where you update some property of an object by sending that object a formatted message consisting of a symbol and a number. You might set the size of a slider by doing something like this:

When you learn Max, you learn that the number box first sends a message consisting of a number to the message box. The message box then interprets that number and formats its own output, which will be the symbol "size" followed by the number. Finally, the slider receives the message and figures out what to do with it based on the first symbol in the message list. Contrast this with something analogous in RNBO:

Objects in RNBO don't really "pass messages" to each other in the same way that Max objects do. Instead, RNBO generates code where setting the slider value will call into other functions. Which functions are called depend on how the objects are connected. In other words, RNBO skips the "message interpretation" step that Max goes through, and instead goes straight to calling functions. The important takeaway is that what's going on in RNBO is very similar to what's going on in Max. Most of the time, when you find yourself reaching for a prepend object or a formatting message box, the RNBO set object will be what you're looking for.

Routing Messages

One other major use for symbols in Max is routing (often using the route object), deciding where a message should go depending on how the message is formatted. You might be familiar with a pattern like this:

There is no close analogy for this. In the context of RNBO, you'll often see situations where a list of symbols is represented as a list of indexes. For example the way to use a route object in RNBO looks like this:

You'll encounter a similar pattern when working with multibuffer~.

Rather than selecting a buffer by name, we use an index. The numbers 0, 1, 2 select the buffers in the list buf1, buf2, buf3. This is a very common pattern in RNBO, where you use an index to pick from a list of symbols, rather than the symbol itself.

Inports and Outports

The inport and outport objects form a bridge between the symbol-free world inside RNBO, and other environments (like Max) where it's convenient to use symbols. You can send messages directly to a RNBO inport object using the "message" prefix in the parent Max patcher.

And you can get messages back out of RNBO using the outport object. This lets you follow the Max pattern of having a "dump" outlet for big, complicated objects, instead of having dozens of outlets.

Something interesting about inport and outport objects is that they work anywhere in your RNBO patcher, even inside of subpatchers. So inport and outport provide direct access to the host, without having to walk back up multiple levels to get to the top-most RNBO patcher.

This covers the use of inport and outport in the context of RNBO and Max, but of course these object will also work with exported code. The inport object will create a code path for handling a MessageEvent with a given tag, and the outport object will generate a MessageEvent with a corresponding tag. For more, see the articles on working with messages in the C++ and JavaScript sections of the documentation.