Transports and Synchronization
Understanding Storage: let, const, @state, @param
Using the Audio Plugin/Desktop Application Template
Programming a Custom UI with JUCE
RNBO Raspberry Pi OSCQuery Runner
RNBO and Max for Live
How RNBO and Max for Live work together. When it makes sense to port a patch to RNBO. Best practices with RNBO.
Sharing a Max for Live Device that uses RNBO
For the time being, the version of Max that comes bundled with Live does not include RNBO. If you want to build a Max for Live device that uses RNBO, you should export your RNBO patch to a Max external before sharing your Live device. In the near future, the version of Max included with Live will have the RNBO package, and it will be possible to share a Max for Live device containing a rnbo~ object with anyone. However, it's still best to export to a Max external before sharing, so that the object does not need to compile before the device can process audio.
Porting a Max for Live Device to RNBO
Suppose you have an existing Max for Live device, written before RNBO was released. Should you port it to RNBO? In many cases, the benefits will be small enough that porting to RNBO is unnecessary. However, there are situations where porting to RNBO will make a huge difference.
In plain Max, the Max environment itself has to manage the interaction between objects. One object sends a message to another, and Max is responsible for moving that message around and making sure it gets to the right part of the right object. That introduces overhead, consuming time and memory resources. With RNBO, the entire RNBO patch is compiled into a single block of code. A RNBO patch will almost always be more efficient, in terms of CPU usage, than an equivalent Max patch.
However, if you're using a Max for Live device with a rnbo~ object inside it, be aware that the internal RNBO patcher must be generated and compiled before the rnbo~ object can process audio. A Max for Live device containing a rnbo~ object will probably load slower than an equivalent Max patcher. For the best possible performance, export your rnbo~ object to a Max external, and use that in your Max for Live device.
If you're building a Max for Live MIDI instrument with multiple polyphonic voices, you're especially encouraged to port your audio processing to a RNBO patch, and then to export to a Max external. A single Max external will always load much faster than a large poly~ object, and after porting you should see significant improvements in the time it takes for your Max for Live device to load.
Finally, if controlling access to your intellectual property is important to you, you should consider exporting to a Max external. Unlike a Max subpatcher, there's no way to double-click on a Max external to open and reveal its contents. Even if your end user unfreezes your device and looks at the patch, they won't be able to look inside your exported Max external. You can keep your secret sauce a secret.
If you're building a RNBO device for use in Max for Live, you might wonder how best to set up your project. We recommend using a Max Project to organize your work, as well as creating two different main patches. One patch will be your Max for Live device, which will ultimately be hosted inside of Live, and the other will hold your rnbo~ object.
The basic workflow looks something like this: design your audio effect in your rnbo~ patch. Then, export a Max external that you can use in your Max for Live patch. With this workflow, you can easily make changes to any part of your patch, and when you're ready to distribute a finished Max for Live device, you won't have to reorganize your overall structure. See the attached project for an example of how best to organize a Max for Live Device with RNBO.
Materials in this article