Max/msp : community/consolidation/standards/deadness?

ok so this is sort of an amalgamation of discussions I’ve been wanting to start about max/msp/m4l in relation to lines. it’s a lot to take in, sorry, but I think it’s a big deal !


so especially in the wake of norns and its awesome community-ness I’ve been starting to notice how decentralized the max (and other platforms to an extent, pd seems to be doing decent though?) side of things has started to feel. there isn’t really a great consolidation of max/m4l devices for one, even though that is still one of the most common use-cases for grids. just recently someone newer like me dropped in kind of confused about this same kind of thing. to an extent I think it kind of pushes out the less hardware oriented monome users. as far as I can tell we’re still 1 thread per device, which I feel like doesn’t quite work well now that there’s so many platform options for grids. It also doesn’t look like the monome docs really cover the breadth of everything now, which it shouldn’t fully be expected to as a static document I suppose. honestly fixing this might be just as easy as making a “max thread” or a “max device thread” (maybe even a category?) to consolidate all of the different device threads. maybe there’s a better way to address this. I don’t think it’s a huuuge deal either way, just a bit of housekeeping that hasn’t happened yet imo


the bigger problem: new devices. they’re not happening ! they’re sort of dead rn. I want to make them a thing again ! a non-regular also brought this up recently. I’ve kind of brainstormed for a while why this might be happening, but of course want to hear other people’s takes on it. anyway, things where I see potential for improvement:

  1. organization, as I mentioned. I’ve been working on new stuff but none of it is in a finished state where a device thread would be quite deserving. something like a Norns: ideas or Norns: code review would be cool to have for max. sharing/answering questions and giving help in some dedicated thread might be a good way to get more people involved, i’d love to spearhead that.
  2. documentation/drawing APIs. this is of course one of the major improvements of norns, probably why it’s so so successful as a community platform right now. at the moment I’d kind of argue that making a grid app for max/m4l right now (especially one with pages, states, things that go beyond what something like grid studies covers) necessitates years of max experience. max is just super fiddly when it comes to this kind of drawing, but an API/library and good docs could fix that. I’ve started on a drawing API, I think @ithkaa started some work in a similar realm but they don’t seem to be active anymore. && to be clear, I’m not suggesting monome should make this by any means, it’s a big undertaking, and I’d love to work on it as a community if there’s enough interest ! like I said, I’ve already started on something, the working name right now is pattrns.
  3. and last, the big honcho, standards. most m4l apps don’t run at the same time as other apps, but some do, but not all in the same way ??? I’m actually not super caught up on this, cause I’m new (and because it’s hard to find this stuff due to aforementioned things falling out of organization), so fill me in if I’m wrong about this. it looks like at least @tehn, @elquinto, @ithkaa, and @stretta all have multi-object systems in max for live, but they don’t all fit one standard ? (again, correct me because I didn’t take time to confirm that). also most of those users look like they’re inactive now. part of what I’m imagining for the drawing API thing is just a standard approach for storing the drawing data so the grid can switch between apps, and also a standard for how to switch apps. I also like @stretta’s approach of just keeping track of active app using the live track. I’ve been experimenting and so far the dead-simplest approach I’ve found is to store that drawing data in pattr objects. but again, we can interrogate that.

EDIT: it looks like, yea there is a bit more standardization for this than I initially thought, I just haven’t been fitting my ideas into it - this might also diminish the need for an API (which could could run into compatibility issues inevitably)

and TO REITERATE I’m not at all blind to all the work that monome is putting into norns right now, I’m actually volunteering to take on the bulk of this work, hopefully this doesn’t come off as asking for stuff. mearly trying to get community feedback involved ! these are all things I’ve been quietly prototyping solutions for on my own, but I think I need to publicize the process to get to any solutions. also trying to use this topic to gauge who would be interested in getting involved with a re-born max community of sorts, and how that would look.

@dan_derks @alanza @glia @Rodrigo I’ve talked to all you lovely folks about this idea in various configurations and would very much value your feedback on this idea in its current state if you wouldn’t mind taking a look ty xx


I think a standard way to allow for switching between grid devices would be lovely!

When I went to start my little thread about the polysynth I’m working on, I was surprised to discover there really isn’t even an obvious candidate for “main Max thread”, so a category or a megathread would be really cool. (It’s kind of funny how much the platform on which a given idea is going to be manifest silos conversation around it—after all, with enough thought and typing, practically any grid device could be ported to any given platform.)

An interesting sub-current in your post and a Hard Problem for Lines in general I feel like, is dealing with varying levels in how much engagement with the construction of our various musical tools we have. It’s really awesome that there are so many things one can do with a Grid that don’t require any deep knowledge of computers, programming, nor electrical engineering. On the other hand, it’s also really hard to hold anything made and worth sharing to that same standard. Anyway, just a musing.


