set target-buffer on a record~ starts recording?!?!?!

    Mar 10 2012 | 10:04 pm
    as the title says..
    in max 6, when I use the "set" message on a record~ object, it immidiately starts a recording in that same buffer.
    this is extremely frustrating. does anyone know how to get around this?
    here's my patch:

    • Mar 11 2012 | 2:06 am
      this doesn't seem to happen for me when I used your patch. can you explain the exact steps that lead to this?Also comments on your patch to explain what it does are helpful
    • Jun 05 2012 | 11:03 am
      Hi Liam
      thank you for trying it out.. sorry for the late reply, but I've been far away from max. but now I'm back (with the same issue)...
      and I understand now that the patch I showed you was quite confusing to look at, SO:
      I've made a very simple patch showing the exact same problem.
      it should be very clear in this patch.. if not - you can mail me at
    • Jun 05 2012 | 1:28 pm
      what is it you are actually trying to do? I get kind of the same result as you do but then I also don't see the real point. Surely if you want multiple inputs you can just set the argument in ADC~ and you will have multiple out puts. When you change audio settings the audio will restart which is presumably why your buffer gets erased (but I'm not 100%). Also the (3 3) message to ADC~ i think doesn't do anything as your ADC~ only have two outputs.
    • Jun 05 2012 | 2:42 pm
      1. I want to be able to record stuff into several buffers in a flexible way without loosing the last recording I did.
      - I mean there's gotta be a way to avoid this.... or else multi-sampling for live use isn't going to work at all.
      2. I want to be able to change inputs without audio stopping
      regarding the adc outputs: if you click the 3 3 or 2 2 message boxes and afterwards hold your mouse over the adc outlets you will notice that it changes the inputs in theory.. but in practice it doesn't work obviously.
      This doesn't have anything to do with lack of outlets on the adc object.
      any kind of advise is very much appreciated
    • Jun 06 2012 | 1:02 am
      Ok so the loss of the last recorded buffer is weird I don't really understand why has to do that. It seems to happen whenever the audio is restarted, seemingly [record~] writes over the buffer. I think you can get around this behaviour by giving it a name of another buffer before you do anything that restarts the audio.
      As for the input changing I would just put all your input numbers as the arguments for [record~] and put a [selector~] underneath. You can then route those inputs to whatever you want without having to change the channels around and restart the audio in the process.
      Let me know if this helps