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
    -- Dan Nigrin Defective Records 202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X http://www.defectiverecords.com http://www.jackosx.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 http://www.jackosx.com