Dan Nigrin

I am recording some realtime audio into a buffer~ using record~.

I'd like to then immediately (or as quickly as possible) begin to 

repeatedly trigger the beginning of that buffer, using metro and 

play~. It seems as though this does not work reliably though for the 

first cycle of the metro. I seem to remember some discussion on the 

list in the past about how one accomplishes this "record~ then 

immediate play~" kind of thing. Any suggestions?

The attached example gives you an idea of what I am trying to do, 

albeit with a soundfile rather than real time input.

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X

I'd like to then immediately (or as quickly as possible) begin to 
repeatedly trigger the beginning of that buffer, using metro and 
play~.  It seems as though this does not work reliably though for the 
first cycle of the metro. I seem to remember some discussion on the 
list in the past about how one accomplishes this "record~ then 
immediate play~" kind of thing.  Any suggestions?

The attached example gives you an idea of what I am trying to do, 
albeit with a soundfile rather than real time input.

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com
http://www.jackosx.com


record-then-immediate-play

The problem you've encountered has a pretty subtle cause. The record~

object and the play object may like they're simultaneously writing to

and reading from the buffer~, but in fact in the dsp chain the play~

object is doing its calculations BEFORE the record~ object. So the

play~ object is reading the data from buffer~ before the new recorded

In general there is only one way to guarantee that object B comes

after object A in the signal processing chain: that's to connect a

signal patch cord from the output of object A to the input of object

B. In your example you actually can do this: simply connect the

outlet of record~, which outputs sample position within the buffer~,

to a *~ object with an argument of zero, and then connect this to the

input of play~ - adding zero to the input won't affect the sample

If you do this fix you'll probably notice that the resulting sound is

kind of messed up for the first bang. I think this is because of

play~'s interpolation - it's looking ahead to samples that haven't

been written yet at the end of the signal vector. Try using index~

The problem you've encountered has a pretty subtle cause.  The record~
object and the play object may like they're simultaneously writing to
and reading from the buffer~, but in fact in the dsp chain the play~
object is doing its calculations BEFORE the record~ object.  So the
play~ object is reading the data from buffer~ before the new recorded
data is written into it.

In general there is only one way to guarantee that object B comes
after object A in the signal processing chain: that's to connect a
signal patch cord from the output of object A to the input of object
B.  In your example you actually can do this: simply connect the
outlet of record~, which outputs sample position within the buffer~,
to a *~ object with an argument of zero, and then connect this to the
input of play~ - adding zero to the input won't affect the sample
playback position.

If you do this fix you'll probably notice that the resulting sound is
kind of messed up for the first bang.  I think this is because of
play~'s interpolation - it's looking ahead to samples that haven't
been written yet at the end of the signal vector.  Try using index~
instead.

Thanks Ben! Now that you mention this, I remember reading this exact 

thing in the Pluggo Dev docs a long time ago - yup, there it is, on 

"There are a number of solutions to this problem. The one we adopted 

path from the input to the output along with a gain control. This was 

effect more useful as an insert effect anyway, and it caused the 

network by the signal compiler, since there was no longer an 

discontinuous "pieces" of the network should be ordered first."

What I didn't realize is that the same concept applied in Max/MSP 

>If you do this fix you'll probably notice that the resulting sound is

>kind of messed up for the first bang. I think this is because of

>play~'s interpolation - it's looking ahead to samples that haven't

>been written yet at the end of the signal vector. Try using index~

Thanks, will definitely try with index~ as well.

Thanks Ben!  Now that you mention this, I remember reading this exact 
thing in the Pluggo Dev docs a long time ago - yup, there it is, on 
pages 57-58 of the Pluggo Dev manual:

"There are a number of solutions to this problem. The one we adopted 
was to add a direct signal
path from the input to the output along with a gain control. This was 
needed to the make the
effect more useful as an insert effect anyway, and it caused the 
proper sorting of the DSP
network by the signal compiler, since there was no longer an 
ambiguity about which of two
discontinuous "pieces" of the network should be ordered first."

What I didn't realize is that the same concept applied in Max/MSP 
itself, rather than just in Pluggos...

>If you do this fix you'll probably notice that the resulting sound is
>kind of messed up for the first bang.  I think this is because of
>play~'s interpolation - it's looking ahead to samples that haven't
>been written yet at the end of the signal vector.  Try using index~
>instead.

record~ then immediate play~?