Any alternative routine to buffer~ write wave/aiff?


    May 03 2013 | 8:39 pm
    Is there one? I've recently found that buffer~ write is terribly broken in the latest Max. I can't say how long the bug have been there, and I just don't want the patch to rely on this.
    I would consider an external that can do arbitrary binary write if it is cross-platform and x64.

    • May 08 2013 | 10:29 pm
      That's just amazing there is none.
      I guess I should stick with ugly sfrecord~ fallback until buffer~ would be fixed. But how can I detect Max version from within the patch to disable the fallback then?
    • May 08 2013 | 10:37 pm
      what's wrong with buffer? post a patch.
    • May 08 2013 | 10:44 pm
      In brief, buffer~ "write" appends the existing audio file instead of overwriting it, and forces the written files to be 24 bit. It is a reported and known issue.
    • May 08 2013 | 10:58 pm
      not sure if I have understood your problem:
      "Is there one? I've recently found that buffer~ write is terribly broken in the latest Max. I can't say how long the bug have been there, and I just don't want the patch to rely on this."
      what bug? explain your issue properly.
      "In brief, buffer~ "write" appends the existing audio file instead of overwriting it, and forces the written files to be 24 bit. It is a reported and known issue."
      you can overwrite files with the same path and file name. use the format message to define the bit rate.
    • May 08 2013 | 11:13 pm
      you can overwrite files with the same path and file name. use the format message to define the bit rate.
      Surely it behaves as I stated (file appending instead of overwriting, always 24 bit) exactly under these conditions. Was tested with latest x64 Max on Windows. Take a look if you're interested if it is reproducible on your system.
      `
    • May 09 2013 | 12:39 am
      yes you're right! I can reproduce under OS X 10.8.2
      Please, send a report to cycling.
    • May 09 2013 | 12:48 am
      6.1.2 too?
      I already did. They said they know about it, that's encouraging.
    • May 09 2013 | 7:25 am
      as quatro said the problem is known..
      unfortunatelly as you can see Ben Bracken says
      "There are a number of differences that have cropped up in Max 6,
      and although I can't say when or if we will have fixes for them,
      we are going to be taking a closer look in the near future."
      i am the only one who believes that max is "buffer-based?"
    • May 09 2013 | 9:15 am
      no, tad a, you are not the only one.
      I am lamenting that the 'read audio from qt.movies' is broken in Max 6.
      slick stretching patch cords replacing basic functionality ...
    • May 10 2013 | 12:17 am
      I think this the case of a 64-bit application and a limited 64-bit Quicktime implementation. (the qt.movie problem) Maybe it goes away if you run in 32-bit mode?
    • May 11 2013 | 4:28 am
      For those who may need the answer some day, I will most likely settle with JS file write. And the version can be checked as easy as ;max getversion receiveobjectname message.
    • Feb 18 2014 | 5:02 pm
      an alternative would be to automatically delete the local file before saving the audio buffer file. anyone knows how to do it?...