From the intrepid grid-playing monome producers comes a whole bundle of goodness: a free album, and along with it, a nice video that illustrates what’s happening on some of the tracks, some reflections on how 15-second samples can bind together a community of music makers, and even, as a bonus, some tips on running Windows software in Linux under WINE. (Whew!)

Via Joshua Saddler, who illustrates his music creation techniques in the video at top, we learn of the monome Community Remix Project album, available as a free download via Bandcamp. (Full track lineup embedded below.)

MCRPv10: MCRP​-​RP, by monome community [Bandcamp]

Josh explains how the “meta-remix” came about — by limiting to 15-second samples, and pooling results, an entire community of producers was able to work collaboratively:

I admit that this is slightly in my own interest, since I’m on this album (as “ioflow”). But even though this is the first album I’ve ever appeared on, being new to the world of electronic music production, what’s really newsworthy is that it’s another outstanding effort by all the monome artists. these guys are super-talented.

This MCRP theme: the meta-remix project. Each participant grabbed a 15-second sample from a previous MCRP track, and submitted the unaltered clip to the pool. the participants then used the pool to craft their own original tracks.

Man, what they did is crazy. I had access to the samples and I still can’t tell how they got those sounds. they’re a fine buncha talented
folks, so maybe this is a news item of interest: monomers around the world coming together to create a free album, created at least in part
with free software (i even used Windows software on Linux), using tracks previously made freely-available on other MCRP albums.

Thanks, and happy listening!

Here’s Josh’s track, too, via SoundCloud:

lines and angles by ioflow

Linux + WINE Tips

Josh also, after my prompting, shares some tips on how he works with Linux and, for Windows compatibility inside Linux, WINE:

I ran Max/MSP under Wine. I ran the “Ricochet” performance patch for the monome, which was tied to Linux-native Renoise via JACK (WineASIO transports audio/midi from Wine to the system JACK daemon). Renoise hosted the samples as sliced instruments, with some more open-source software DSSI plugins loaded (Calf Vintage Delay, etc.)

Ricochet is based on the Otomata website that’s been covered on CDM previously. You can actually see how it translates to the monome on my video for “lines and angles.” Press a button to place an initial “token,” with each subsequent press indicating direction: [seen at top]

More details here:

(and more monome/controllerism/software/music-related stuff on the “music” tag!)

The Max/MSP stuff, especially MIDI-outputting patches, generally works on Linux exactly the way it does on Mac or Windows. Occasionally I have to do some hacking to get audio/sample-based patches to cooperate, but only rarely do I find something that doesn’t work at all. mlrv1 and mlrv2 are the only ones so far. Most of the challenges stem from the fact that Wine’s handling of Bonjour is broken. The zeroconf layer that’s used by serialosc poses the most problems. For zeroconf-based apps, I got the man himself, tehn, to create a “static” serialosc.maxpat, for which I use a plain text editor to manually specify ports, then copy that .maxpat into each serialosc-based Max patch I intend to use. serialosc itself is developed on Linux, but it uses Avahi there, whereas other platforms use Apple Bonjour. Can’t have two DNS stacks on one machine, so I’m forever hacking on and around Wine to get it to cooperate with the system DNS responder. So far, there’s no way to bridge the app’s zeroconf transport and use it unmodified on Linux.

Workarounds like customized .maxpats are a small price to pay, though, for the pleasure of being able to run monome performance patches. I’m not a coder, so I have to work with what’s available right now. Maybe in the future I’ll try porting some of these things to Python.

I recently got Aalto running under Wine — I posted that to the CDM article a week or so ago. Rules of the MCRP being what they were, though, no external sounds allowed, so I couldn’t hook that in, much as I wanted to. I had a lot of fun learning how to make music with samples for the first time, anyway.

Good to know, I think! For more on WINE, see:

