< Back to IRCAM Forum

Om#, Windows, filename errors

In om# 1.2, I’ve encountered 2 filename error problems. In my system, all om# files are on L: and I have configured the Preferences accordingly. Attached are the error messages corresponding to the following:

  1. If I load a patch and simply “Save” it, om# tries to save it to a directory on C: (which doesn’t exist) instead of L: (where I loaded it from).

  2. When trying to load an abstraction, om# is adding extra ''s creating an illegal path which it then cannot load from.

Hello — thanks for these reports.
Could you provide the following details:

If I load a patch and simply “Save” it,

=> How do you load it ? From the “File/Open” menu ? Somewhere else ?

When trying to load an abstraction

=> Here also, can you be more specific on the procedure to follow in order to reproduce that ?

Thanks again,

First error chronology:

  1. In om-sharp Windows, “File” – “Open” – L:\om-plus-plus\om-sharp\patches\Test.opat
  2. “File” – “Save”


  1. In om-sharp Windows, “File” – “Open Recent” – L:\om-plus-plus\om-sharp\patches\Test.opat
  2. “File” – “Save”
    ERROR MESSAGE (it tries to save it to C: directory, which does not exist)

Second error chronology:

  1. In om-sharp Windows, “File” – “Open” – L:\om-plus-plus\om-sharp\patches\Test.opat
  2. In patch window,
    Right-click (to get pop-up menu)
    Left-click “External Abstraction (p)”
    Left-click on L:\om-plus-plus\om-sharp\patches\Test.opat
    ERROR MESSAGE (it adds an extra ‘’ so that the path is corrupt (L:\om-plus-plus\om-sharp\…"

Thank you, this is useful. And probably not too hard to fix :slight_smile:
When pathname are saved/reloaded as simple strings (like when OM# saves the “recently opened file”) this information can get lost on the way!
Stay tuned for an update !

It seems like the problem shown in the first example extends to trying to load a library. When I double-click on a library, it tries to load it from drive C:, but my libraries are on drive L:, correctly indicated in preferences.

While this is being fixed, can you suggest a workaround to be able to load a library? Thanks.

Thanks for reporting. I am hoping to release an update very soon, or I’ll let you know if there’s an easy fix that you can apply.
Sorry for the in convenience!

Thanks. In the meantime I just copied all the libraries to C: and they load fine. I am getting an error message relating to what it thinks is a missing library sub directory (I think it’s called ‘reference files’ – I’m not at the computer at the moment). I don’t know what that’s about or what to do about it.

I am hoping that this file fixes the different issues you are mentioning here.
Please let me know!

(copy put the file in teh init sub-folder of the OM# application)

fix-pathnames.lisp (5.8 KB)

About this problem, please try to provide an error report (listener? error window?)
It could be because om# expects you to have write permission on the disk where the library is installed, so it can generate and write reference files in there.

Fixed! Thanks Jean. :smiley:

It’s still looking on Drive C:. See attached pictures.

This should be fixed with this other file.
fix-gen-reference.lisp (6.8 KB)


Perfect! As far as I can tell, everything in the Windows version is working and looks good in 4K. If you’d like to use me as a test bed for the Linux version, I’d be pleased to help.

Thanks Jean!!!

I’d be interested to get more feedback on the HiDPI rendering topic.
If you can, please follow up on the GitHuib thread: HiDPI issues · Issue #3 · cac-t-u-s/om-sharp-users · GitHub

At the moment vor v1.3 is planned to use the “Segoe UI” font as default on Windows.