Forums > MaxMSP

Any alternative routine to buffer~ write wave/aiff?

May 3, 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 8, 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 8, 2013 | 10:37 pm

what’s wrong with buffer? post a patch.


May 8, 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 8, 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 8, 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.

`

– Pasted Max Patch, click to expand. –

May 9, 2013 | 12:39 am

yes you’re right! I can reproduce under OS X 10.8.2
Please, send a report to cycling.


May 9, 2013 | 12:48 am

6.1.2 too?
I already did. They said they know about it, that’s encouraging.


May 9, 2013 | 7:25 am

as quatro said the problem is known..

http://cycling74.com/forums/topic.php?id=46355

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 9, 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.

http://cycling74.com/forums/topic.php?id=45998

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.


February 18, 2014 | 9:02 am

an alternative would be to automatically delete the local file before saving the audio buffer file. anyone knows how to do it?…


Viewing 13 posts - 1 through 13 (of 13 total)