88mph

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

live-looping

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 

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 

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.

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.

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.


Have you tried looking on some sites to see if someone's all ready done what

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:

https://cycling74.com/twiki/bin/view/ResourceGuide

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:

https://cycling74.com/twiki/bin/view/ResourceGuide can get you started.

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

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.

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.

> i just thought this is the kind of thing someone would have already

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 

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 

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:

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.

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.

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.

been reading the help file for stutter, cant quite figure out how to send the recording to a buffer~, any clues?

click on [p additional_messages] and you will see it right there -

http://www.ruccas.org/index.php?Michael%20Duffy

--
Michael Duffy
http://www.ruccas.org/index.php?Michael%20Duffy


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?

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.

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'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 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)

for this solutions you will need the following object one of your  external folders

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

weird. The "clocker_plus" works fine, but when I open the other patch...it 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.

weird.  The "clocker_plus" works fine, but when I open the other patch...it 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.


damon, try pasting text DIRECTLY into the patcher window, i assume you are pasting into the text view

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...

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...


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?!?!

your absolutely right, the size thingy doesnt work, it should all be in one object  [prepend size], rather than prepend routing to size $1.

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...

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

i'm trying to create something that will allow me to loop straight away. 

hense building a layered performance, like a one man max band


>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 :

i am a bit of a newbie, could you talk me through it a little?

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

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 maxobjects.com).

Searching for 'loopexp' with John Hudak's indespensible C74 Archive search ( 

http://homepage.mac.com/johnhudak/google.html

http://www.synthesisters.com/hypermail/max-msp/Sep03/6479.ht

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

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 maxobjects.com).
 Searching for 'loopexp' with John Hudak's indespensible C74 Archive search ( http://homepage.mac.com/johnhudak/google.html - bookmark it now! ) got me this:  http://www.synthesisters.com/hypermail/max-msp/Sep03/6479.ht 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
