Max/MSP, Max4Live, & RNBO (the thread)

As I understand it, making an external with RNBO will run your code more efficiently than if it was made with Max objects. It would also hide your code if you wanted to distribute it without people being able to see/modify.

Another benefit of RNBO is polyphony. It now seems like the easiest way to add polyphony to a Max patch FWIW.


My approach was to find existing patches you like (Sakonda’s sugarSynth here) and add new functionality to them - a good start would be making configurable / mappable LFOs.


Yeah, this makes sense as you can basically compile the entire graph into optimized code… no need for the RNBO engine to say “what node do I send this signal to next for processing?” Removing that type of dynamism can lead to significant performance improvements.


performance benefits would be good reasons enough for me.

i am mainly thinking about the scheduler here.

1 Like

As a person who struggles with conventional code but is very comfortable with Max/MSP I’m super excited about RNBO! Does anyone know yet how difficult it might to move something from Max onto Norns?


not completely trivial, but not too hard, I would imagine. The RNBO docs include something aimed at creating a SuperCollider UGen as @trickyflemming mentioned above. Now, granted, a SuperCollider UGen is (typically thought of as) a lot more low-level of a component than a finished Max patch complete with UI and all, which would be more along the lines of a whole norns script.

just to speak from personal experience, I wrote bitters et al in Max with some custom gen~ components and then later ported it to a Norns script of the same name. In the port, I chose to take the oscillator code and made it into a UGen, and then scaffold the rest (envelopes, filters, LFO and so forth) directly in SuperCollider and finally wrote the interface in Lua. In my case, the part most obviously suited for RNBO—the UGen—was actually fairly straightforward to port by hand from gen~ to C++, largely thanks to the way the cookiecutter-supercollider-plugin project streamlines the process. The hardest parts were the SuperCollider portion—since I didn’t and honestly still don’t know SuperCollider as well—and then reimagining the UI for the norns screen.


The new version of Plugdata just came out, and it’s pretty stable now. No compiling, just patch away in a VST, in any DAW. What Pluggo should have been 20 years ago.


I’ve been curious about this. How does it handle swirl devices? Like, would this work with patches designed around the Monome grid?

plugdata is great, but then again… i would not like to use pd for audio stuff… and not for GUI either.

it is so mean that you can not just choose the best of different systems and have it in a single application. :slight_smile:

1 Like

Yeah, plugdata looks beautiful compared to pd, but doesn’t have all the nice UI objects Max does. I think they want to keep patches compatible with vanilla pd, so that might hold back UI progress.

Do you know if you can add externals (other than else and cyclone, which I understand come with the program) to PlugData?

I think currently you can in the standalone, but not the plug-in version

1 Like

Got it - thank you (+20)!

Separate question - I see that Max 8 on Windows includes support for multitouch and HiDPI monitors. I can’t seem to find the setting within Max that would enable HiDPI - could someone please point me to it? I am assuming there is a toggle within the program itself (similar to Ableton) that would allow Max to display in HiDPI when I override the ordinary Windows behavior in Properties. Currently, my M4L devices appear somewhat blurry in Live, even though Live itself is sharp.


Seems like people are starting to play with RNBO and show demos and stuff. I havent gotten the chance yet to purchase and dive in, and had a question.

Can you load audio files into a RNBO patch? If so, how does it work when you publish to various formats? Are size limits overall? Per sound file? Can you wind up exporting some crazy multi-GB Web Assembly blob? If so, is the sound data more or less obscured? Any specific sound file format requirements?

Wondering what the quirks are before I dive in.

I’m curious if any folks maintain their Max patches in a GitHub repository? Whether it’s private or public facing, it recently occurred to me that this is a useful way to keep track of my patch versions as well as sharing them - especially if they get mentioned here on Lines. :slight_smile:

I’ve begun tentatively adding some patches to a repo here

I find that a readme.txt in Markdown is a pretty nice way of providing additional documentation too. That said, I’m still not quite happy with the structure and might see if I can implement a wiki or something instead.


seems to my a very good idea, … thx

1 Like

this page talks about audio-files(doesn’t seem to be any format restrictions, probably depends more on the target/context):

1 Like

I really like to use git to track Max projects, but there is a caveat. It is great to have the version history and have the confidence that I could get back to a previous known good state. Makes me feel like I have greater latitude to experiment with new things.

The caveat is that I don’t know that you could use the version control to easily determine what are the significant changes from one commit to another. The Max patcher files are themselves just JSON descriptors of the visual layout as far as I can see. But that means that even a repositioning of an object changes the coordinates. This is not a significant change, but one that git tracks. It is hard to separate these kinds of changes from the ones that are significant, like adding new objects.

So I don’t know how, for a Max patcher file, to see the equivalent of text-based code tracking like “these 3 lines changed, and these 6 were added.” I’d have to open both versions and visually hunt down changes, which can be hard if there are a lot of abstractions and sub-patchers.

But still very worthwhile to use git. Here’s an example of an entire Max Package that is tracked in git:

But if others have strategies for git diff’ing, I’d be curious to hear…


GitHub - diemoschwarz/diff-for-max: Attempts to get version control to work with Max patches ? (i haven’t tried it myself)


this is a problem in pd too as far as i know, graphical programming languages are not too good with diff.

Using detailed/descriptive commit messages is the only way i guess; but it’s difficult, i always end up with many parallel changes and versions called “working before changing this aspect”, “version for live 20221110”, etc.