MonomeSerial OSX -- Latest Build: June 25, 2008

  • The version notes below pertain to version 0.18L:

    includes tilt for the 64.

    first build good for 128 (rotation support)

    FYI the following features are untested (?) as I don't have a 128, hopefully these can get tested:

    -frame/row/col to 128 at rotations
    -setting orientation to MonomeSerial via OSC (labels correct?)
    -LED's from MIDI at all rotations (presses looked OK and it was late)

    //begin edit by soundcyst
    ********************* most recent: ***********************

    To preserve version-specific documentation and changes, features and fixes in the new version are listed in the post above.

  • Hi could you/someone/anyone maybe provide a test case(s) for the 128? Be glad to help with testing, but not quite sure how to go about it as I don't quite know what the corrcet behavior/orientation etc are.

    (incidentally, I think there might be some sort of issue, in that changing left/right/top/bottom doesn't make it behave the way I'd expect intuitively and I did see some unexpected lights flash on when using Press Cafe, also I have seen some errors in the console to do with 'address out of range' - just need a systematic way to work out exactly what's going on? Can someone suggest a patch to run and a few combinations of key presses + expected results?)

  • just a little friendly bug report for the latest version of monomeserial downloaded from the site ( when used with the 256.

    i am just setting up my 256 today for the first time and encountered some strangeness when setting orientation and test out the led's when running monome_test. at first i was afraid of hardware failure but the problem seems to be related to monomeserial.

    as you can see in this attached photo (256_photo), i have all but one of the led's turned on in monome_test, but only half of the led's on the device. also, with cable orientation set to "left" and the top-left led turned off, the top-right led is turned off on the device.

    i've also attached a screenshot of my monomeserial and monome_test configs. i am running OS X 10.4.11 and max/msp runtime 4.6.3.

    downrev'ing to version .18D appears to have fixed these issues. the 256 kind of looks and acts like a 128 in .18G! :>

    hope this helps.

    872 x 752 - 199K
    800 x 600 - 119K
  • weird, did you grab the 018G right after it was posted? I might have had a blunder as I was using my 256 to be a 128.

    For saftey's sake (I could have uploaded the wrong one)
    here it is renamed/reuploaded:

    If you can give that a go, I'd appreciate it, as it seems fine here on my 256 doing what your screenshots show!

    dsmudger, I'm not sure on your error messages - where are you getting those? There is no 'range' word found in the MonomeSerial project so I'm not sure, maybe related to the above I hope..

  • i don't know when i grabbed it relative to it's release .... but i probably downloaded it about five hours ago? anyway, the new version seems to work great - both led's and orientation work great in version 018H.

    thanks for the super fast fix!

  • Hey Steve,
    I was wondering if it would be possible to get the source for MonomeSerial?
    I'm trying to communicate with Quartz Composer, and would like to try sending messages as an array of floats, rather than ints (QC has a strange OSC implementation)
    It has been suggested to use a chuck script to interface, but I'm not sure how to go about using two OSC threads in one script, and the whole point is to minimize CPU load and latency...
    I'm on a 40h, so I was looking for the old (pre-256) source, but it seems to no longer exist (did it ever?)


  • hah! thank you very much for:
    a) finding the source for me
    b) showing me that you can search the wiki!!!
    Learn something new everyday...

  • It seems that the led_row, led_col messages are still using the 40h (8bit) range. I can only control 8x8 leds with them. If I go above 255 the leds start at 0 data again, so everything apart from the first 8 bits seems to be trashed.

    Same problem applies to the frame message obviously.

    I'm using the latest (18H) version of MonomeSerial.


  • you use multiple bytes to access a full row:

    /test/led_row 2 255 255

    would turn on row 2 cols 0-15

  • Ah that makes perfect sense. Thanks!

  • I can't figure out how to use /frame on the 256. According to the OSC specifications only one byte is used for every row, so that would cover only 8x8 leds. I tried using the optional x y offset parameters, to cover the space in 4 separate frame messages, but that is giving me all sorts of unexpected results. Its not a big deal atm since I can use either led_row or led_col to do the same, but having one message to cover the whole unit would be nice.

    /intensity is a global thing due to hardware restrictions right? I just think it would be awesome to have control over intensity per led. I'm sure you already thought of that, but I couldn't resist to ask;-)


  • per-led brightness would be a hardware overhaul, but we like the idea (though it defeats the binary system).

    are you looking at ?

    /frame A B C D E F G H x y i think works, if you use offset x,y as multiples of 8. so:

    /frame 0 255 0 255 0 255 0 255 0 8 would make stripes on the bottom left quadrant.

  • Yep those are the specs I'm looking at. That message is definitely not working on my system. The frame message like you suggested doesn't do anything, and some other combinations just give me unexpected results.


  • hmm. that's an official bug, i wonder if it cropped up in a new version. i'll do some testing when i get a chance.

  • Hi Brian,

    Any news on this yet?

  • i enjoy your name.
    0x80 = midi note off channel 1.

  • Regarding /frame and the OSC spec.

    I delved into it before here:

    and again here:

    Basically, contrary to the specs, the offsets need to be specified BEFORE the frame data. Which mostly makes sense, given the way that other optional modifiers are spec'ed.

    ie, /frame x y A B C D E F G H

    Offsets that are not multiples of 8 will not necessarily work as expected, which is either a bug or a limitation in what can be easily accomplished in MonomeSerial, depending on how you look at it.

  • Ah! Cheers for that! It works like a charm.

  • Hi,
    i'm using a macbook with leopard as OS but i doesn't recognize my 40h...
    in the device field says "no device available" while on my other macbook with tiger works perfectly,

  • Did you remember to install the FTDI driver on the new machine? Also, not sure if all versions of MonomeSerial are Leopard compatible, but the newer ones work fine.

  • O no! I take that back. Frame is not working after all:-( I'll start a new discussion on this.

  • The most recent source has no xcode project in it. any chance you could upload the most recent source with the xcode project included. wanted to tinker about a bit....

  • thanks a lot i completely forgot about the FTDI driver...

  • > The most recent source has no xcode project in it.

    Use the original Xcode project and replace the updated source files.

  • OK downloaded older projects:
    attached monomeserial-0.17-src.tar.gz
    attached monomeserial-0.15-src.tar.gz
    attached monomeserial-0.13-src.tar.gz

    The xcodeproject file, "MonomeSerial.xcodeproj", just shows up as a "default unknown file" or just has a blank icon. When i open her up with Xcode, nothing happens. What version of Xcode are you using? Im using Tiger with Xcode 2.0. Not really an Obj C/Cocoa programmer per-say, Just looking to add a couple simple menus so i can have applescript access and keyboard commands...


  • I'm using XCode 2.4 but I didn't make those files.. I'm not a programmer either ;) good luck.

  • I actually just realized i have access to monomeserials params via OSC...makes life a lot easier. You guys sure did think of everything...
    Thanks again for all the love...


  • > I actually just realized i have access to monomeserials params via OSC

    may help

  • @kid_sputnik -
    Yeah thats how i noticed this...Any plans on being able to change the Address or Ports via OSC. Dont even really know if that would be possible

  • Question from a new user:

    The data on is mostly for 40h. Is there any _major_ difference in how it communicates with a 256/128? I've tried to divine the differences by looking at the serial protocol for the 40h and 256 and correlating that with the way MonomeSerial wraps around it, but I've had some problems.

    It seems that /led_col, /led_row, and /frame are only addressing half of the monome...

    I'm trying to teach myself ChucK by updating the "letters" app for the 256/128. I thought it would be really easy but it's been a bit harder than I thought.

    Any ideas? Or other resources on the site that I missed that would help?

  • The OSC spec is mostly compatible.

    /led_col and /led_row can address longer lengths by specify multiple bytes.

    "/led_row 2 255 255" would turn on all LEDs in the third row of a 256 or horizontal 128. (Or two side-by-side 40h/64s with the same prefix and an offset.)

    There is no simple way to change only the second (or further) byte using /led_col and /led_row without affecting the first.

    /frame takes an optional x,y offset, although contrary to the spec (unless it has been updated) the offsets come *before* the frame data.

    "/frame 8 0 255 255 255 255 255 255 255 255" would turn on all LEDs in the upper-right quadrant of a 256, right half of a horizontal 128, &c.

    It might work, but not necessarily 100% as expected, when the offsets are anything other than multiples of 8.

  • Thanks bean - I think that's just the info I needed. big ups. If I get my little letters patch working for the 256, I'll post.

  • bangInclude:
    not sure if this would be reliable. i suppose it would be possible - the OSC command would basically be sending a message telling the host to make a new connection, and then kill the old one. im really not sure how useful this would be, although im sure you have plenty of ideas. what i mean is, i think it would cause more confusion than its worth. it would probably be a perfect example of why its great that monome serial is open source, since you can always add this yourself to a custom version (id say the released version, but im not sure if brian would be into this idea).

    what we need alot more is per-device /sys commands (instead of just ordinal) and a /sys serial query command, and most important individual OSC ports per device. suprisingly, monome serial's OSC code has this in place to a degree, but the GUI does not. also, im thinking maybe per-device Protocol select as well? its nice to say just use OSC and use a third app for MIDI conversion, but that is alot more work for the end user compared to just letting the user select the protocol for the device itself. i think both protocols for a device is overkill though.

  • @kid_sputnik -
    EDIT - What i would like is to be able to have individual ports per device... Also, some way to set up Monomeserial so it would *itself* be OSC controllable. I know now you can talk to MS via OSC using the /sys prefix, but im talking about giving MS its own UDP port. You'd set a seperate port for Monomeserial, then would be able to change things (read Ports an IPs ) with Max, OSCulator, Chuck... This way you wouldnt lose connection if you were to change the Monome's listen port.
    Don't have any experience with Cocoa or Xcode but just got the Monomserial XCode project to compile, ( YAY! )so thats a start.

    I believe i have an old Build of the OS X source - .17 any way someone could upload the latest version that fully supports a 128? Or point me in a direction of a link...



    latest sources with some 64 fixes

  • Is there any particular reason the project files are never included with the source?

    I made it work once with the old project files, and then it defeated me with newer versions, and now I'm not very inclined to try again. The fileset has not stayed exactly the same since the project file I have, and it's a bit of a blind guess trying to modify it to work with the newer files.

    If there's a good reason for not bundling the two together that's fair enough. But someone has to have a working project file for XCode somewhere in order to build it...


  • The only reason is I don't believe I changed the project file besides adversely, e.g. having it reside on my desktop and point to stuff on my desktop and an strangely named liblo which I linked in myself.

    The only snafu to the project is building Liblo, which has nothing to do with the project file. Thus if even if I sent you my project you'd still get a build error and quite likely the same one. I posted a how-to on the "old forum" regarding this as nobody seemed to know when I was trying.

    If you post an error I'd be happy to try and help you decipher it. I'm very used to errors, its when I hit build and there are no errors that I get surprised ;)

  • I got past the liblo issues before using your howto on the old forum, so I know it can be done.

    I suppose as a matter of principal I think it would be good to have a full buildable source bundle available.

    What does everyone else think?

  • i think unless liblo is dumped that will never happen!

  • Whyso?
    Can we not get liblo building as part of monomeserial?

  • I've taken the liblo source and built it into an xcode project that builds universal-binary versions of both a static library, as well as a framework (which can be put into the frameworks directory of a GUI app bundle). This is much easier than using the unix style building of liblo (I never could get that to build universal correctly).

    I've uploaded the project if anybody's interested:

    It also builds the example_client and example_server command-line apps. The example_client is a good starting point for writing custom OSC apps that talk to the monome through Monomeserial.

  • friarwyer - Excellent, will take a look later.

    Anyone else got any cool stuff hiding under their mattresses?

  • @ eman - totally off topic

    sorry, i cant find any other way to get a message to you, i am just after the dimensions of your flightcase?!

    you can mail me at

    lwarren (at) ccm dot ac dot uk

    or start a new thread! cheers mate

  • the link is dead :[

  • top of the page.

  • what a nice page.. i like

    Check out Auto Skinz Online Now and Save 30% on Select designs. Hiqh Quality digitally printed auto graphic kits for any vehicle. Many different designs and sizes to choose from. Made from easy to apply vinyl anybody can do it.

  • Boy I sure would love to run Monome serial on my G3 Tower. But I'm stuck on OS X 10.3.9.

    What sort of sacrifice to the coding gods could I make to possibly get a build that will run under OS X 10.3.8?


  • Hello. I'm new to the site. I'm trying to get my PadKontrol going with monomeserial and monomulator to run MLR. I've managed to get everything hooked up but MLR consistently crashes once I click on DAC. I'm running Mac OS X 10.4.11. I've run MLR by itself and still the same issue. If there's a better way of reporting the bug let me know and I'll pass it along.

  • you should ask the author of monomulator. i also don't think you need to run monomeserial for this.

  • two things i think monomeserial desperately needs, if it doesnt have them already (i couldnt find them) is

    the ability to save presets

    and the ability to reopen the window if it gets closed

    i spend more time setting up monome serial than anything else because im using 4 separate logic boards, so i need to retype all my orientations and offsets every time i open monomeserial, whenever i want to make a change, as well as every time i accidentally close the window. i would really really appreciate this functionality

    you guys are awesome, keep up the good work!