record~ then immediate play~?


    Mar 15 2006 | 2:43 am
    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;
    --
    Dan Nigrin
    Defective Records
    202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
    http://www.defectiverecords.com

    • Mar 15 2006 | 6:58 am
      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
    • Mar 15 2006 | 12:47 pm
      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