[new project] mlrVST

  • Well, monomeemu is working with the LP ( no led feedback though : ( ). I didn't try to max it out but there were no crashes all three times I used it. Will there be midi mapping available for parameters like playback speed etc? is there a way to record patterns within the vst?

    Thanks for all of your hard work.


  • was jamming away flawless earlier! LED feedback and all.

    Is there a quantise and stop function?

  • yes a stop would be nice.

    @ dean what setup are you running the vst with?


  • @Redoom -

    ableton 8.2.5
    windows 7
    monome 256

  • @dean - sweet glad to hear it. i've found a few bugs including one that makes the ableton CPU shoot to 100%, I've updated the download on github.

    As for quantize there will be eventually, but it's low down the list.
    It'll eventually have a similar setup to mlrV where you can map the whole top row to whatever you want, so yes stops will be possible.


    pattern recording and midi mapping are coming! it's quite difficult to do though so will be a while.

    Realistically I can see this taking at least a month so please be patient, there's still masses to do. I start my PhD in a fortnight so I'm trying to get the heavy stuff done by then. The idea of posting these very early builds is just to keep me motivated by seeing that people are interested!

  • @Redoom:

    to quote upstream, "everything will be midi/monome-mappable" at some point. i know i'm definitely looking forward to presets and session/setlist storage!


    group mutes aren't working yet. workaround for endlessly repeating loops: turn off "latch," set playback mode to "loop chunk," press a row button.

    for quantize, i asked @hemmer about that, but it'll be harder to code, so it's lower on the priority list. i suggested poking through rove's source to see how @visinin did it. there may even be some internal quantization mechanism for JUCE, which would be a lot easier than coding one from scratch.

    patterns will apparently be stored as midi clips, which suggests that quantization will be tied to midi clock somehow. it further opens up the possibility of using a midi mangler, such as hypercyclic, to glitch up the pattern as it's played. maybe even the whole loop, depending on how midi is used within mlrVST.

    it would be pretty cool if playback position/BPM was tied to midi, so that sending midi messages from an external app would seriously mash and warp the loops. opens up more possibilities for musical expression than can be done just by pushing buttons in a row.

  • there is definitely interest! Is there a place or info for sending donations?

    Also, any thoughts on why there was no feedback on my LP?


  • i'd rather not take donations until the project is a bit more mature to be honest. there is sometimes the risk that donations can be seen as a purchase, putting me in the position where I feel obliged to provide the community with a finished product sooner. i'm not for a second implying that you or anyone else on these forums would take that attitude, but I'd rather not risk it for now. i will pop a paypal or similar up there when it's released or a fairly stable, feature complete beta comes out.

    in other news, features that people might not be aware of:

    - middle-click drag moves the selection window
    - ctrl-drag moves one of the end points of a loop
    - double click selects the whole sample
    - changing host BPM changes sample speeds (unless you lock the speed)
    - when you select a sample, it automatically selects the closest speed to 1, so 32 bar loop at 120bpm and a 1 bar loop at 120bpm both start at speed 1 if the host is also at 120bpm
    - all weird and wonderful sample rates should work the same

    a fun thing to do is lock the speed to near 1, select a small part of the sample, then move the window with the mouse. granular synthesis!

  • Awesome project can't wait to try it!! :)

  • Just working on the preset system just now and was wondering if anyone had any input on how it should work?


    - separate xml files for each preset which are referenced in a separate set list xml file? [[http://pastebin.com/ajLqKNUT|example]]

    - one big setlist xml file with all presets in it: [[http://pastebin.com/i7P0RQsP|example]]

    - other?

  • all in one is probably easiest, just so that fewer things get scattered thoughout the filesystem

    design question: does it have to be written in xml, with all the extra tagsoup that's not easily human readable? what about a simpler ini-style format, or some other name-value pair that's easy to edit by hand? heck, even bash format is easy to read for simple variables.

  • similar to mlrv 2 would be awesome!

  • Agreed, like MLRV2 would be awesome.
    But without the downside of being unable to go from a preset to another.

    I explain myself:

    Some of my works needs two presets of 15 samples and switching from preset 1 to preset 2 while some loops are playing makes them play all wrong.
    Therefore I have to stop them before switching which is not convenient at all.

    I guess some of us might appreciate the possibility to do it smoothly.

  • cool, all-in-one is looking easier to do anyway.

    @nightmorph - initially will be xml though that's something that wouldn't be //too// hard to add further down the line. its just JUCE has a great Xml parsing library built in.

    @suburbananimal - this is something i'm keen to get right. it's easier for me to have it set up so that switching presets stops existing loops playing, though it might be nice to have it so that you can set an option to keep the loops continuing. i'm definitely aiming for smooth preset transitions, it was something I couldn't quite get how i liked using mlrV. one thing that might be an issue is tempo - currently the host controls the bpm, so tempo changes between presets would need to be triggered by midi mapping within the host.

  • you might try checking out how rove does this. it lets you switch between presets while still playing the old preset's loop at the old bpm, even as you play new loops at the new bpm. as soon as you press any buttons in that old loop's row, or if you hit its group mute, it switches over to the new loop/bpm assigned to that row, clearing out the old loop.

  • @hemmer:I guess some people will need an internal tempo mode with a next tempo button like in mlrv2.

    @nightmorph: I'll definitely have a look at this one.
    BTW do I have to compile the program or is there a Mac OSX binary available?

  • @suburbananimal:


  • quantize is pretty easy, at least how i implemented it in rove...basically, you have a 1-length queue for each loop, and pressing a button in that loop pushes the action onto it (or replaces the action that's already there). then, on the quantize tick, the action gets popped off and performed. rudimentary but works well.

  • Good job on this, I've been waiting for someone to develop an mlr to use within live that is geared more toward granular synthesis rather than clip mashing.

    Just tested on Windows 7 using Ableton 8.2.5 and a Launchpad. Monomeemu reacts fine in terms of sending to mlrvst, but does not receive any OSC for LED feedback. I am using prefix mlrvst and ports 8000/8080.

    Aside from that I have only one recommendation, which is to allow for numeric input for the speed rather than relying on click and drag (unless I'm wrong on this, but when I double clicked on it it switched to text entry, but wouldn't allow me to put in a number)

  • @phlemz - good feedback thanks. i wouldn't worry too much about the LED feedback for now, i will eventually be using the new OSC spec, this is just to make life easier while testing. numeric input for speed should be possible (if in the range 0 - 4). this is just temporary until i can think of a better way to do it. i like how max handles it, i.e. you drag the numbers to change it. the simple slider (currently used) is obviously limited to a specific range of values.

    @suburban - the more i think about it the more an internal tempo makes sense. in my eyes it's neater if the host handles these things but that's not always possible. plus it makes a standalone version more practical.

    @visin - yip that makes sense. i will get around to it eventually (should be easier once the internal tempo thing is up). i don't use quantize myself but i know a load of people do so definitely will be coming.

    @all - development will be a little bit slower now i'm afraid, still ploughing away though, hopefully there's enough to tinker around with for the curious!

  • This looks very nice. Thanks for your hard work. I have been waiting for this.

  • This looks great. Has anyone got this up and running under linux yet? Thanks.

  • @marto: read the thread from the beginning.

  • @nightmorph

    sorry, must have missed that when browsing from my phone, cheers.

  • for the curious, development is definitely still active, just will be a lot slower now. i can only realistically work a little bit at the weekends. there's hopefully enough to have a play around with for now, but there's loads to do (in order of priority):

    - presets (getting there)
    - (re)sample recorder (not started)
    - pattern recorder (not started)
    - polish

  • Will you implement inner looping and quantize? Running on Win7 64 in cubase 32 let me know if you need me to test anything and where to donate :)

  • Hi Hemmer,

    Another suggestions:
    In my opinion there's a missing mode in MLRV2.
    There should be a mode where you can play a slice and mlr play it automatically to the end of it.

    To do this MLRV2's slice mode you have to keep your fingers on the corresponding button and unpress at the right moment which makes beat chopping quite difficult.
    I also think there should be a per sample quantization like in ableton live.

    I'm also a developer and if you need help for coding some functionality i'd be glad to help :)

  • Keep it up! I was just sulking at the lack of a MLR VST. Your work is very much appreciated. If you can make this fully functional I believe a MLR/MLRV VST could be the most popular Monome app.

  • I second that ^

  • >- polish

    finally, the first version of mlr to be translated into polish. a noble goal! keep up the good work.

  • @ suburbanimal - love that idea, just implemented it just now.

    @ and - inner-looping and quantize are definitely on the way (the former should be easier to do)!

    as for helping out, people are of course welcome to contribute but I don't feel the code is particularly readable at the moment. I'm trying to write a developers guide to help people get up and compiling, and hopefully this should make it easier to contribute code / understand what's going on.

    just put a new version up on github:


    - internal/external tempo (that nearly works, but is still a bit weird on reopening the GUI)
    - preset visual side (but no functionality yet)
    - fixed a couple of playback bugs
    - top row now act as stop buttons (eventually will have custom mappings)
    - new playmode (as suggested by suburnanimal)!

  • yeah, that play mode is something like 64fingers' "one-shot" mode. it's a very welcome addition! now i don't have to try to duplicate it by chopping up a sample into 8 to 16 pieces and laying them out sequentially in 64fingers just to get that effect.

    thanks for everything, ewan!

    oh, and lemme know if you want help writing the "how to compile" part of the developer guide; i can assist on the linux side.

  • I'm so enthusiast hemmer about your project, can't wait to try it.

    I'm currently using MLRV2 rewired to Ableton Live and the sync between the two application takes 40% of CPU usage which is huge compare to the 5% for the rest.

    BTW thank you very much for having given consideration to those ideas!

  • Same ^ I would love to use MLRV in my live sets with Ableton but because the projects are so big along with the rewire it crashes sometimes and I cant risk a crash during a live set. I switched to Molar because of this but MLRV still has my heart so Keep it Up and Thank You!

  • Oooh, this MLR is so sweet! Running very well with monoemu + LP, really fast, stable and so little cpu usage. Really dig the different play modes. Fantastic work!

    EDIT: Possibly found a bug? Or it just hasn't been implemented yet? It's not possible to launch multiple samples at the same time.

    Also would be cool if it had the feature of mlrv 2.2 where you can stop the sample playback by holding a pad and pressing the pad before it. Makes for some nice break stops etc.

    Will definitely donate when you feel the time is right!

  • @cookie:

    the latest source on github can stop clips with key combos, but i've not put up a .dll release with this yet.

    you should be able to launch multiple samples. can you elaborate a bit more on what specifically isn't working (i.e. what steps I need to follow)?

    cheers, hemmer

  • speaking of keys...latest git has some interesting light-up vertical row effects on the right half of my 128. column 9 lights up from the bottom to within one row of the top, same for column 12. samples only play in the first 8 columns though; it doesn't seem to know that this is a 128.

    also, the group buttons don't light up. they work just fine for turning off each sample, but never light up to indicate playback.

  • Hey Hemmer, sorry late reply.

    Ok, thanks, I'll stick to the .dll for now.

    So yeah, I can only launch one sample at a time. I'm on win7 64 with a launchpad running through monoemu. Might be where the problem lies i guess..

  • a progress report: i've spent the last few weeks on rewriting quite a bit of the code due to the rather silly way I had things organised (I have some awful habits for just rushing into a project with too much planning!). the upside is that things should be running quite a bit smoother now. the issues with the GUI freezing up are gone, and the whole thing should be a bit more responsive. Rudimentary inner looping is now working, though I still need to sort out looping for the last segment of the row. the pop sound bug should be fixed but please still take care!


    next things to look at are finishing up the presets (aren't useful at the moment but the framework is there) and some pattern recording (/quantize).

    @Cookie that's pretty odd. are you sure the different strips are on different channels (colours)?

  • @Hemmer

    Yeah, different channels for sure. They still mute each other..I've noticed the "in-lamp" on monoemu is rapidly blinking constantly. Is this normal anyone?

    Oh well, I'll just use Mlrv2.2 for those rapid improv button press sessions. The vst is still very nice for building tracks with its powerful looping features!

  • Is this still Windows only?

  • it's never been windows-only; the source had always been there. it's just that there's only a precompiled dll for windows users. you can build it yourself if you want to; i've been doing doing so on linux since the project was announced.

  • to be fair it might be a little tricky to get working on mac (no-one has reported success). the tricky bit is getting the right OSC library to be linked (ioflow might be able to help with that).

    i'm still hoping to buy a macbook pro in the next few weeks though so i'd hope to have some mac builds up by then!

    @cookie - i'm sure we'll get it working eventually (particularly once it starts using the updated OSC spec)

  • I`d love to try this as well, but I am also osx.
    I have zero knowledge on how to build that myself, sorry.
    Any smart user wants to give us mac users a x-mas present?

    edit: @hemmer
    sounds great. Thanks!

  • @hemmer
    once this vst has come along a bit further, do you think it could be possible to run multiple instances of mlr vst? it would be cool to drop 2 instances of mlr vst into ableton and put one on each side of the crossfader. then if you connect two different monomes through pages, and set each of the monomes to the 2 different mlr vsts? do you think this could be possible? certainly not right now, but in the future? that would be really ideal for me personally.

  • @nowawakelow - yes I can't see why you couldn't do this. the code in it's current state won't allow multiple instances but I think it's relatively easy to set up. I could put an option into to set the prefix within the VST so you could have /mlrvst1/led ... and /mlrvst2/led ... etc?

  • @hemmer
    that would be really awesome if you could change the prefix on the vst itself, that way it's just way more customizable. thanks for all you hard work on this project so far. i can't wait until presets are available. and it's also really cool that it's a straight vst, so tons of people will be able to use it that don't have m4l.

  • little update for everyone. I now have a nice new Macbook Pro so you should be seeing some mac builds fairly soon. recently I have been getting the resampling / recording mechanism up and running, and improving the thumbnail code.

    I have managed to build the project for Mac, although I've not got the OSC libraries working. as this is literally the first time I've set eyes on a mac, I may need some help getting the libraries to work (particularly people who have used oscpack).

    i need some sleep!

  • ahhh yeah! i am not familiar with c++ or oscpack, but am on osx and will do what i can do to help out. let me know what you need, i'm there.

  • i can't wait to test this out on osx. it will be a very happy day whenever it comes. also can't wait to see what the finished gui will look like, really digging the design so far.