Om#, Windows, filename errors

[das]

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.

[bresson]

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,

[das]

First error chronology:

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

However,

1. In om-sharp Windows, “File” – “Open Recent” – L:\om-plus-plus\om-sharp\patches\Test.opat
   OPENS CORRECTLY
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
   OPENS CORRECTLY
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\…"

[bresson]

Thank you, this is useful. And probably not too hard to fix
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 !

[das]

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.

[bresson]

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!

[das]

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.

[bresson]

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)

[bresson]

@das

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

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.

[das]

Fixed! Thanks Jean.

[das]

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

[bresson]

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

best,

[das]

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!!!

[bresson]

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.

Thanks!