But personally, I’m delighted just to have some nice music to listen to – and the price is right. Thanks, monome community!

  • excellent album guys! Thanks for the freebie!

  • hey, thanks for the news item and links!

    for anyone who's interested in using a monome with linux, i wrote a wiki page on how to do it. i try to keep it up-to-date; been working on adding instructions for gentoo linux, in addition to the ever-popular ubuntu distribution.

  • Peter Kirn

    I'm curious, though, even having brought these points up in the article — why not use Pd in Linux? Why go to the trouble of using Linux, only to use Max/MSP? I love Max/MSP … but then, that'd say to me, stay with Mac/Windows. And I'm curious what happened to the efforts to build monome tools in Pd.

  • a couple reasons:

    1. choice. there simply aren't as many puredata applications that offer appealing forms of musical expression.

    2. updates. most, if not all, of the puredata apps haven't been updated for the new serialosc protocol, with the accompanying in-development external. the pd patches also see fewer bug fixes and feature additions. maintainers come and go.

    3. equivalent apps. with one exception that i can think of right offhand, the pd apps have a somewhat more full-featured equivalent available for max/msp. mlr is a good example.

    i really don't know why the community ideals of openness, inclusiveness, and collaboration haven't extended to software. i wish every app was written in a cross-platform open language. if i had any programming ability, i'd be creating the things i'd like to use.

  • Peter, I think Chris Randall's final points about Pd on OSX are just as valid regarding Pd on Linux.

    I love Pd, but if given the option to use Max, I'll take it, no matter what platform.  There's a running line in Left Coast hacker circles where we try to convince newcomers to tackle an important project: stabilizing and creating a modern user interface for Pd.

    The responses run the gamut from disinterest all the way to actual code spelunking, but, invariably, everyone eventually tells us to just use Max.

  • Peter Kirn

    Okay, I understand these concerns. I would note that the predominant reason among what Josh describes is that the monome community hasn't embraced Pd. And that means, if you don't put energy into any one platform (whether it's open source or not), you won't get something back. 

    I respectfully disagree with Chris' larger opinion on Pd; my take is that it doesn't suit his applications, but, for instance, he's experiencing kinds of instability I can't reproduce because I'm not doing the kind of patching he is.

    There are a wide variety of tools that can do the job beyond Pd and Max. That doesn't mean you shouldn't just choose Max, or just choose Pd, or just choose SuperCollider or coding in C++ or whatever it is. But, putting this as delicately as possible, almost anyone who tells you *any* one tool is correct for every job (including, say, Pd) is probably not well-informed. 😉 Not to say I haven't probably said that myself … but, well, sometimes I'm not well-informed!

  • Peter Kirn

    Anyway, that didn't answer my question — we're off-topic now.

    The question was, why use Max *under Linux*? I can think of a few reasons, but I'm curious … and as I said, I'd be inclined to use Max under Windows/Mac for the reasons above, but switch to Pd under Linux, even with these WINE tips. I still find the WINE + Linux + Max combo interesting, though, so I'm curious what the thought was.

  • I understand what you're saying, Peter.  What I'm trying to convey is, even under Linux, Max seems to be the preferred tool of many for tasks which could also be done by Pd. Why is this?  It's probably a host of reasons: user interface, stability, existing library of applications, etc.  These are not trivial when someone just wants to make music.  Running Linux because you support FOSS and/or can't or don't want to give dollars to MS or Apple doesn't mean you have the time or inclination to create new tools when good or better ones for your purpose already exist.

  • Peter Kirn

    Right, but actually, I don't think either Max — or, for the precise reasons about which people are complaining, even Pd with its normal GUI — is the optimal choice on Linux. In fact, I would think the ideal for people comfortable doing their patching in Max would be something like this:

    1. An easy path to porting their finished Max patch to Pd (having taken advantage of the very polished Max GUI for development)

    2. The ability to use libpd to create an embedded, standalone application which could then run on Linux, iOS, Android, etc. 

    We're not quite there yet, but it's a worthy goal.

  • Now you are talking.  I endorse this vision of an interoperable future.

    Maybe I can offer this as an alternative project starter when people balk at reworking Pd. 😉

  • @peter:

    vlad sums it up exactly a couple of comments ago. i agree: using max on linux is not optimal in the slightest. ideally, over time, patches would be ported by the community to puredata to make them truly cross-platform. but to a non-coder (me), running max applications in wine delivers results immediately.

    vlad hit every point i'd make. using max on linux is a case of pragmatism edging out idealism. i'm still working my way through the "create your own mlr in pd" tutorial on, so i can't speak as to what pd can or can't do, as a language, compared to max. i just look at the available music-making applications feature-by-feature, bug-by-bug, and how easy/pretty their interfaces are on my weak eyes. max wins in most categories.

    there've been a few efforts to port pd's tk interface to gtk and qt, which are much friendlier and cross-platform to boot. a better gui for pd would boost its appeal outside of linux, compared to max. but those projects seem to have died.

    so if you have a language that's more-or-less on par another one, feature-wise and style-wise, and it also offers much cleaner, readable guis . . . which one would you write your application in? i think that's why folks have just been using max rather than pd. pragmatism over idealism, or of necessity in the cases where the application must fit into the host's scripting/integration environment, such as max4live.

    you mentioned a migration path for max-to-pd patches. there's a converter available, written in supercollider, that saves max5 patches as max4 patches, which can then be opened in puredata:

    i haven't really tried it, since i don't know enough about sc to use it.

  • Is it just me,  or does anyone else find this concept conceptually interesting but its output incredibly mediocre and bland? not to be blunt: but it kinda sounds like shit. pretty video though.  

  • People have different tastes.  I like every track in the compilation.

  • the point behind the remix projects is to get people involved and making music within a tight deadline, not to produce some epic opus. This is about free interpretation and engagement, not judgement and competition.