Anthony H

This is what i'm trying to do: create a patch that will loop a period (currently i'm working with 8000ms) of live input audio continuously, and allow you to add new audio into that loop.

essentially, it's a loop station, like the Boss stompbox unit.

Eventually i'd like to extend it so that one can have several independent audio loops.

has anyone else worked on a similar project?

I'm using record~ and buffer~ to create and hold the 8000ms of audio. I then send index~ to dac~ (so you can hear the sample) and also send it to the original record~/buffer~ objects.

Are tapin~ and tapout~ better options than record~/buffer~/index~?

With looping back, I need to avoid a constant incrementation (feedback) and adding new audio which will quickly push the signal over the dac~ limit, so I've use normalize~ objects. Is there a better way?

Even with the normalize function, I am experiencing some clipping, especially on lower end frequencies. I'm not 100% clear on attentuation methods, and sometimes confuse myself =) is there some comprehensive online resource that'd help me understand how to keep all my sounds within the 1 -> -1 limit without destroying the dynamics in the audio? ie. the louds are still loud, softs are still soft...i suppose it would be a compressor of sorts? I've never encountered such clip sensitivity in any other audio software; it frightens me how quickly i'm hitting the limit of the dac~!!

i posted another query a few days ago re. my soundcard...i'm experiencing a getclocksource error on the ASIO 2.0 driver... how will this affect me? am i running without a clock now??

lots of stuff here, i suppose. many thanks for any assistance!

This is what i'm trying to do: create a patch that will loop a period (currently i'm working with 8000ms) of live input audio continuously, and allow you to add new audio into that loop.
essentially, it's a loop station, like the Boss stompbox unit.
Eventually i'd like to extend it so that one can have several independent audio loops.
has anyone else worked on a similar project?

audio-looping-help-please

On 20 Feb, 2006, at 13:21, Anthony H wrote:

> Are tapin~ and tapout~ better options than record~/buffer~/index~?

Advantages and disadvantages, but easy to try and see if it works 

better for you. Simply feed the output of tapout~ through a gain 

control and back to the input of tapin~. If you also have a gain 

control on the input and also the output you can control levels quite 

finely with a bit of practise. You can also do things like set feddback 

gain to 1. and shutoff the input, which gives you an infinite sustain 

The disadvantage is that you can't retrigger the start of a sample, but 

you can never play across the recording point (causing a click) and it 

> With looping back, I need to avoid a constant incrementation 

> (feedback) and adding new audio which will quickly push the signal 

> over the dac~ limit, so I've use normalize~ objects. Is there a better 

You can control this sort of system pretty well, but a normalise~ at 

Lawrence Casserley - lawrence@lcasserley.co.uk

Lawrence Electronic Operations - www.lcasserley.co.uk

Colourscape Music Festivals - www.colourscape.org.uk

> Here are the questions:
>
> Are tapin~ and tapout~ better options than record~/buffer~/index~?

Advantages and disadvantages, but easy to try and see if it works 
better for you. Simply feed the output of tapout~ through a gain 
control and back to the input of tapin~. If you also have a gain 
control on the input and also the output you can control levels quite 
finely with a bit of practise. You can also do things like set feddback 
gain to 1. and shutoff the input, which gives you an infinite sustain 
of the recorded material.

The disadvantage is that you can't retrigger the start of a sample, but 
you can never play across the recording point (causing a click) and it 
is very simple to set up.
>
> With looping back, I need to avoid a constant incrementation 
> (feedback) and adding new audio which will quickly push the signal 
> over the dac~ limit, so I've use normalize~ objects. Is there a better 
> way?
>
You can control this sort of system pretty well, but a normalise~ at 
the end may be a smart precaution.

Lawrence Casserley - lawrence@lcasserley.co.uk
Lawrence Electronic Operations - www.lcasserley.co.uk
Colourscape Music Festivals - www.colourscape.org.uk


For simple things, I'd use tapin~/tapout~ (note the freeze 0/1 

messages that tapin~ accepts), but you probably want a buffer~ - based 

Couple of other things that may be useful:

Record~ outputs a 0-1 ramp as it's recording. Good for syncing up 

envelopes using trapezoid~. (note that it won't work to connect to use 

it on itself, but you could do it in a loop if you use a send~/receive~ 

I'd use a buffer~ bigger than the amount of time you want to record. 

That way you can use append mode, and/or store several different 

passes. Instead of destructively mixing them, you could just play 2 or 

more at once. (also nice, because you can remove things) (though you 

may prefer doing it the other way for different reasons) Also, some 

sort of double-buffering might provide additional mixing security.

Unless you really need the CPU efficiency, groove~ will probably be 

more interesting to work with, and will let you set variable loop 

times, etc. Notice that it also has a very handy 0-1 sync signal 

I generally stay away from normalize~ when I'm working with live 

signals. (though it's great for synthetic signals) If the first thing 

you play into normalize~ is really soft, then you play something loud, 

they're going to (theoretically) be the same volume.

(there's plenty of ways around this, such as doing a calibration of it 

by feeding it the maximum predictable level of loudness, but performers 

often underestimate when you ask them to play their loudest note)

I think the surest solution is to manage your gain levels in the 

decibel domain. Give yourself at least 12 dB of headroom (use dbtoa to 

provide gain coeffs. to *~) and maybe even a bit more. Consider using 

a limiter (or compressor) at the input and output stages. (omx.comp~ 

For simple things, I'd use tapin~/tapout~  (note the freeze 0/1 
messages that tapin~ accepts), but you probably want a buffer~ - based 
solution for this.

Record~ outputs a 0-1 ramp as it's recording.  Good for syncing up 
envelopes using trapezoid~.  (note that it won't work to connect to use 
it on itself, but you could do it in a loop if you use a send~/receive~ 
pair to connect the two.)

I'd use a buffer~ bigger than the amount of time you want to record.  
That way you can use append mode, and/or store several different 
passes.  Instead of destructively mixing them, you could just play 2 or 
more at once.  (also nice, because you can remove things)  (though you 
may prefer doing it the other way for different reasons)  Also, some 
sort of double-buffering might provide additional mixing security.

Unless you really need the CPU efficiency, groove~ will probably be 
more interesting to work with, and will let you set variable loop 
times, etc.  Notice that it also has a very handy 0-1 sync signal 
that's good for driving envelopes.

I generally stay away from normalize~ when I'm working with live 
signals.  (though it's great for synthetic signals)  If the first thing 
you play into normalize~ is really soft, then you play something loud, 
they're going to (theoretically) be the same volume.
  (there's plenty of ways around this, such as doing a calibration of it 
by feeding it the maximum predictable level of loudness, but performers 
often underestimate when you ask them to play their loudest note)

I think the surest solution is to manage your gain levels in the 
decibel domain.  Give yourself at least 12 dB of headroom (use dbtoa to 
provide gain coeffs. to *~)  and maybe even a bit more.  Consider using 
a limiter (or compressor) at the input and output stages.  (omx.comp~ 
or omx.peaklim~ for instance)

audio looping, help please!