record~ then immediate play~?

Mar 15, 2006 at 2:43am

record~ then immediate play~?

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.

Thanks,
Dan

max v2;
#N vpatcher 129 153 465 454;
#P window setfont “Sans Serif” 9.;
#P newex 39 111 58 196617 metro 250;
#P user ezdac~ 24 221 68 254 0;
#P button 157 43 15 0;
#P message 39 143 62 196617 0 , 100 100;
#P newex 39 162 30 196617 line~;
#P newex 39 185 76 196617 play~ my_buff;
#P message 234 119 14 196617 1;
#P newex 151 220 112 196617 buffer~ my_buff 5000;
#P newex 205 178 87 196617 record~ my_buff;
#P message 176 115 43 196617 loop $1;
#P message 131 114 30 196617 open;
#P toggle 165 90 15 0;
#N sfplay~ 1 120960 0 ;
#P newobj 157 140 44 196617 sfplay~;
#P connect 7 0 11 0;
#P connect 10 0 12 0;
#P connect 12 0 9 0;
#P connect 9 0 8 0;
#P connect 8 0 7 0;
#P connect 7 0 11 1;
#P connect 2 0 0 0;
#P connect 3 0 0 0;
#P connect 1 0 0 0;
#P connect 1 0 3 0;
#P connect 6 0 4 0;
#P connect 0 0 4 0;
#P connect 10 0 6 0;
#P pop;


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

http://www.jackosx.com

#24899
Mar 15, 2006 at 6:58am

Hi Dan,

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.

Ben

#72623
Mar 15, 2006 at 12:47pm

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.

Thanks, will definitely try with index~ as well.

Very much appreciated info!
Dan


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

http://www.jackosx.com

#72624

You must be logged in to reply to this topic.