max 6.1.2 message error 'jsoundfile_writefloats'

    Aug 15 2013 | 6:22 pm
    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'

    • Feb 15 2014 | 2:26 am
      same problem here, have you found a solution?
    • Feb 18 2014 | 6:00 pm
      Bump! Same problem!
    • Feb 19 2014 | 3:44 pm
      Have you checked writing permissions for your the directory you try to write to (just as the message says)?
    • Feb 19 2014 | 4:29 pm
      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..
    • May 25 2014 | 3:23 am
      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.
    • May 25 2014 | 8:24 am
      Using the full filepath name as per MAAACHSEVEN's advice here: works fine. Writes the file. This is enough to solve my auto-naming/saving concerns.
    • May 25 2014 | 9:09 am
      Yes, this actually worked also for me. if it still doesn't work, write back, we'll try something other.
    • Aug 01 2014 | 6:31 pm
      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?
    • Aug 02 2014 | 3:24 pm
      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.
    • Aug 04 2014 | 10:11 am
      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.
    • Aug 04 2014 | 11:29 am
      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.