Getting Started

Max and RNBO are intended to solve very different problems and have different strengths and limitations. Whether you are coming to RNBO with a background in Max or as a new user, a clear sense of the overlaps and differences is an important place to start. Understanding where Max and RNBO functionalities begin and end will help you make the best use of the learning materials that span the Cycling '74 software ecosystem.

Floating-point Numbers are Central to RNBO

Most Max users are accustomed to using two different types of numbers in Max - integers (or ints) and floating-points (or floats). In RNBO there are only floating-point type numbers. By default all RNBO values are 64-bit double precision floating point. RNBO does support the use of float32 for targetting platforms that lack 64-bit support. It is still possible to use objects in int-style modes, which can be useful for things like simple logical comparisons or switches and gates. However these are not different data types, they are simply floating points rounded to integers.

Symbol Messages are not supported

One of the most significant differences between Max and RNBO is that RNBO only allows numerical values in messages. Symbols are not supported. All interaction with object attribute states is done using numerical messages. For cases where you need to control attributes in RNBO that do not have a dedicated inlet, there is a special object called set.

Object Attributes can be Fixed or Dynamic

Objects and operators in RNBO have properties that determine the way they behave. Fixed attributes are set at compile time and cannot be modifed, like the name suggests. Dynamic attributes can be changed during code execution. For more information see Object Properties.

The Message Object

Unlike the Gen family of objects, RNBO patchers support the use of message objects. However, messages in RNBO do not support many of the functions that are present in Max.

No `;`, `$` or `,`

RNBO does not support symbols, so the special behaviors provided by the semicolon, $ and comma characters are not functional in RNBO patcher message objects.

gen~

RNBO fully supports gen~ and all gen objects and operators. Like in Max, you simply create a gen~ object in your RNBO patcher. Your gen~ object can be patched directly in your RNBO patcher, or you can load gendsp files from disk.

The gen~ environment in RNBO works identically in RNBO and Max and provides single-sample DSP processing. The only difference is that in RNBO, audio processing is always on, which means that objects like elapsed~ (in RNBO and in a gen~ object in RNBO) do not respond to dsp in Max being toggled.

Event gen (no tilde)

Event-based gen is currently not supported.

gen~ Parameters

Parameters in gen~ patchers are not exposed to the top level rnbo~ object by default, whereas parameters in RNBO patchers and subpatchers are. Setting the gen~ attribute @exposeparams 1 causes the parameters to be exposed, making them accessible in exported code and in Max as top-level parameters.

Unsupported Aspects of MSP

RNBO does not currently support all aspects of DSP that are implemented in Max. Below are some of the key elements that are not available in RNBO.

Timestretching - RNBO does not provide built-in support for any of the domain independent pitch or time stretching features found in Max.
MC~ - RNBO does not provide support for the mc.* suite of objects.

Other Unsupported Max Features

Jitter - RNBO technology is currently limited to DSP and MIDI code generation. For exporting glsl shader code, see jit.gl.pix and gen code export.
Mappings - RNBO UI objects are not parameter_mode accessible and are not exposed to the MIDI and Keyboard mappings feature.
Pattr - RNBO does not provide support for the pattr family of objects. It does, however, support snapshots using the rnbo~ object. See the rnbo snapshots guide for more details.
Event Probing - While Signal Probing is a feature of RNBO, Event Probing is currently unsupported.
UI objects in Top-Level Polyphony - UI objects will not work in a top-level polyphonic RNBO patchers. The workaround here is to use polyphonic subpatchers. See the polyphony in rnbo guide for more details.

Max and RNBO Object Parity

The RNBO environment includes many of the same objects used in Max. Significant effort has been made to achieve parity. There are, however, sometimes differences in object names and/or features. In some cases, objects also may resemble the functionality of objects in gen~ rather than Max-level objects.

Object Names

In most cases the decision was made to keep the object names consistent. In some cases the decision has been made to rename certain objects. This is mostly done in an effort to make objects more identifiable and discoverable. For example, the zl.* objects, which are a class of list processing objects in Max, have been changed to list.*.

Object Functionality

RNBO objects may not support all of the arguments and options that are available in their corresponding Max versions. In many cases the lack of symbol support can change the way you interact with the RNBO versions of objects. There are too many to cover in detail here, but differences in individual objects can be found in the corresponding help and and reference files. When in doubt, check!

Send and Receive

The RNBO environment supports send and receive (and send~ and receive~) for cordless patching, but the send/receive pairs are isolated to each instance of a rnbo~ object's patcher, subpatchers, and abstractions. The following constraints apply to using send and receive in RNBO:

Different top-level rnbo~ patchers with same named send(~) and receive(~) objects will not connect to each other.
Send and receive does not work between a rnbo~ object and its hosted gen~ patchers.
Send and receive are not shared across top-level gen~ patchers in a rnbo~ patcher.

For more information on the use of send(~) and receive(~), see the dedicated article here.