rove: a cross-platform (mostly Linux) mlr port in C

  • I've been working on this for quite some time and I made a decision recently that I should do a better job of following the open-source "release early, release often" mantra. So, thus, this release is far from perfect, but it works.

    Rove, in essence, is a sample-cutter that is heavily based on mlr. It borrows the major concepts and interface paradigms of loop handling and display, choke groups, and pattern recording, but differs in the specifics of how each of them function. It is designed primarily to run on Linux, though it also runs on OSX assuming the right libraries (which are detailed in the README) are installed.

    As of this initial release, the following features are implemented:
    - file playback (forward and reverse!)
    - choke groups
    - tempo quantization
    - pattern recording

    There is no theoretical upper limit for loops loaded, number of groups, number of patterns, or steps in a pattern. Practically, of course, the limits (save for number of pattern steps) are what's imposed by the monome device you happen to have.

    It's not all rosy, though. Here's what's missing:
    - a GUI of any kind. it's currently a console program that reads in a text file with a list of loops.
    - speed control
    - sub-looping
    - clean code (it's currently messy, uncommented, and likely nonsensical)

    And, on that last note, I'm going to quit my ramble and actually release some code. Everything not covered in this post should be covered in the longer-winded README included with the download.

    get the source from the github repo:

    enjoy :)

  • Hi Visinin,

    Finally managed to compile and run properly (not on my 64studio but on my Hardy Heron)...

    What i can say first is that Rove is pretty light on cpu ressources...
    Very reactive.

    One thing though:
    I loaded different tempis loops and it seems that they each run at their own speed! I played a bit with that session file and i can't get around it.
    [edit] Maybe that's what you meant by "no speed control" [/edit]

    Otherwise, great job!! I think u deserved ur rest ;) .

  • yep, that's the "no speed control"

    i tested this out on Mac OS a couple of days ago thanks to the joys of IRC, and it works exactly as described. there's a lot to be done, sure, but hopefully others give it a test and pitch in with their comments.

    thanks will!

  • rove was missing a wiki page, so i spent a few hours creating one:


  • thanks! i was trying to install it yesterday on my mac. no luck yet. will try again today.

  • To get rove to compile on mac os x I had to edit the configure script, and change the line:

    JACK_LIBS="-ljack -lpthread -lrt";


    JACK_LIBS="-ljack -lpthread";

    i.e., I removed the -lrt linker command. A quick google search suggests that librt is not available for mac os x. I'm not sure if this effects the functionality of rove/

  • nope it doesn't. it's a jack dependency on linux but is not necessary on OSX.

  • going to be testing this out on osx in the near future... !!!!!!

  • what are advantages to running a port of mlr in c (rove)?

    easier on the cpu load?

    it's worth noting that i am on osx, so I am looking for information pertaining to the osx platform.

  • considerably reduced CPU usage (single-digit percentages usually) at the expense of somewhat reduced capability because i haven't gotten around to adding it yet.

    the core features (chopping, groups, tempo stuff, pattern recorders, multiple sessions) are all there and work very well. rove is very responsive. it's lacking some features of mlr that would be really nice, however. these include resampling, automatic speed matching, any sort of sync, and inner looping (i.e. pressing two buttons in a loop to just loop that section). there's nothing prohibiting any of the above from happening other than a lack of time and, to some degree, interest (on my part).

    it's just a different app. a little harder to get working, maybe, and certainly a little nerdier, but just a different spin and implementation on the mlr concept.

  • And, of course, there's no max runtime requirement, so you're not tied to a full-on Windows or OSX installation. Running something mlr-like off of a tiny embedded device is more plausible with this, if you're so inclined.

  • enticing. i have been wanting to learn c/c++ and then some. expanding the functionality of rove would be a future goal. i have yet to begin my studies.

    what is automatic speed matching? and by sync do you mean, for example, syncing the tempo of multiple instances of rove? lastly, does rove allow for audio routing of groups as stereo pairs?

  • 1. rove can't match/set tempo based on a clip you load in. you have to manually enter in speed values for each clip in the text config file.

    2. syncing to, say, a midi clock. rove can't do that.

    3. yes. you have to use JACK, or JackOSX, of course. rove can't output sound any other way.

  • word! thanks for the info.

  • JACK is unfortunately a requirement, but yeah, each group has its own independent stereo pair. i really like the idea of routing each group to its own set of physical outs and then running that into an outboard mixer or some other gear like that, even though i haven't done that yet.

  • "i really like the idea of routing each group to its own set of physical outs and then running that into an outboard mixer or some other gear"

    i've written an implementation of this idea in a different project i'm working on, tons of fun and totally worth it.

  • wow. this is exciting. thanks for sharing!

  • Reading this makes me feel bad for sitting on my branch of Rove that I hacked RubberBand support into! RubberBand is a lib for doing realtime independent pitch/speed adjustment.

    It worked ok, but chewed up CPU. It also added just enough latency to affect the playability, which kinda knocked the wind out of my sails.

    If anyone cares, maybe I'll try to make time to push it out to GitHub?

  • And in case anyone missed it, ioflow posted some great performance videos using rove. It seemed more than stable enough out in the field.

  • @bodhi:

    holy shit. github please please please please.

  • @visinin pushed: (master, small updates?) (branch that includes rubberband module)

    I haven't touched it for about 6 months, so I really can't remember what I did, and I didn't bother to configure Emacs to copy your coding style. You'll have to get rubberband compiled on your own and edit the Makefile include/lib paths or something, sorry!

    My original plan was to add the pitch/timestretching to enable syncing to midi clock later on, but when I actually got it working, it was a bit of a let-down as I said before. When I thought about it again recently, I thought about ripping out the rubberband support and just dropping/duping samples to sync properly. I'm hoping it will just add character to the sound, instead of sounding horrible ;)

    Another thing that would be really nice, and that shouldn't be too hard with Jack is having some audio recording facility. It is so much easier for me to contemplate doing this stuff in C rather than trying to do it in Max or Pd!

  • @bodhi:

    by audio recording, you mean live input or resampling? especially the former, mash-style, would be extremely awesome!

  • The former, live input. I used to play a bit with a pianist, and being able to record phrases that he was playing in live would have been really fun.

  • @ioflow so cool to see a gentoo user performing with monome. /neckbeard

  • i dont know what im talking about but is it possible to ad rewire to this?

  • @maersk:

    rewire isn't open way to compile it. also, it's specific to just two operating systems, whereas JACK runs on win, osx, and linux.


    gentoo developer, even. i gotta run it on gentoo, of course...i plan to demo it at SCALE next week, actually. do you run gentoo with your monome? if so, that makes three of us.

  • @ioflow i thought as much :)

    i'd love to get onboard with some ui design here guys...

  • I was just thinking... this combined with a raspberry pi or with a panda / beagle board could be a fairly affordable headless monome

  • @ioflow oh, wow! sweet! i'm not a gentoo user. mostly use arch and ubuntu but have a fondness for gentoo as i have a shell on #anapnea.

    in general, i'm really glad to see applications like these. max/pd and other interpreted languages are great but full of gui bloat.

  • @maersk @ioflow Depending on what you want to connect it to, you might Just be able to run Jack on OSX and connect up the applications directly. Jack is kind-of a "better rewire"... for varying definitions of better!

    About UI, I'd actually really like to make a simple console GUI for it ;) something vaguely like tektracker:

  • meh. something in qt would be more established and cross-platform, and look much nicer, as well as being visually consistent between platforms. i've been contemplating doing something in pygtk/pyqt for editing config files -- adapting similar tools already out there to give some possible arguments, pick files, and write it to disk, and launch rove using a given config as an argument. but then i decide it's too much work, and just go back to making music with rove.

  • @ioflow ah, a front-end/launcher is a good idea... I'm good with the config files really, but i'm not really using rove anywhere near as much as you are, I imagine.

  • the config files are pretty straightforward, but a gui to generate could definitely save time, especially when i'm in the various stages of production, doing little experiments with samples, and making tons of tiny changes.

  • I've just pushed a branch that has recording support:

    On my horizontal 128, on the top row, press 5th from the right (so: session next/prev, 2x pattern recorders, *then* recording button). To record, hold the record button, it should light up. Then press a button as if you are triggering a sample, and Rove will record into that ... "track"? (file_t). It will record for as many beats as the track is configured for. After you've triggered recording, you can let go of the record button.

    It creates 2 Jack input ports, and connects them up to Rove's master out by default.

    In all my work I've broken a couple of things. Biggest one is reverse samples, they just play forwards with weird button offsets. There's also a crash-bug that I've triggered a couple of times when looping sub-ranges of samples.

    Two more features I'd really like to add are pitch-time-stretch on load (not in realtime), and midi-clock-sync. I tried to hack this into mlrV a few years back, and I must be a sucker for punishment wanting to try to do it again!

  • And of course I seem to have added a bug where it becomes impossible to deactivate a group :(

  • Quick fix: the track won't light up playback-style when recording. Just the first column's led will light.

  • @bodhi: how's the rove-record branch coming along? are the bugs ironed out, yet? this would really open up the improv performance possibilities, which is how i like to perform, if it's in a workable state!

  • @ioflow Sorry, I haven't worked on it since my last post. I think having no-one reply ruined my motivation ; ) I might get out my Monome and see what state it's in.

  • +1 for interest in this branch of rove.

  • Didnt realize this one got an update. Used to play with rove to the point where the lack of recording feature got unbearable. I would really like to something like that happening!


  • After using pretty much only this application since i got my monome, i want to help out with improving it. I know only the very basics of C but could easily pick stuff up if i just know here to start. Problem is, the code is (as is mentioned) poorly commented, so its kind of hard to find a handle to grab.

    Any advice here? There are some examples that come with libmonome. Perhaps it could be a good idea to start studying those?

  • note that there are a few other branches of rove in the wild, including one with audio input. check the forks on github. those might also be of interest. what specifically would you like to improve? bugfixes? additional features?

  • Well, i only know what i want based on my current work flow. I would have wanted to be able to switch between playback modes like grain, one-shot, and repeated looping (even slicing, but that would be more time-consuming to implement). That along with the ability to be able to select a directory of samples and generating an input file from it, would sum up what id like before even considering implementing audio input - a step one if you will.

    Iv always enjoyed the experimental approach to finding samples that i enjoy playing around with. I might spend a couple of hours finding a good 20 of them to load up into the monome for finding the sweet spots that are useful for looping. Id like to bring that into a live setting where i can see the amplitude spectrum of the sample that im currently playing along with being able to modulate volume. That would require a GUI, which would be my second milestone.

    As of right now, im working on a simple script to generate input files. After that i will start studying the code.