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

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.


Yeah, this is the issue isn’t it? As @ermina pointed out, using detailed/descriptive commit messages is really the best practical option, but still doesn’t get around the diff issue.

I’ll check out your Package for sure. It will be great to see how others are tracking their work. :slight_smile:

@pflouret - will look into diff-for-max over the coming weekend. :+1:

1 Like

Accessing RPi GPIO pins in a RNBO patcher.

TLDR: use a python script to read the pins and send the values to the RNBO patcher via OSC.


I know its not mind blowing or anything but its nice to see that OSC is a kind of “first class” solution with RNBO. Wondering where it might come into play with other export targets…

Havent had the time to buy it and put it through its paces, so if any RNBO adventurers want to share any findings Id be happy to hear about OSC adventures

With RNBO, is it possible to use third party Max objects in a patch and export that, to say a RPi?
From what I understand, the answer is no, but I figure it’s worth confirming in case others might be wondering the same thing.

Specifically, what I wondered about was whether it would be possible to take an old monome max patch, e.g. something like flin, and export it to run on a PiSound that I have lying around. I have a norns, so that is already a much richer environment, but the thought of being able to pair up an under utilised PiSound and an old grid by just exporting some old Max patches is very appealing.

edit: I dug a bit deeper - I guess it may be possible to port old monome max patches, since the serialosc.maxpat is just handling the routing of monome osc messages coming from the serialosc service that would have to be installed at the RPi operating system level, just like norns, but it looks like it wouldn’t be as straight forward as just cutting and pasting into a RNBO patcher. Norns is prob a better place to spend my time for grid - no point re-inventing the wheel.

This was one of the questions that came up during the Q&A of DZ’s keynote at the Audio Developer Conference last week, and the answer was approximately “not yet”. It sounded like you won’t necessarily be able to drop in existing externals directly, but perhaps they’ll come up with a RNBO reflection of the external SDK?


I’m thinking of picking up a PI to use with RNBO, any hardware recommendations? Preferably something prebuilt, as I am not handy with DIY…

It depends wether you need buttons and encoders, screen etc. Any headless Pi with an audio output, controlled via OSC should work too. You could run Patchbox OS if you want to set up the whole Wifi and audio stuff easily.


I was looking for a Works In Progress thread but couldn’t fine one.

As this is made in Max and I’ve been working on it for a while I thought I’d share it here.

It uses prime numbers and euclidean rhythms (thanks to Gregory Taylor’s book Step by Step) to generate the material.

Just an extract from a longer recording - I’ve got tons of these going back to the bare bones!

The goal is to eventually score it for actual players (even bought Dorico on BF with that intention).