Love for the Penguins (monome series under Linux)

  • I mentioned this back in the big 256 thread we had, but I figured I should probably post a little update, especially as people start receiving their 128s. For the past month or so, I've been setting aside a good bit of time to re-learn C and get to work on a Linux monomeserial that works with the new series of monome. It's rather complete at this point, actually, and I want to spend some time this weekend cleaning up the source and testing it a bit more thoroughly, but I'd like to at least get a beta (or alpha or whatever) out the door sometime in the next few days.

    Though Max/MSP doesn't run on Linux, I can get nearly all of the ChucK apps running (chuckstep is a bit unstable on my system) and they run well. I've also been investigating other languages that aren't getting much love, namely cSound (with which I have some experience) and SuperCollider.

    Will keep you all updated.

  • i'm looking forward to beta/alpha testing this. thanks much.

  • is it a port of monome serial, or just based on it? gui based? id love to see it, gotta get a linux setup when i build a new pc.

  • it's a rewrite done in C. currently it's just console based and there are two parts: libmonome (handles the communication to and from the monome and provides a C wrapper around it) and monomeserial (OSC interface to the C API). I want to make libmonome a shared library at some point (might not be in the initial release), and a GUI version is on the horizon as well. if a name change for monomeserial would be a good idea to avoid confusion, just let me know.

    currently it only supports the 256/128/64, though I presume 40h support would be easy enough to add, I don't actually have one to test with.

  • > Though Max/MSP doesn't run on Linux,


  • >> Though Max/MSP doesn't run on Linux,

    > YET...

    You have Pd.

    I installed ubuntu on my machine some weeks ago and I'm looking forward to a linux monomeserial! There's a python version somewhere also, which should run on linux... haven't had time to try it out.

  • yeah, i wasnt thinking, you did say C, sorry.

    if you need any help with the 40h protocol, feel free to write me, its my username here at yahoo dot com.

    writing for the 40h is considerably simpler IMO - all packets are 2 bytes wide, and there is no frame packet, you just shoot off 8 led_row commands (still worth it IMO, OSC packets are pretty bloated binary-wise compared to midi, so it does minimze network traffic slightly since the address pattern is only sent once, and whatever reasources used to send the datagram are only initiated once per frame rather than 8 times).

  • wow. i'm very impressed. have any of you guys tried the python implementation? serial-pyio? it works quite well, though i imagine a native C version will be even more optimized.

  • @jah, i haven't used pd much, but it's definitely worth noting.

    but, i was referring to an article on the Cycling '74 website (

    >> And, ultimately, we want to port Max to Linux. (No, we haven't done this yet, but we can now conceive of doing it.)

  • >> And, ultimately, we want to port Max to Linux. (No, we haven't done this yet, but we can now conceive of doing it.)

    that made me pretty excited when i read that article. i get the feeling that max/msp will be better off in every way possible once max5 comes around and is in wide use: plus, having it ported will linux might be the eventual nail on the coffin for PC for me and other Windows users (i exaggarate, i cannot see NI moving Reaktor to Linux, they seem WAY too, well, capitalist to embrace Linux).

  • > have any of you guys tried the python implementation? serial-pyio?

    serial-pyio doesn't work at all with the 256, which was kind of the motivation to write my own. is there an updated version about?

  • no, and you're correct. though it could be adapted somewhat easily (or at least i'd hope so-- i also wish i was really good at python.)

  • adding code for a new serial protocol isnt really tricky. the tricky part for the 256 IMO is if you impliment cable rotation and especially offsets. doing offsets on the 40h alone is tricky (/led is easy, its row and col and frame that are nerve-wracking, especially on the 256).

    iotao, have you implimented midi yet? i would definately recommend you check out portmidi if you haven't yet. since it is a C api, it will probably fit in your application rather easy. easier to work with than liblo, too.

  • yeah, the cable rotation is going to be the next thing that I work on (it's not in the initial beta, regrettably). it's been fun thinking of how to solve it, actually, and I'm excited get that done with.

    midi has not been implemented yet, no. i'm going to put some serious thought into it, though, because I want to make it a pretty useful function (I'm looking at mapd for inspiration). I've thought about the potential of using portmidi/portaudio, but initially I think I'll just use the alsa sequencer API. it's the standard nowadays, at least until JACK midi starts to take off. and, for the record, I don't mind the liblo API one bit. ;)
    thanks for the tip regardless. cross-platform development isn't something I particularly want to get into right off the bat, but I have no problem wih moving the portmusic stuff a few notches higher on my "to learn" list.

  • > I don't mind the liblo API one bit. ;)

    i guess i'm way too stuck in the OO world of programming to really enjoy working in C personally.

    cross-platform of course is nice, but i really just mentioned it in case you havent yet looked into it (it took me quite awhile to actually go thru the trouble of installing Subversion to get portmidi from the site). its a fairly easy library to program against without worrying about lowlevel stuff, but i guess sometimes the low level bits are fun. i have no idea what the specs are for the alsa midi, but i do know that id rather stab myself in the eye at this point with a butter knife than use the Windows MIDI (Multimedia) API, which is why i started looking into other libraries. id imagine though that the linux APIs out there are a bit more, um, modern (i think even goddamn Vista uses the same 1980s midi code, which i know under the hood the other libraries use as well).

  • Nice to hear that there's more interest in using monome devices with Linux!

    Although I'm rather short on time (that's also why serial-pyio's development is stalling at the moment), I could help with beta-testing a bit.

    You've mentioned "mapd" as inspiration, but I'm not sure how you meant it. (I'm asking because if you're planning to also implement something similar to mapd, please tell me)

  • @rooker:
    Though it's certainly not something that's going to immediately get done, something similar to mapd is certainly on the horizon for me.

    Additionally, I finally managed to get a release of this out the door. I've got a homepage up at , and the very first alpha or whatever release has been uploaded there as well. At this point, it's really just the bare-bones functionality that's implemented here (no cable rotation, GUI, MIDI).

    This is my first time posting something up for anyone other than friends to download and try out in quite some time, so please let me know if I'm botching anything. Also, this is the first C I've written in maybe 3 or 4 years, so any feedback on the code itself would also be welcome.

    Thanks again, everyone. Hope this works for you so far.

  • looks great, can't wait to check this out. impressive work.

  • @iotao:
    Hm... maybe if I find out how to use C-stuff in Python (that's possible somehow. I know), I could actually use your library for interfacing with xxh devices instead of having the same code again in Python (as it is now).

  • iotao : were you thinking of making a second mapd-like app, where it replaces monome serial (like on OSX)? personally, im into the idea of a second app that takes OSC from Monome Serial, and transforms it to OSC and MIDI via Widgets. or, an extension to Monome Serial, although i like the first method better, as it takes advantage of the serial code in Monome SErial, and is less confusing for end-users.

    ive been working on something like mapd using maxmsp and javascript, although i slowed down a bit. i think a native, compiled version, or an interpreted version other than javascript would be alot more efficient, though. regardless, i have alot of ideas already on ways to impliment such a thinng.

    when you start on your Linux version (whenever that may be) please do say so. i think it would be possible to work out a core code engine that would work on all 3 platforms if we are careful (and then add p[latform specific GUIs, or maybe just make it command line). im more of a C++ dev than C, but id be willing to work in C also (i personaly feel it owuld be easier to manage in an OO language, but as i said i aam biased due to my own programming skills/experience).

    i think if there were a community, open-source, crossplatform mapd it would be far more likely to be realized, since the work would be split up and on person's lack of involvement at any time wouldn't stall the entire project (i say that about myself really, as i bounce around between the worlds of C++ development, Server business development, and Reaktor/MaxMSP music patch development, depending on my current mood and other factors).

  • I like the linux idea; I myself have been interested in switching back to the dark side =)

    I have a certification in C++ from school, though haven't coded in a bit, but could give a stab at some work, I lso did a project with a friend that is the head programmer at SDT. Do a google for "Matthew Clower" you will see what I mean, he proof-reads C++ tutorial mauals for a hobby =P Anyways, he tought me how to take a bit of knowledge (equasion, function, idea) and structure it how it is described... kinda freaky at first, but it mkes more sense than I thought.

    Anyways, I am definately in for it; I need to procure an updated copy of Linux and wipe my Home PC for a clean dual-boot system on it's own drives.

  • @KidSputnik:
    I also find the idea better to have a mapd-like app and monomeserial separated. I'm not sure, but does mapd actually depend on code from monomeserial or is that part rewritten?

    Furthermore, joint development in that corner would definitely be a benefit for all of us. But beware: coordinating several developers on a free software project, including taking care of cross-platform compatibility, etc... adds more work, too.

    About xxh devices and Linux:
    My personal experience is that the lack of stable audio pd-patches/apps to use with a monome is rather rare, so even if the monomeserial app exists for linux (e.g. serial-pyio) there's still *lots* of work to do to actually make some music with it (that's also the reason why my involvement in serial-pyio's development is stalling).

    What are your plans/ideas/hopes regarding the audio side on Linux?

    (btw: Thanks for starting that project, because it gives me motivation to finally re-arrange my time to continue work on the successor of serial-pyio that will hopefully make life for me and most other electronic-music-makers easier:

    Yes, I still haven't given up on that idea. :)

  • firstly, regarding mapd and monomeserial bits:
    the way I wrote this actually kept a scenario like that in mind. the whole point is that, rather than putting the serial communication bits in monomeserial itself, it's decoupled to the point where the serial communication routines are in a small, separate library of their own. then, monomeserial is implemented on top of that. included in that tarball, in addition to monomeserial, is a simple demonstration program that illustrates how to use that "library" to communicate with the device. one of the next steps here is going to be to write up some documentation for how it's used just in case anyone's daring enough to try it. :P

    the reason I did things that way, in addition to it, IMO, just being a cleaner design, is that I'm planning on writing applications for my monome in C, and I'd like to have a nice API there that I can use without having to use all of the liblo stuff. I'm thinking about writing an identical API to the low-level one that lays on top of the OSC protocol, perhaps for a cleaner separation of client and server.

    and, continuing that train of thought...

    i have a few vague ideas of the kind of applications I want to write. one that I've already been playing with is messing around with fluxus ( ). fluxus is a livecoding environment (much like impromptu, or somewhat like chuck) designed primarily around coding 3D visuals on the fly, and it has functions built-in for audio analysis. it also can send and receive OSC messages, so there's certainly an interesting canvas to play with there.

    my current project, though, is essentially a live looping instrument taking cues from mlr and freewheeling ( ). the concept is something along the lines of syncing to something outside the system via tap tempo, then recording loops of various lengths and playing with them (mlr style). the use case for this particular app is using a laptop as a send/return effect on a DJ mixer and being able to sync the tempo to a track playing off of one of my turntables, then sampling bits of it in. and, with the recent release of chris cannam's rubberband ( ) time-stretching library, creative manipulations of time and pitch could be considered as well.

    i'm trying not to be too ambitious, seeing as how I barely have broken ground on the code at all, but it's certainly an application that I would use myself, and I think that'll be the driving force behind it.

    the goal is also to show that we Linux folks aren't always as mundane as we're said to be. some of us like to rock out too, y'know. ;)

  • i completely agree with developing a stable serial layer that can be decoupled from the OSC code. it's a level of abstraction for which i'm happy to see more interest. monomeserial is a middle-ground solution for flexibility-- OSC doesn't always require programming, but due to the grand failure of mapd the perceived ease of integration isn't much higher than an API (an "osc api?").

    one thing that's attractive about an all-python solution cross-platform support. serial is really gross on windows, and quite wonderful on osx/linux/etc. i'm hoping that the py-serial lib hides these distinctions, but i might be wrong. either way, a good C library would certainly be faster.

    i'm all for collaboration, but as was said earlier, coordination is tricky. having a base library would facilitate several like-minded projects which could be great for everyone, rather than several people contributing to the same code?

    @iotoa: i'm really looking forward to your audio app projects.

  • i am in no place to do any linux programming, what i meant for myself really was to work on the Windows version of whatever you guys have in mind.

    i like the idea of the Serial code seperated as well. of course it would have to be differant on Windows, but i think the *interface* to it could be identical. like, on Windows, a .dll with methods for IO to the device. a generic serial library would be nice, but i personally think having a monome-specific API that encapsulates all the device's logic would be more useful (there are plenty of serial libraries already, and Monome uses a small subset of what can be done with serial, like modems and whatnot).

    if you have time, id love to hear about the interface to the serial library you did. if you want, you can email me, thru my profile here, otherwise it's just my name here, at yahoo.

    i understant the troubles of a full-scale open-source project, but id also love to be able to eventually see a true x-platform API for Serial, OSC and MIDI.

  • Hello,

    I worked a bit recently on serial-pyio.I was using a mac and it worked out of the box. That's the very positive point. I am usually working under linux on a PC.

    The gui is progressing, and serial pyio supports now multiple applications at the same time and app switching. I added support for the adc. This is present in the CVS.

    Adding support for the 256 should not be difficult. We just need someone who owns a 256 that would aggree to write the protocol code. Or, we at least need someone who would like to test code we blindly write, which woul be a bit more tricky. The good point is that it would benefit from the multiple app support, the gui, app switching...

    I am also adding support for detection of higher level interactions. I mean detection of the press of multiple buttons at the same time and sending the corresponding OSC commands. For instant, I am testing detection of multiple press on columns or rows.

    Serial-pyio uses bloking IO everywhere now, so CPU usage is minimum and reactivity has improved again.

    Concluding note:

    serial-pyio is already an open source project:

    Anybody who wants to contribute is welcome. I think rooker will agree on that.