From a user (as opposed to dev perspective)

I haven’t done a ton with script development of Norns, but I have played around w a lot of patches because it is quite easy to get access to them. You just update and they are there in a scrollable list to try out!

I got a grid just a bit before getting Norns, and I feel like the max/m4l devices was more overhead to find what all I could do. I used the monome site’s docs as a starting point, but it wasn’t super clear as to what was currently up to date, what everything did, etc.

I think some work beefing up and updating that list in the documentation, as well as providing example videos of various devices would go a long way in getting people to make cool art with max + grid. If you are looking for dropping the grid requirement, creating a new webpage or github wiki or something where you start to create a home for showcasing cool max devices would be awesome.

Excited to see what takes shape here!


Max/MSP is a great platform, but there will be limits on how it can translate to DIY hardware solutions using raspberry pi or arduino (both of which did not exist in the early days of monome). I think that’s the main reason for the focus away from Max.

I think it’s good you’re raising this question and I love the idea of people creating their own grid and arc instruments using Max again. There’s such a rich history there. Regardless of whether or not you can get a ‘big revival’ going, the health of the supercollider/norns development and any puredata can spawn new ideas for those using Max.

1 Like

I totally, totally admire your initiative and passion for this topic.
But I’m sort of with @Jonny in that I’ve never seen Max/MSP as “community” software, though I know it has very many intensely enthusiastic supporters and contributors to the Cycling’74 message boards. The main reason being that it doesn’t run on GNU/Linux and exists solely on Macintosh/Windows desktops/laptops which represent a relatively high price point (from a software perspective and, in the case of Macintosh, from a hardware viewpoint). Workflow/processes are certainly translatable, but require actual human effort to move them from either Pure-Data (which I still use for prototyping interfaces) to Max and vice versa.

Either way I’m definitely stoked to see your ideas manifest themselves :smiley:



Thanks for bringing this up. I may or may not be unusual for a lines member, but I’m honestly more a musician than a programmer… much more, to be honest… I’m intrigued by coding but work over 50 hours a week and as I’m approaching 60, my bandwidth just isn’t able to support learning a bunch of technical underpinnings… I love to power up my Eurorack and exploring in a semi-rational semi-intuitive way, but coding? It’s not gonna happen…

i would be thrilled to see an active and coordinated effort to develop new monome friendly m4l devices, because it’s unlikely that I’ll ever develop any myself…


I’m curious to see what sort of insight and input someone like @darwingrosse could add to this discussion.


FWIW I’ve used this abstraction to switch between devices:


For performances, I set the devices to focus on ‘track’ and then change tracks with another controller. I’m not a 100% sure but I believe @tehn and @elquinto use the same thing in their devices. Don’t know about @stretta


It’s an interesting conversation, and I guess there are some possible structural answers/solutions to stuff (i.e. a Max thread, etc…).

norns does seem like a positive way forward for some of this, particularly since the hardware/software is tightly integrated, and static, so everything should work everywhere, in the same way. (will see what happens if/when new Raspi compute modules come out)

I personally have plans of M4Ling most of my fx and aspects of my bigger patches, but after playing with it a bit, I realized that that can’t be the way I personally use the devices. Unless something changes with how Live/M4L are integrated, as far as I can tell you incur a vector (or 2?) latency each time you go in/out of a M4L device. Meaning that if I have a few devices chained together, the latency isn’t acceptable, which is a shame.

Beyond that, there’s some really good work happening in @stretta’s gridlab devices, which I have been looking to as a kind of ‘default’ behavior, particularly in terms of how grids are buffered, arc animations work, etc… (no need to reinvent the wheel every time)

All of that is still very Max-specific, which the grids/monome/norns are bigger than. I’m personally a big Max guy, but that’s just because of what I’m comfortable with. I’ll see what a more norns-y future brings as I far prefer that form factor for my “computer”.


I assume it’s obvious that the Ableton/M4L install is a “sunk cost” already incurred, whereas Norns is an additional not-insignificant spend…

I’m interested in Norns for sure but I’m already deep in the Live way, with a Push 2 and lots of dedicated plugins, etc…

1 Like

A time investment in Supercollider just feels like a less risky investment than a time investment in Max for me. Of course I use both at times, but in terms of devoting a significant chunk of my life to a music coding environment, Supercollider feels like the more stable choice.

Cycling74 has a habit of breaking APIs a little more frequently than I feel comfortable with. They’re nice enough to wait for major releases to do this, but the major releases happen with some frequency. You can’t write a Max script today and expect it to run on the latest version of Max five years from now.


thx everyone for the responses so far, this is helping me get some perspective.

as I kind of mentioned, a big part of the motivation to start this thread was not wanting to develop my max-based applications in the dark and not really knowing where to do that here/who to do it with.

