max 6.1.2 message error 'jsoundfile_writefloats'
Hi everybody,
Trying to write buffer files in a path, in max 6.1.2, I've got this message :
"
buffer~: could not create file: soundEx
jsoundfile_writefloats: could not create output stream. check permissions of output directory.
"
Doing the same thing on Max 5 it works normally.. Somebody can help me?
Thanks a lot,
daniele 'piedone'
same problem here, have you found a solution?
Bump! Same problem!
Have you checked writing permissions for your the directory you try to write to (just as the message says)?
Sorry, Finally I solved this problem some time ago and I forgot to post the solution. Now I forgot how. I don't think it was with a writing permissions problem (max 5 did it well in the same directories). If someone still have this problem just telle me, I'll look faster..
Hi Daniele,
I am having this problem. Any idea what the fix is?
Further information:
Mac osx lion 10.7.5
Max 6.1.7
I can save contents of a buffer if saving manually, ie, sending it message {write} and then using the file browser dialog to name and set location of file. But I can't automatically save anything with pre-configured names. That is, the message {writewave XYZ} (or any of the other filetypes for that matter) does not work and returns error as in the OP.
Cheers,
Joe
Yes, this actually worked also for me.
if it still doesn't work, write back, we'll try something other.
This problem also today:
write or writewave etc. with a filename, with full filepath or not: does not work
write or writewave without filename to open search window: works
but how to capture the new created filename after that?
The issue seems caused by space characters in the full file path (like "MacIntosh HD")
Now it works in inserting a tosymbol object before the (write $1) message.
Maybe useful for somebody.
There are a couple of abiding problems with a variety of Max objects that access the file system: spaces and "special" delimiter characters (slash, colon, backslash, and so on).
Not all objects accessing the file system exhibit exactly the same problems, and AFAICR this is the first time the space character has caused a problem (slash on the other hand, which seems so appropriate in a "Max/MSP" directory, has caused untold difficulty).
Space has been a legal character in Mac OS file systems since about five years before the first Max implementation, so you'd think it wouldn't be a problem any more. But apparently it is. The slash ("/") has also been legal for ever, except it needs some special handling on Unix-based file systems (and probably also on Windows). I know this can be pain when writing externals, but it would be nice if the user could simply use OS naming rules without worrying about little oddities required by various Max externals.
Still, probably worth mentioning on this thread that there multiple file-system path naming idiosyncrasies that are waiting to bite you where it hurts.
To precise my preceeding post, I mean that one needs to insert [tosymbol] before (write $1) if the $1 filepath string includes some 'spaces'. With this precaution, 'spaces' bring no more problem. Confusing because the printing is identical with or without [tosymbol].
More confusing, strange, and seemmly a bug: if the file already exists and is to be replaced, the [tosymbol] is not necessary, but if the (write $1) tries to create a new file without converting the $1 string into a symbol, the error message comes.