pd_mlr - Pure Data sample cutting app * v0.6 available *

  • Here's my first attempt at creating a monome app using Pure Data (extended version required - see http://puredata.info).

    pd_mlr is a sample cutter based upon the original mlr (thanks Tehn), the work of Gwen (Axiome) and @ucacjbs & @smioliolio (pd and max mlr tutorials, respectively). I undertook this project to 1) learn more about pd; and 2) to create a sample cutter for my 128 with more groups and more recorders.

    pd_mlr features:
    - Monome configuration: 64, 128H, 128V, 256
    - 4 groups + 4 recorders for 64 or 128V; 8 groups + 8 recorders for 128H or 256
    - each recorder can record either button presses or audio; recorder length adjustable from 4-32 beats; recorder can toggle play/stop
    - quantization
    - "intelligent" sample load, which finds nearest multiple of standard beats
    - save/load of sample sets and configuration parameters

    My implementation of some of these features is unorthodox, so read the help file (click mlr_help box) for details - especially for the pattern recorders.

    I don't expect this application to take the place of the more robust max sample cutting apps, but hope that for those considering application development using Pure Data this might be of interest.


    UPDATE April 8, 2010
    pd_mlr V0.5 now available
    see my 4/8/2010 post below for release notes

    UPDATE August 17, 2010
    pd_mlr V0.6.1 now available
    Now uses mr peach external for OSC communication. mr peach is part of pd-extended package, but you may have to add path to mr peach directory to your pd startup.

  • Great work Bongo! I will try to try it out tonight. Good to see some more PD apps and a version of MLR might just be some good enticement.

  • yeaaaahh Bongo!

  • thank you, i try to learn pd at the moment, and this is very helpfull for some better understanding of more complex work with it.

  • anyone have a chance to try this out yet? i am interested in your feedback.

  • I'm sorry I haven't gotten to it yet. I will try some time this early evening and get back to you soon.

  • I've tried it and I like it, but then again, you already know that.

  • You could call this "Pummeler."

  • Bongo, this is great! It works like a charm. I have to complement you on one particular aspect specifically. I really love the toggle button deciding whether you record button presses or audio. Do any of the other MLR's have this function? I know there's the resample thing but it has always seemed a little complicated to me. Your simple toggle makes it really easy. It really takes the concept of MLR and adds a looper pedal on top of it in a way. My favorite feature by far. I also like that you can turn quantize completely off. Really good work.

    If I were to give any constructive criticism: I noticed CPU load looked a little high. It wavers between 35 and 48 but I haven't noticed lag or audio problems. The other thing that seemed a little hard to figure out at first was the pattern recorders. They work fine, as described and I also like the fact that they retain the pattern or audio if switched off and then on again but it seems that once you've recorded into one of them there's no way to get the LED state back to the way it was when initially loaded. It's really the tiniest detail but it seemed like my OCD was triggered by it. I had no problems with the hold for 1 sec aspect but that could be a complaint from some of those with more skill than I at performing with the monome.

    Now just add the external sync and some multi-outs to your DAW and your super golden!


  • @egon77 - I really appreciate you taking the time to put pd_mlr through its paces and for your clear feedback.

    re: CPU load meter - I grabbed a small patch that comes with pd as an example and I don't have a high level of confidence in its accuracy. I've seen it bounce over 100 on my dual-core 2.2GHz 4GB RAM machine without noticeable lag. Anyone know of a good patch for monitoring CPU load?

    re: pattern recorders - I was looking for a looper peddle like capability and that's one of the things that drove me to create this app.

    On the subject of the monome interface to the recorders, I struggled with this and tried a few different methods, and none of them made me happy. I am wide open to suggestions for how to do this better, knowing that having to hold a button for 1 second while performing could seem like an eternity. This time could be shortened, but what is needed is some way to differentiate between the command to record and the command to toggle play/stop. And then on top of that, some way to visually show when a recorder slot is ready to record, when it is play mode, when it is in stop mode with a loop stored. And I very much get the point about being stuck with a blinking LED once you have used a recorder slot.

    Suggestions for how to make button press and led interface for these pattern recorders better?

  • @egon77 - Also meant to ask for a bit more detail on your sync and multiout comments (I'm relatively new to all of this).

    I assume for sync you mean being able to receive an external beat and syncing pd_mlr beat with that, yes?

    And for multi-outs, is this a matter of being able to map individual mixer channels to different audio transport channels on my computer? For example, I am on a PC and use Virtual Audio Cable; so for me this sounds like mapping different mixer channels to different cables. How is this done generically in Pure Data so it works for everyone? @BoxieBrown? Anyone?

  • The multi-outs to a DAW would not be too difficult to implement. However, unfortunately with a lot of things related to Pd, it might not be the most straight forward to implement. The way I've done this in the past is to use Jack (http://jackaudio.org/), which is similar to Rewire. It's more flexible because it allows users to configure routings by hand, but this also can make it slightly more confusing.

    You can start Jack, then Pd and switch to using Jack as the default Audio. From there you can route to whatever DAW you want. Again, maybe not the most straightforward process. It does work really well once it's up and running.

    As for Midi Sync...ugh...I wish I had the answer to this. Everywhere I look I come up with only once solution. That is to use an object [midirealtimein], which supposedly only works on Windows. However, it will receive Midi clock on a Mac which I'm using. Though, I've had the worst time trying to actually use it and sync to an external device. I tried implement it in a monome app I made, but it was definitely not working.

    I'll keep poking around the interweb and maybe also the Pd Mailing List. I'd love to hear a solution if anyone else has one.

  • It is possible to use Pd as the master and have other devices sync from it. I have not tried it between applications on the same computer though.

  • @BoxieBrown - I use Virtual Audio Cable (VAC) the way I think you are using Jack. I have been successfully using pd_mlr with PD output set to VAC 1, and Ableton Live receiving that on its (ASIO4ALL's) input channels 1/2.

    I just tried adding a 2nd VAC, and I can see it as an input choice in Ableton/ASIO4ALL, but I am not sure how to route to it from PD. I set PD to have multiple output devices (VAC1, VAC2, etc.). The PD DAC~ object allows specification of output channels. This worked when DAC~ channels 1 & 2 were specified, but not for channels 3 & 4.

    @ ALL - still looking for ideas to improve the recorder button/led interface.

  • top! will check this out for def tonight and get some feeback up! nice one bro! been working loads recently in Pd, finding it easier than max tbh!

  • Hey Bongo, regarding the way to possibly do the pattern recorders: the number of states the recorders have is exactly the same as 64(videp)fingers and it could be an alternative for yours. The way it could work is, press the button to activate recording. Mash the buttons until it begins to automatically play back. The LED state switches to flashing. press the button once again and the pattern turns off and the LED state inverses. Press it once again and the pattern comes back on and LED inverses back to the way it was previously. A quick double tap at any time and the pattern recorder is cleared and the LED turns off.

    The way I did it in 64(video)fingers was once the flow ended up in that locked loop where the button acted as a toggle, pattern on/pattern off. I would also send a bang to open a gate as well as start a counter object which would quickly count up to 9. once it reached 10 it would bang and close that gate. If I were able to press the button quickly twice, the first bang would open the gate and the second would make it through the gate before the counter object closed it. Hope that makes sense.

  • @egon77 - i like your approach to pattern recorder interface, and will implement something like this soon (first, i must put some time into MCRP3!).

  • ok, while i should have been working on MCRP3 today, i put time into implementing @egon77's suggestion for pattern recorded interface. new version 0.4 attached to edited first post above. to use pattern recorders:
    - tap once to arm for recording, which starts with first button press
    - play begins automatically when specified recording length (in beats) is reached
    - tap once to pause; tap again to start playing again
    - tap twice quickly (

  • Hey Bongo, I was playing around with this app tonight and I noticed what might be a couple of idiosyncrasies.

    First thing I noticed was when you load a sample into a row and then change the tempo the speed of the samples don't adjust with it. I loaded in a sample thats set to 100bpm then adjusted the tempo to 100 and needed to reload the sample in order for it to display 1.0

    Second, with the choke groups. I had two samples of the same group loaded into row 1 and 2. When I would chop between these samples there appears to be a microsecond of mute before the sample triggers. This doesn't happen when chopping within the same row, only when you chop between samples in the same group.

    And one tiny feature request - I think it would be really super awesome if this version of mlr could have a couple of buttons in the top row for next and previous preset switching.

    I have to say that in my opinion this version of mlr has the quickest playability. I play with mlrV and its hard to get into rhythm with the quantizing. This one is rock solid and it's a breeze to really do some quick chopping. I also LOVE your pattern recorder options. I also love your auto load feature. It's too bad about the PD and midi sync inefficiencies.

    Anyways, well done. A well deserved bump as well for this thread. Let's get some people using this app!

  • Also I think my suggestion for the pattern recorder order of button presses may not be so hot because when you double tap it to clear you hear a quick snippet of the recording before it clears. Not sure of the answer yet but I'll think on it.

    As well I am noticing the microsecond of mute on the audio recording function of the pattern recorders. Mainly at the loop point of the recording.

  • Bump for Bongo

  • @egon77 - my apologies, but i missed this activity on this thread last week - it's been an exceptionally busy time recently at home (family illness) & work (reorganization at my university). i've got a couple of other things in my creative electronics queue (MCRP V4 submission and completing a more portable rig for my laser harp using an arduino), but will put some time into pd_mlr this weekend.

    - i believe the change of tempo issue was just an oversight on my part, and should be easy to remedy
    - i am guessing the "microsecond of mute" when chopping between rows has something to do with the way i am cross-fading. you specifically mention rows 1 and 2; does this happen with any group and any two rows?
    - please share a bit more about the "next and previous preset switching." i haven't used such a feature in other versions of mlr, so i could use a basic primer. is this just an ability to have a "playlist" of the sample set/preset files, and then be able to move through the list by pressing next/last buttons on the monome? what happens if such a button is pressed while samples are playing in the current set?
    - i am open to suggestion for a different button press interface for controlling the pattern recorders
    - i too have noticed a discontinuity at the loop point of the recording, and i think this has to do with two things: what could be a significant difference in the audio itself jumping from the end of the recording immediately to the beginning; and what may be a lag in pd when it reaches the end of the array holding the audio and triggers from the beginning again. i have thought about addressing this with what amounts to a cross-fade, but that will require two copies of the array and some additional processing... it's already on my to do list.

    peace, bongo

  • I'm just reading through this really quick before work, and I think I have a possible solution for the discontinuity issue.

    If I remember correctly tabread4~ needs 3 more samples at the end of the loop to interpolate the end of the table correctly. I don't mean just add 3 samples to what's in the table, just add 3 to the $1-sample-length which feeds into the *~ underneath the phasor~ in the sample playback section.

    @egon77 If you're happy with Pd as the master for midi sync, that's certainly a possibility.

  • Bongo! Thanks a bunch for replying. I completely understand. I don't expect anything I just really dig your version of MLR and while playing around with it I noticed a few things in regards to it. I really appreciate your tone on these forums, really helpful and always upbeat. Anyways, to answer your questions -

    - the microsecond of mute when chopping between groups - I'm not sure if it's happening between other groups or between rows other than 1 and 2. I will check that out today and get back to you.

    - Re: the preset switching. The way the preset switching works on other mlrs is that you switch presets and it changes the audio files in each row as well as their parameters (groups, forward/reverse, even tempo I think). If you have rows playing while you do the preset change they continue playing until you trigger the row again, then the new sample begins. Really helpful for complete changes in a song or for doing a longer set of songs you can switch over seamlessly. I'm not sure how it handles pattern recorders that are playing at the same time as the preset change. You'd think the pattern recorder would trigger the new sample. I'll have to check into that.

    - Re: the button config for pattern recorders: I'm not sure exactly, I just know that my first suggestion is flawed because of the double tap to clear. Perhaps the only way to do it is to have a second button that you hold first and then press the pattern recorder to clear. Or maybe go with what you had before except shorten the hold time to half a second. I'm bet that would still keep the action quick while keeping it simple. I'm not sure what the best suggestion is. There might be some other way but it's not coming to me.

    @Boxie - Using PD as the master is certainly a solution to a problem and Live doesn't always have to be the master clock. I'd give it a go and check it out.

    Anyways, Bongo, I appreciate your making this app and take this stuff on at your leisure. No matter when you make changes I'm sure to check them out when you do. I'm in the research process right now trying to make my own MLR from scratch with a focus on the live input recording function.

    All the best!

  • Okay, I think I figured something out. The microsecond of mute is there for all rows and groups but I think I know why. When I turn quantization to off there is no problem. When I turn quantization to 1/4 the mute happens for longer. So I think what's happening is that when you jump to another row of the same group it triggers the previous row to stop instantly while the next row waits that short quantized period to begin.

  • @egon77 hmmmm... curious. i will not have a chance to open up pd 'til saturday to check this out. if i remember correctly, i thought i had set up quantization to in effect hold any button press in a sample row until the next quantize beat comes around. to my cross-fade it should simply appear as if the button press comes later. your experience suggests this is not working that way. i'll check it out soon.

    thanks for your kind words earlier, and the interest you have taken in my pd_mlr work.

    btw, when you talk about creating your own mlr are you contemplating using pd for this? i would gladly see you borrowing whatever would be helpful from what i created.

  • No worries mate! I'm probably going to use max since I own a copy and I already have some experience with it. I'm sure it wouldn't take much to make the transition but I am heading down the path of least resistance at the moment.

  • Just coming from the mlr tut for pd.

    After that, I did a quick search with "puredata", and "pd" and I stumbled upon this thread.

    @bongo: Congratulations for your app, it seems very featureful and the gui is really nice, a lot of work here, knowing how pd is gui-friedly ;).

    [edit] What a doc too !! I'm impressed, really. :)[/edit]

    Glad to see some interest in puredata. That was not really the case when I started with the monome and puredata.

    Hopefuly there will be more apps :)

    Greetings all

  • @Bongo

    first off just want to say massive thanks for the time and effort you've put into this I'm quite new to the whole mlr thing and have been putting time into getting to grips with both versions (max and pd) but am going to pursue this version as i'm really excited about the possibilies off expanding it through different effects etc.

    On the functionality I find the pattern recorders work well with the current set up and don't find the double tapping an issue at all, some other features i'm planning on exploring are adding a routing matrix to the audio pattern recorders so that you can say choose to only record sample row1 and 2 (or any combination) into the audio recorder, I don't know if anyone else would find this usefull?

    edit: Was thinking of using the keyboard to trigger this i.e pressing buttons 1 to 7 switch on/off the rows being routed to the pattern recorder (i've only got a 64 so limited on buttons atm :D ), open to suggestions if peeps think this will be usefull?

    Also I'd like to add choke groups to the recorders so that when you trigger the next set of samples they cut out the recorded sequences and viceversa.

    As egon77 suggested being able to switch between presets while playing would be awesome.

    I'm quite new to PD so might be a while before I implement any of these things, was just wondering if there is a filing convention for people modifing the app so that people don't confused between versions?

  • @Spacolucia

    Thanks for your interest in pd_mlr. As it turns out, after not making any mod's to this for a few months, I just put some time in over the last few days to address some of the issues identified by @egon77:

    - changing master tempo or standard beats should change playback speed of all samples
    - the microsecond of mute when chopping between two different rows assigned to the same group was indeed a bug in the way I implemented cross-fading
    - the discontinuity when a recorded audio pattern loops results primarily from noticeable differences in the end and beginning of the audio sample. I am working on a cross-fade to address this.

    I plan to have these three things finished within the next couple of days, and then will post a new version to the 'documentation' section of this site.

    You may want to wait to do any modifications until I post the next version later this week.

    Thereafter, I was going to have a look at adding the capability to move to next or previous preset.

    I do not know what the filing/naming conventions are when new versions are created. For this particular app, I guess we first need to decide if the mod's you want to make should be part of pd_mlr itself, or if they should begin another branch. What do others who have been following this thread (boxie, egon et al) think of @Spacolucia's ideas?

  • @ Bongo

    You're the man, looking forward to the update!

    Having a look at the file "sequence_record_audio $1" I can see the "receive~ seq-left" and "receive~seq-right" but can't find the send objects for these, i thought they would be in "pd mlr_sample_play" any chance you can point me in the right direction?

    I was thinking of placing a set of sends and receives inbetween these from the different sample groups and toggling them on/off with the keys as outlined above - may be on the totally wrong track here though ...

  • @Spacolucia

    I'm at work, and my pd_mlr code is on a computer at home. I'll be back in touch tonight (EDT).

  • @Spacolucia

    The sends for audio for the sequence recorders come directly from the mixer. To get to these right click (PC) on the mixer on the main UI and select open. Alternatively, you could open the mixer subpatch directly in PD. It's located in the /lib/utility directory and is called mixer_8x1_stereo~.pd

  • @ Bongo

    Thanks for the help, will check it out!

  • I have posted the latest version of pd_mlr V0.5 as an attachment to the initial post in this thread. I will post to the documentation section of this monome site when I figure out how to do so.

    _pd_mlr_0.5 Release Notes

    Please address comments & questions to:
    Monome community pd_mlr discussion thread

    Fixed in this release:

    1) Added missing functionality - Changing master tempo or standard beats per sample now changes playback speed of all samples.

    2) Fixed bug where chopping between different sample rows assigned to the same group caused a brief discontinuity audible as click or silence - Now cross-fades correctly.

    3) Improved functionality of audio loop recorders - a) Implemented a cross-fade between end and beginning of loop; and b) Adjusted precise timing of loop record start/stop for better capture of what exactly what is heard while recording.

    4) Fixed bug where group stop was being sent to rows without samples loaded, causing clicks.

    5) Fixed bug where "stop all samples" did not always work.

    6) Added functionality to save sample play direction (forward/reverse) in saved set.

    Under consideration for future releases:

    1) Add functionality for next/previous preset settings, to make it easy to move between sample sets/settings directly from the monome during performance.

    2) Consider revising interface for sequence recorders, as current quick double press of button used to reset recorder can sometimes result in a brief bit of unwanted play of previously recorded loop.

  • hello bongo...

    was playing with this on a netbook, lenovo s10, ubuntu jaunty

    seeing a skipping of sample playback, pdextended is version 42-5

    I'll be checking to see about getting something loaded outside the
    ubuntu package system, but thought I'd check what version of pd people
    have used successfully to run the app.

    using serialpyio 4.1 for device connection


  • ok, think I found the problem.

    switched from oss (the default) to alsa

    seems better now. all under the pulse audio setup, still

  • @rawore - working now? i don't know linux, and pd_mlr was developed on a pc, by i think oss and alsa are sound drivers, yes?

  • No, there is also JACK (which is the best option on Linux so far).

  • I'll check out jack. not installed by default I think.

    left the setup running over night. top (performance monitor)
    showed cpu usage of 83% at the end (while idling). startup percentage was
    around 40%. dropped to that when restarted. this is a 1.2ghz
    chip. (just have one sample loaded, for tests, so far)

    pd doesn't seem to like some .wav file headers on this installation.
    they play ok with firefox. haven't poked at ubuntu audio, for a while.
    I'll have to check.

  • also, this pd version calls out OSCx as deprecated. suggests OSCroute by arpeach.

    says "load_object: Symbol "setup_for0x2b0x2b" not found"

  • @artfwo

    are you using a real time kernel in your setup?

  • @rawore, currently - no. I'm on Ubuntu Maverick, and the default Maverick kernel suits me well. You can try one of the kernels from this PPA:

    But you should definetly go for JACK. It is alot better than OSS/ALSA for all production tasks.

  • @artfwo I've used in in other systems. are you leaving pulse audio active when using jack?

  • well, I'm using JACK with an external Firewire audio interface, so I leave pulseaudio untouched.

    But when using JACK with ALSA backend, run it with pasuspender, QJackCtl program does this automatically for you.

  • ok, thanks...

    one last question... about using the ppa for a kernel.

    I just add the ppa and then look for the kernel name in
    synaptic package manager? (i've only used ppa method
    for applications).

  • Well, you add PPA with "add-apt-repository" then update package indices (either by running apt-get update or from Synaptic) and install the appropriate kernel package (linux-lowlatency, linux-realtime, etc.).

    Then reboot and select new kernel from GRUB (grub menu is toggled by tapping right SHIFT on system boot).

  • @bongo sorry for hijacking the thread, but maybe it would
    encourage other linux/pd activity.

    one thing I failed to note about the app...

    the active row is not echoing an led light for sample position.
    presses still work, and the top left switch lights when the row is
    active, operates to stop the sample playing.

    monome used is a greyscale 64.

  • @rawore - no problem. i would be psyched to see more linux/pd activity.

    i'm not home where my setup is, but last time i used pd_mlr a few weeks back, the leds were lighting correctly to show sample playback position. i wonder if this isn't working on linux because i used OSCx and not the Mr Peach OSCRoute. i've been meaning to update to use OSCRoute... and weng has recently posted PUMA (PUre data Monome Abstractions), including some standard objects for button presses and led control using the Mr Peach externals for OSC.

  • +1 for more linux/pd/monome activity. perhaps a tutorial on how to get the best setup for audio might be useful.

  • By the way, is it okay, that currently playing track doesn't get any led feedback at all?

    I press the button in 2nd row of my arduinome to begin playback, the group led lights in the topmost row, but no leds light in the 2nd row at all (but I see the playback cursor moving in pd_mlr screen).

    In other words, group and recording leds work, but track leds don't. At first, I thought that I'm doing something wrong, but now I got back to playing with pd_mlr and just cannot figure out how to light the feedback leds. Any hints?