Writing a Standalone Application for monome - Stuck at the first hurdle.

  • Hey guys,

    I built myself a 40h a couple months back and have been loving all of the apps (especially polygome) and all their possibilities, but i'm a fan of flexibility; what if I wanted some areas of the monome to arpeggiate and others to trigger samples or control a looper? I am probably wrong but I don't think this is possible, at least not without Ableton and a lot of hassle.

    So, as I am entering the last year of an audio programming degree and looking to produce an impressive final artefact, I am planning to write a standalone application that allows complete flexibility - dragging and dropping of samples to buttons, audio and midi looping, control zones etc. (I'm still working out the details). I'll have at least 6 months of evenings and weekends to develop it so i'm hoping for a polished product that I can give back to the community.

    The problem is that all my software development experience is in C and C derivatives so the application will probably be written C++, allowing the use of the juce audio/midi libraries which i've spent a year working with, and I haven't got a clue how to interface with the monome outside of SerialOSC.

    So, I have 2 questions.
    - Before I dedicate a few months of my life to this, is there already an application that has this sort of functionality?
    - How would I go about interfacing with a monome in C++?

    Thanks in Advance,
    Monomous

  • yep, rove by visinin is an mlr-style sample looping app, written in c. you can interface the monome via pure osc or libmonome.

  • Hi Monomous,

    You've got basically two options: cook your own serial parser for the Monome protocol or extend your software to do light management of finding and selecting a device thru SerialOSC. You'll want to use Apple's Bonjour development API's to talk to SerialOSC (dns_sd.h).

    I've been sitting on a linux Monome application in C thats fairly complex (~2 thousand lines) that I'd consider releasing if it'd be some help to you. EDIT: It currently doesn't interact with Bonjour, however.

    Murray

  • bonjour is only used by serialosc, if the libraries are found in the system. as an alternative, there's an osc-based discovery method, described here: http://monome.org/docs/tech:osc#discovering_connecting_to_serialosc_devices

    @murray, i'd love to play with your app as well.

  • I recently put out my first monome app, that was written in objective-c. Actually finding and communicating with the hardware were much simpler than I had expected. You'll have a simple test app up and running in no time.

    Basically you need to browse what bonjour devices are available and look for the ones that are running 'monome-osc'. The app Bonjour Browser is useful for debugging at this point. Alternatively, as @artfwo mentions, you can do it just using OSC.

    Then you'll be sending and receiving OSC messages to the monome via SerialOSC to turn on lights and receive input. I would recommend finding a library that wraps up creating and receiving OSC messages rather than having to deal with the network stuff in too much detail (I'm sure there are plenty of options).

    In regards to the actual communication to the monome, make sure you check out the '/grid/led/level/map' messages which allow you redraw the whole grid efficiently.

    Sounds like a cool project, good luck!

  • @artfwo i'll get it polished up over this week and maybe the next so that its usable

  • "but i'm a fan of flexibility; what if I wanted some areas of the monome to arpeggiate and others to trigger samples or control a looper? I am probably wrong but I don't think this is possible, at least not without Ableton and a lot of hassle."

    hello. max/msp can do this without ableton and or max 4 live. you could develop a system of patches that spanned across the monome and could be swapped in and out.

  • you can skip serialosc if you'd like and not do serial parsing by using libmonome: https://github.com/monome/libmonome

    i'd suggest using serialosc however. with a lightweight OSC library it'll be an easy task.

  • libpd might be useful to you:
    http://libpd.cc/about/

  • Wow, I've been pretty busy the last few days and haven't checked back... Thanks for all the help so far.

    Now, where to start?
    @artoftwo rove does look pretty cool and I might see if I can get a look at the source for it. Looks like the functionality i'm after but it's really the UI that I want to perfect.

    @murray Anything that I might be able to draw parallels to/from would be a huge help, thanks for taking the time to finish up.

    @markeats That's a relief, I thought I was in way over my head when I started looking in to this but it's starting to look much simpler now.

    @away message I have done a fair bit of development in MaxMSP and I can't deny its power, but I find working in it very clunky and end up having to spend hours figuring out a workaround that would be solved in a few lines of code. Interface aside, I really want to focus on the GUI side of this project, mapping complex functionality to an intuitive UI is a fun challenge, and i'm not convinced that max has the flexibility to do what I want.

    @tehn That looks perfect. Looking at the documentation it seems it would be possible to use libmonome with serialosc (monome_open() will take an osc url). Which would make this as simple as: search bonjour for device>pass url to monome_open>interface using libmonome.
    I don't know my way around bonjour yet but i'll work it out.

    @karaokaze Thanks! I will be using that in future projects but i'm set on using juce for this one. I've already gone through the painful process of learning the naming conventions and quirks and won't have time to do the same for another library.

  • So to summarise;

    The general consensus is that I should be connecting to the monome by serialosc via bonjour APIs and letting a library such as libmonome handle the network end. Or have I missed something?

  • if you're using serialosc you don't use libmonome. serialosc uses libmonome as a backend. with serialosc you're just sending OSC to serialosc. you don't need bonjour with the newest version of serialosc.

    see here: http://monome.org/docs/tech:osc

  • however, you can also use libmonome to talk to serialosc!
    you're right, if you pass monome_open() an OSC URL, it will talk to a serialosc instance at said URL. libmonome works this way so that just by changing the argument to monome_open() an application can either use the raw serial device or speak to serialosc.

    some gotchas though:
    the OSC protocol backend uses liblo, which is LGPL licensed and may be a speedbump if you're developing a closed-source app. libmonome itself is ISC/BSD licensed so no trouble there.
    also, i don't think the OSC backend sets the prefix and port correct for serialosc to send button data to the app (it depends on you doing this out-of-band). would be trivial to set up though.

    you may be better off rolling the OSC functionality yourself. liblo is good, OSCPack is probably a better choice for C++. the monome OSC protocol is pretty straightforward, and the source for serialosc is available if you run into any oddities. if you want the ability to switch between serial and OSC though, libmonome's the best bet.

  • Thanks for the clarification guys.

    @visinin I'm glad you brought up the subject of licensing actually. I want this to be open source but as it'll technically be academic work, it'll be property of the university and maybe not even my IP. Will have to ask some higher-ups some tough questions.

    Anyway, time to go away and try to get a test patch up and running. Thanks again everyone for the help!