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

Meta
1

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 !

PART 1.

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

PART 2.

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

21 Likes
2

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.

2 Likes
3

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!

3 Likes
4

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
5

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:

5 Likes
6

Andrew,

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…

3 Likes
7

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

2 Likes
8

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


----------begin_max5_patcher----------
2875.3oc6bksaiiiE8YmuBB+TO.ItDI0lGfBX54KXdXdqPACYaZa1krjgDsS
xzn+2GtHISZsX5E5jpQEfD6PRId44txkK+ymFMdd9ajxwf+I3afQi9ymFMRV
jnfQU++nwaSdaQZRorYi2RJKSVSF+rpNF4Mlr7UEjxM0ktJOiUR+eDQMPuId
UEmseKMKkvjuIjVayR1Ja63eufljB924oKGe7Yx2ypeHXUophXuuinn8wiAe
upJ5R4aJe9e7Bzu9srKgsXCMa8rBxBl5QBvSmDx+INxCBifwQAOC78fS7h7Q
p+Ci4TN.woev2Eul+5omD+4YKQpLxqbhnEPUvocB3Kayyx2R9x5B5xu7Cx6N
G4P8hbO2G5gG.8vXAwA7wgZ.FDgtIDqOYKCvJkr7KIoo.u5lkRyHKx2mwzGl
63hijLVBilmMqyV7YQFEN.J66gmf4+.QSiiQwPjPpLLXRPCjGKYCX38UFsjv
wW.7RDJwWCTg6CplmjsVHXV+YmP2zKE4f9RYVnKTqKAu7xKBAzBxEaJDdMXm
m1CsJYAQuLMPJdHPhCHmBR9d95hWHmgUk4kKdgOddX.kFnDZgksHcKaQdNwU
PCNPytDXvy8lkBFBgBj5QvnHwGgNAZVRVQJRye04RGWFr3OTDE9g9xHJBB8m
xUs7BkFcvAZxQAtQehat9wD+E5bFr6F0FxGW.B1NNLivJtqf1gjhlQ6RxA5B
BcYK.kSlrBPc0f+EaSw9iAb3LYQ7fwn0G5hwWH5hizixEBCOBuUuHtrDKunt
225w+IvK7XuWlbfrbFuy48yLAVQmyCpsrhITwEDzSAenyHEyHYIyS0cQoW41
jc6ZpVVqjCeWMxRXubJ214VZWjmlWnvPuIgA9S8POy+lOmQDFH91TD2NAuLn
FzamcHbzf77JNpzLcbf6bgekn5M4F+pPU8.tCuTiQFQBDG4B3bGHkdfLaU9h
8kebShVZDuKLCguTK3lt8Bm1xDi78PJN0jwJZJ4.onjOsMMRczXtIBshGo8H
B.9OTRDwO2TDMSUjWSQEbA0Ses72aAezv3Ck8JycieKr1Eu30jujTjsmJeFU
gbVcEIIYpBPubWU32Rdec0Gwm3H4LNvdRMQ+3XUXSZnAWpYcZ9hePVZXhLeG
IiloOUVip4wHkrOkMyPPAMoy5OYFBlUZJ4zLBDylgOwaNQXvJDEW2ceC.kCJ
weONXjsHKYWGOrxmQOUVxGj6KmmTH3TUNDP0UxxySMqp44RIqXUUuilkcBJx
x20ekEz0aF3Ymmyqb6PuaYMky1mopcFWnfMS3ezrcIooUp9lu92RxnaSXDFU
wBPdMUp7YtobQQdZpw3UUygNpQYM9U5R1FYGoKLvaNcWsPz3Ft7R5Zt2dyxX
IqKMKoj8tBz0JZ+7Jk3YLx1co7QgYCLVaQcMVcijFkOjwxN7pyUYTZEZsnK2
28aC7Ltb6adi8YILRthg74QK9Po0KVRLkmhiA1Lp1iwcFTVxmG.zSupdLMzm
ejd7kL95fQC2I8stD8AkPrLpe+oSUqy3iFKE9imv1PKUpT8Bpd8CpvqDTwmE
T4SEflwp+nOHN5LPLxa5DwzqjgIFcxhc6dDVFB42DP72YEIK9w0H2dsPrW2H
Vv4ProRrBq9H9gKTJlnO7QpeirQTrWAPeK0wUgGhCcBbpHacJIIKK+X3TiGa
ivkUhOX6FuAJ+CG+qA9sHe6VRV0lpIlO.fkudcpgEHZ1RxaZAkdW.J4.WuW1
PyXsPHaAuqz06P1yPmCdmh0zNs.dEBvbzEvCudIPetWlfLxkfriwydASncxp
1Cl7urGvmsxdlykTGxB4qT9PAf.nqwiMdPyj5So99wG7sMRHe4BsGD+n8Sy.
yAz6e7OmAMQ1FDTe.K1e547lGHkpwwJm5HQvPORf8qe8ZPUjyjQGDMC7NGZ5
qDSq1j0fGMZxmANOHRPBWZcwGf7p+fZ+Oe72gQ4y4iCEoDV8kgLEE8QXLH8y
owfAPUrcnJJThmAQNQ107zsXBqqILNYs4yk8fA.TeKATUDY9ObwT4r2Uq03O
MXZfkp9PYD.AsVRca1YNS3bz3Y6DKpdIijsPa62L3O+xfRG7pH63UPUzZQAO
bCJ6Jx4rV16741jxoJtLwvqwxmLkgPOKMv3Ushq3OHKLkjhCjhGNrhNazF8C
s1Z6VMeiHzeOryH4WC5iE8fWI2VGpi1rJKcI.UaBWfaV.sAiaImkCDnpZ+qK
ILvAJ40eZLyDZG.OEorx38nsx72hI0DcNi4vH0B.i8+0jZrNFjHncnJRc74B
g+ZRMCaLHBYIfFE+qI0XKlhsT0WEG2OUSpYvvuEtDEas4L01GCVjjkmQWjjN
aWRgXIy0dptROkO+b1yt4dp49.UAPVs0LvGr1xOYA7EEXGnhfSsHfuiGHKgD
VOmDGYmHpuaztLeewh5AP09FAL0NWRJYzrlsv5aZ6qAvVt8ESE0u8yRG9NjJ
PWDV.cDUH2nCwa+rzgbQ7cLc3YMc3JtRya2R9BxYzgP9.aCdTibNhNvVyW7c
NcXmbZfKkSqGkVRGtCOBrlNPNkNhrkNB8bNcXk7gXMrbm7Qnm03gS0WBsWNE
6T5vd4zHmRGgVyWbpdqX8LrytdGdhxKVpx5A3GLwEzOo44HRy1XGkSE2g7On
s1YhvtzNSDxZ7vo52QVGePjSs+GYs8tH2peGXs7AzgzgsngKmmk0VbibomP6
iOI7QaTK5RAnGmq.amgb+1VpJrNk2rMseunTMZcZ97jzpDIpYYV5HSjt6IFb
xBF8.4i6BFPeOSLN07ClO2QcjqkdwSPQggPHt4R73lRRU4RmINOu0DxIGR4R
9PCntSdTGaZfHQIm.9uhiX.3qUk85FRFPdpC.zxlygvDv+Ic+5WnYlsaQJUz
trR5RBXGuE7uCdklsLG7a79FvnbzCLOo3ezUh7mrmkaj6rFW+OZ2PCUqfu5l
cRcyUnm5hWjTPWY29Mk1+mlnmvycc.rJMOoaYHLpQHRIlOesQdSCiB8ifO2y
2NIKcOe19hDGg1i2n.dsAVkoiFaFCX83PR5dR9p1o46Q7NMOacu7diVRynLN
32lC0Uqp1xW8MePqQkaxKX10qbMms0FXWsRvoDRzh63EvX0wvoydnlCidR2P
7UYxq9f42xlmsJJH0Y.oJgUTqje7UpnH5cCoOum09C7j25Eeg.zmZiwYAO5B
yecTntDsxrgB.teNfVKxX1OW2FYVbkuYpqicxko0mPjAMDx3iztvMtQHoNop
a7yQIuJS5cZJk8tAguZE2SroRUCoqtNAVVviepIMwatBMDNaYaJx2udid4sx
3byJNzth4qEd9MJ4X.2CahAqx2O3zXsCxmdFF0MKtg8VRD727xES3vGGyZ72
UrtZqtpu2.Gq+Fae5VtL+tU4ca+2ZhVHmf8aMj0DTjuUysrSI2b5D.pjd5XB
r5Q922debbkMZIfZaGgrre7tw9ABsuipZyV5xc4bdUY8McGZRbqa5NrtgLtG
O3oWdWVzDj5x1AGnNeMh+6VGs5q9POCVicZ6j43dScL5Lcru+8feZA6DeGjO
sAIw1H1z7iH9XjHck4eyaJVcS2HyhdiRayYPNeffttAhH+2PRw5lehCGtNn5
NYnRjW9esGvvaZ.isQgGeODEsomBuGcjuEcj+fFwB7mJYFFWNUno52Td7XOF
pE2p8drUZt2C9hbBrmsqZHnaquvW.q4l5IeaTjggCJDD52lEabk.2oPfVKtG
iAOKGC2VOYuHvs5ov2+BDr6wDaTGQGfCQmgyn2habPDXCbcG.qo1H.bOTWlZ
g1Rbq9QE+7IWXbht3jKJtStj3ZeAw0+kC2oWLbxUHuuKDtm9qm9+.3G+VwB
-----------end_max5_patcher-----------

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 …

2 Likes
9

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”.

3 Likes
10

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
11

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.

5 Likes
12

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.

13

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

15

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).

8 Likes
16

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)?

2 Likes
17

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

1 Like
19

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
20

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 monome.org/docs 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.

13 Likes
22

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
23

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…