live looping

    Apr 17 2006 | 10:48 pm
    i want to be able to trigger live recordings and loop them. i have looked into using sfrecord~, but i cant seem to get it do record in anything other than sd2 format(using the autonaming message, as i dont want to have to name my file on the fly), which is no good for an external i am using.
    using the record~, buffer~ method i cannot seem to work out how to set it up so that the audio will self-trim according to the record time, and thus loop proporly
    can any one help?

    • Apr 17 2006 | 11:28 pm
      1. holy moly, please read the manual. you can search those PDFs, you don't have to memorize it. the thesaurus at the end of the reference can be valuable too.
      2. read the sfrecord~ help file (again?).
      3. check the examples, isn't there one that covers this?
      4. i made a lousy little app last year to record continuously and save the last n seconds on demand... for those times when you're goofing around but want to be able to save the 'genius' moments that won't happen again. probably easy to repurpose, it's very simple. click the bottom-right toggle to browse the patch.
      5. seriously. i get the impression you're working toward an ulcer, but if you take even 20 minutes and read carefully you'll save yourself some time tomorrow and every day after that. you have, uh, some of my sympathy.
    • Apr 18 2006 | 12:03 am
      Have you tried looking on some sites to see if someone's all ready done what you want to do?
      I'm new to Max/Msp myself, and so I'm probably replicating work that other people have done in an effort to learn things, it's just how I like to work-- but I'm not under any pressure from anyone to get anything done (except from my bandmate, and, since we're not making a living by playing music, even he's not all that worried about it), but there are oodles of sites out there where people have shared their patches:
    • Apr 18 2006 | 12:08 am
      i just thought this is the kind of thing someone would have already done
      i have, and will continue to search all reference media, i am not just here for easy answers
    • Apr 18 2006 | 12:54 am
      The fact that your signature apologizes for you sort of cheapens both the apology and anything in the content of your messages.
      This list already has WAY too many messages per day for me to pay attention to most of them anyhow, your insistence on asking questions that you know may be easy will paradoxically lead to a lesser chance that your questions are actually answered. We all understand that you have a deadline, but realize that we too have deadlines... only we're working on stuff that's not what you're working on.
    • Apr 18 2006 | 1:00 am
      John wrote: > i just thought this is the kind of thing someone would have already > done
      yes, understood. the patch i pointed you to should help you with the buffer~ stuff. you can use very similar concepts to create a looper. it's not as bad as it might look... most of the patch is just handling the file operations! (it writes wave, btw, just uses a timestamp for the filename.) the key elements are record~ and its sync output, modulo (%), and a couple of buffer~s.
      on the other hand, the previous post might be better advice: there are many, many people working with max that are much, much smarter and more skilled than me, and a bunch of them share openly.
      and these might come in handy for you if sampling is your thing and externals are ok:
    • Apr 18 2006 | 8:30 am
      Hi. I've been doing some live looping with Max, so I may be able to shed some light on this for you. First, I need to say that it is a bit heavy to see that other members spend more time insulting someone than helping them (the other replies...) but to each his own.
      Lately, I've been using the stutter object to loop. This is for two reasons; first, because stutter is always recording, whether you need it or not. This enables me to decide after the fact if I want to use something. Second, stutter records into a RAM buffer, making it inherently faster and more manageable than an object which writes to disk. (I must qualify this; a few months ago I set up a sort of Sampler which uses 20 sfplay objects to give a 20-voice sampler, and I didn't hear any difference in performance. Theoretically, at least, there should be a difference.) With stutter, I can use a switch (in my case a footswitch) to start and end the recording I want to loop. (I sometimes use a audio-threshold switch instead, which records each phrase automatically.) What this switch does is to start a timer (to measure the increasing length of the material I am presently recording) and, when I lift my foot again, it stops the timer, sends the number of samples between starting and stopping the recording to the object, and sends the bang to stutter which causes the record buffer to send the information from the last x samples into the playback buffer. I then can manipulate the signal from a phasor object in order to get the playback I want.
      The next step I need to try is synchronizing multiple stutter objects (I simply haven't needed this yet), but this shouldn't pose any problems if the phasor objects are organized well.
      In my experience, this approach is the best way to loop live input. Using the buffer object with groove (here in Spain, there is no tilde on the keyboard and I don't know the ASCII code, so I am not including them...) I managed to do almost the same thing, but there is a drawback in that the buffer object needs a fixed length when it is created, and this means that in order to loop it, you need to keep track of the length you want to use. That proves to be a bit lurchy in practice. Using soundfiles gives the (at least theoretical) lag of disk-operations.
      On the musical side of things: it is often adviseable to quantize the length of the loop so that it fits whatever else you are doing at the same time. This can be done with a simple algorhythm which lengthens or shortens the timer-data to a configurable value, or, more usefull, an algorhythm which quantizes the start and end signals produced by the switch. In the sort of work I do, I have two modes; one which quantizes the in and out points in relation to a BPM value, and another which uses the first loop as the basic length, and proportions the other loops to be even fractions or multiples of that loop.
      What can one do with this? I use it for various things, but when I am using it for performing, I have routines for dynamically changing the length (by varying the phasor values) and the pitch (using gizmo objects) of the loops. I also have another stutter object set up to loop the complete output in order to have a cumulative effect. This allows me to use effects with the voice (and other instruments) which are of suprising scope and variety.
      The only drawback I can imagine to this approach is the predefined length of the recording buffer in the stutter object. Objectively, however, this never plays a role. It is extremely seldom that I may want more than the 10-second buffer I customarily use, and if I do, my 1GB of RAM can give me plenty of headroom; enough for a couple of hours, I expect.
      Hope this has helped.
    • Apr 18 2006 | 1:02 pm
      been reading the help file for stutter, cant quite figure out how to send the recording to a buffer~, any clues?
    • Apr 18 2006 | 1:48 pm
      click on [p additional_messages] and you will see it right there -
      [setbuf ]
    • Apr 18 2006 | 1:56 pm
      I see, duh!! homer moment!!
      just to clarify, am i right in thinking that the corresponding buffer object needs no set time, or do i need to route the length of the sample to the buffer BEFORE sending the file?
    • Apr 18 2006 | 2:37 pm
      not necessary
    • Apr 18 2006 | 4:51 pm
      I see now in rechecking the mail that some unclarity can arise from the use of the word "buffer".
      Stutter is organized into two buffers. One is like the "tapin" object which just keeps writing into its own space, keeping track of the last x samples as a sort of moving window. That is the "record buffer". The other is the "playback buffer", which is also internal; this is what you are resizing when you send the timer information to the stutter object. In the patch I am using, there is no external buffer, even though stutter has a command to send the recording to one. Instead, I just use as many stutters as I need to get the job done.
      I will post the patch, but cannot now because it is in another machine in another place.
      Have fun, Dayton
    • Apr 19 2006 | 12:44 am
      that would be great, cheers
    • Apr 19 2006 | 4:39 am
      I'm looking for the same thing...! I've spent all night with buffer~...I'm trying to figure out how to extend buffer~ to record more than a few seconds although this may not be ideal, but I can't seem to figure it out...
      I'm on board the curious train.
    • Apr 19 2006 | 2:25 pm
      what i have so far
      i have built a solution of sorts, but somethings dont work
      for this solutions you will need the following object one of your external folders
      save it as clocker_plus (quite useful, if you look inside i have left some hints)
    • Apr 19 2006 | 2:27 pm
      once you have that so you can load it as an object, try this
      i have used a buffer, instead of an adc~ so as to save you from having to mess with a microphone during testing
      it seems to work, although the waveform~ (blue box) and the info~ dont seem to update properly. I think my ordering is okay, maybe you can see the flaw
    • Apr 19 2006 | 10:00 pm
      weird. The "clocker_plus" works fine, but when I open the other ONLY opens as a text file? it won't build into a patch...are you sure you copied it right? If you can maybe test it, then re-post I'd REALLY appreciate it.
    • Apr 19 2006 | 10:18 pm
      damon, try pasting text DIRECTLY into the patcher window, i assume you are pasting into the text view
    • Apr 19 2006 | 11:50 pm
      amazing! I didn't know you could do that! I've been using Max/MSP on/off for a few years, and yet I'm still very much an amateur. one thing I see off the bat is the prepend --> size --> buffer~ chain you got going on...I don't think that works, but I'm not completely sure...I haven't even tried this beast yet so I shouldn't jump the gun...however, I think that if you give the buffer~ a size argument of -1 is automatically resizes to whatever you load in...this might be more effective... ok now I'm going to actually try it out... Thank you very much, by the way...
    • Apr 20 2006 | 12:22 am
      your absolutely right, the size thingy doesnt work, it should all be in one object [prepend size], rather than prepend routing to size $1.
      heres the update. it has a problem tho, for some reason you cant make a second loop bigger than the first one?!?!
    • Apr 20 2006 | 1:16 am
      I'm not sure if this is going to help you in your cause..., but its helping mine...check it out...its basic, but I'm going to extend it to have longer recording times and more .aiff's...
    • Apr 20 2006 | 1:23 am
      i can see what your doing
      i'm trying to create something that will allow me to loop straight away.
      i.e start a loop on vocals or guitar or any external input. record a loop, and as soon as its done, the loop seemlessly begins so you can manipulate it in other patchs
      hense building a layered performance, like a one man max band
    • Apr 20 2006 | 1:51 am
      >i.e start a loop on vocals or guitar or any external input. record >a loop, and as soon as its done, the loop seemlessly begins so you >can manipulate it in other patchs
      nothing too elaborate , you can just build on it :
    • Apr 20 2006 | 2:00 am
      that seems to work great
      i am a bit of a newbie, could you talk me through it a little?
    • Apr 20 2006 | 2:20 am
      right, i get it a little better now.
      i does still, however pose the problem of a defined recording length, by the looks of things i'm just gunna have to deal with that
      but surely not?
    • Apr 20 2006 | 10:10 am
      Found a thing called loopexp in my patches, which looks like the sort of thing you're after.It uses Thomas Grill's xsample objects (see Searching for 'loopexp' with John Hudak's indespensible C74 Archive search ( - bookmark it now! ) got me this: ml
      Seriously, that archive search link will save you a lot of RTFM's - there's several years of Max related wisdom there, whereas this forum is still only a few months old cheers Roger