After experimenting with several off-the-shelf phrase loopers that
never do exactly what I want, I decided to just build one that does.
I thought it would be fairly trivial but have run into problems. I
started with tapin~/tapout~ (out wrapped back into in with gain
control for regeneration) which works fine for a very limited set of
features. But I also want to be able to do things that groove~ can
do, like pitch shift, play in reverse, change the delay time on the
fly etc. I setup a buffer and a record~/groove~ pair to implement
the delay with regeneration, and then I have a separate groove object
pointed at the same buffer for the audio output which I can run at
various speeds and reverse without tweaking out the regen cycle.
This works conceptually, but within a few seconds the loop in the
buffer becomes filled with clicks. This didn’t happen with tapin~/
tapout~. Have I made a conceptual error? What I want I suppose is
something that does what tapin~/tapout~ does in terms of smooth loop
recording, but with groove~style access to the buffer.
thanks for any hints,
This might have something to do with the fact, that the record~ object dosen’t stream audio, but records in a loop….. This will generate clicks when the record and playback point are the same…..
I think the stutter~ object does exatly what u want… it keeps a history of the incomming audio stream, and is able to copy snippets of it to a playback buffer~ …. the buffer can then be phased thru…
On 1 mars 06, at 08:33, Darren Gibbs wrote:
> I setup a buffer and a record~/groove~ pair to implement the delay
> with regeneration, and then I have a separate groove object pointed at
> the same buffer for the audio output which I can run at various speeds
> and reverse without tweaking out the regen cycle. This works
> conceptually, but within a few seconds the loop in the buffer becomes
> filled with clicks.
You can’t record and play a same buffer at the same time, i.e position
in the buffer. If the read and write position are crossing, you may get
a click recorded in the buffer. You could use 2 buffers instaead and
swap, or do some logic to avoid these conflicts (which can become quite
tricky if the read speed is changing during time).
Beside of that, when you record new material in a buffer, you erase the
previous content, so you’ll also get a clik. There are a couple of
objects that may be usefull for you: xrecord~ and co, by Thomas Grill.
(see maxobjects.com for a pointer)
Centre de Recherches et de Formation Musicales de Wallonie asbl
Darren Gibbs wrote:
> This works conceptually, but within a few seconds the loop in the
> buffer becomes filled with clicks. This didn’t happen with tapin~/
> tapout~. Have I made a conceptual error?
Probably, without seeing a stripped down example which exhibits the
behaviour its hard to tell.
By the way stripping down such a thing usually points you directly to
the problem and you might find out yourself.
If you find the culprit do not hesitate to post the solution as well
(others might have similar problems and will be happy to go the same route)
   
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-49 77 51 72