I kind of wanted to gauge interests for reviving a little bit of a max sub-community, but ya’ll are kind of reminding me that yea, now that it’s 2018 and there’s more stuff out there that does things as well as/better than max does (and tiny minimalist computers that work as well as an Apple Money Bag). yea, we’re kind of at a multiple platforms stage (maybe we’ve been there), and different people are going to be comfortable with different things, so a max-specific community may or may not be there right now (though a thread at least is probably worthwhile).

it does bring up sort of a bigger problem where yea, not all of our code is perfectly interchangeable & it may not all run simultaneously (i.e. m4l devices (I think @ithkaa is getting at YES - we do have a standard for multiple-instances)). being able to run audio between grid devices is one of my motivations for trying to community around m4l (another thing I’m curious about - before I look into it myself does anyone know if pages is still up and running on 2018 computers?).

@alanza brings up a really good point though, that I think is worth some thought. what’s the motivation for splitting development conversations between different platforms anyway? many of us still know multiple languages even when we work where we’re most comfortable. I actually searched through code and asked questions in the norns thread when I was developing my max device. honestly, a lot of the time when I go to others for dev advice it isn’t actually that platform specific.

what about just a “Development” megathread? and maybe a “Devices” megathread? I think it’s definitely worth considering. could address some alienation non-norns-focused developers could have & encourage platform intersectionality, which I think is often a good thing.

You can probably force it to work to some degree, but it never supported varibright apps, AFAIK.

Supercollider will run on darn near anything, including that $500-700 used mac.

I sometimes wonder if norns is a distraction from Supercollider, to be completely honest. The lua layers seem like nice sugar, but the open source variants of norns seem considerably more difficult to install, configure, and maintain, than vanilla Supercollider.

For budget minded folks looking to avoid planned obsolescence, I’d highly recommend a time investment in Supercollider (with or without norns).


I wonder if the tools exist for larger Max projects. For example, can you usefully diff Max patches? Can you visualize a Max patch without a Max license (ie in a version control system)?


AFAIK, the answer to both of those questions is “no”.

1 Like

It’s just an observation that it’s hard to run Max patches made for one major release at a later time on a different major release, and that often making the necessary edits to make things work again can involve considerable effort.

Perhaps it’s an unfair characterization, but to me, it feels a whole lot like the hardware variety of planned obsolescence in terms of the way I am personally impacted.

1 Like

thank you for bringing up this topic!

supercollider on a consumer raspberry pi is very cheap ($35 plus an old monitor and keyboard) and very well supported. you can do a lot. norns on raspberry pi is at this point not well documented, but that will likely change in the future as the platform matures. i’m not going to get into what the norns hardware offers over the DIY route.

i’d generally not suggest anything is a distraction from anything else. each path has a use case, and ethos, a community, and aesthetic. we all choose our tools based on our own parameters and needs.

but! it’s linux. if the hardware has to change, some bits in the kernel change, that’s it. likely if the hardware changes, it’ll just be cheaper and faster.

i don’t assume this, just like i don’t like to assume everyone has a mac. for one, i do not have ableton installed, nor do i own a non-NFR version newer than live 8 i think.

on to the actual point.

in essence it seems you’re asking: how do we support people making and sharing new max patches?

i think the Development thread is a good place to post new projects.

if we need an additional directory to existing scripts/patches/apps, a sticky’d wiki thread in the Development category would work.

i generally add projects to when they have received a fair amount of community support and attention.

i’m confused by the request for megathreads. megathreads are generally places of massive information loss due to things getting immediately buried.

i don’t necessarily think we’re siloing based on development environment, any more than is necessary. if there are broader conversations to be had about UI/ideas/etc we can certainly start individual threads. if you’re specifically requesting some sort of “grid: ideas” thread similar to the “norns: ideas” thread i see no reason not to do that. (you’ll note that most of the norns: ideas are not grid related!) but also consider that norns: ideas is about feedback for active developers (because there are many of us working on it) and also a chance for me to clarify the limits of what’s possible within the norns environment.

whereas a sortof thrown-out-there request for some grid application in whatever-environment is a likely substantial ask.

however, if there’s a thread about a specific patch/script/etc it makes much more sense to discuss feature expansion there. ie, adding something to the grainfields max patch.

re: m4l, i’d very much suggest some standardization with regard to how grids are managed. if someone wants to head up a m4l grid study which includes an abstraction for grid management, i’d welcome it.

if people have further suggestions about how to encourage discussion/collaboration/sharing here, i’m very receptive.


Really looking forward to this! I’d love to have multiple norns for distinct purposes, running in parallel. DIY would be a great way to achieve this within my budget.

Fair enough. Better norns-on-pi docs will certainly help me feel more comfortable with this assertion.

1 Like

That’s more what I meant. For patches that run up against the rails, I guess it’s possible that there will be patches that only run on faster hardware etc… or more/less options/channels etc…