[FEATURE] Persist models/IRs through relative paths

[mourner]

Our band shares DAW projects of songs we work on through a cloud, and everything works seamlessly when one person saves the project on one end and the other opens it after syncing, except for NAM which can't load models/IRs — I assume that's because they are persisted through an absolute file path, which breaks down if the project is stored in a different folder or is opened on a different OS (Mac to Win or vise versa).

Describe the solution you'd like I'm wondering if there's an easy workaround — storing model/IR paths relative to the project file in addition to the absolute path. If the latter fails to load (e.g. file not found), the plugin could try the relative path fallback. That way, e.g. for our use case, we would simply put the profiles/IRs in the project folder (or in a separate folder alongside the project ones), and it would just work between users.

Describe alternatives you've considered I know there's #206 which proposes persisting models and IRs as data in the project, but since the PR haven't moved in half a year, I assume it's not an ideal tradeoff and has issues.

Additional context When you open a DAW project with NAM from a different computer, the plugin loads and shows the paths of the model/IR in the file fields, but it doesn't actually apply them (without any apparent warning) until you reload both explicitly.

Let me know if this sounds like a good idea, and maybe we'll try to put up a PR for this. cc @olilarkin — not sure if this should be handled here or in the iPlug codebase.

[olilarkin]

I really think that the model and IR should be serialized in the plugin state. The compressed model will not be that big. I hope to add a PR for this behaviour soon

[sdatkinson]

Thanks @mourner for the very nicely-filled out feature request 🙂

Using paths that are relative to the DAW project sounds reasonable to me, and I can see how it would result in part of the underlying issue being solved (not the cross-platform aspect, I think, due to differing separators on Unix vs Windows filesystems). I'm interested in how the project information (e.g. its location on the filesystem) could be shared from the DAW to the plugin. @olilarkin, is something like this defined in iPlug2's interface?

As far as the other way of solving this that's been discussed (serializing models into the plugin's state), I'm not keen on this. Here's my thinking:

1. This isn't how other plugins that use files like NadIR work, and it's not how other applications that use files (e.g. Microsoft Word, DAWs) work--if you're using a program that requires a file, and you move the file while the program is closed, then the program alerts you that there's a problem when you open it the next time. I don't want NAM to operate in a way that's obviously different from this precedent for "Chesterton's Fence" reasons--I can see that it would be an uncommon choice, and I know that I don't have experience making this choice differently from others, so I can anticipate that I'll run into surprises.
2. For example, concretely, this would create a new "path" in the state of the plugin where models aren't loaded from files but from the serialized state. For example, the arrows may behave unexpectedly because there's not an actual filesystem path behind the model that's been validated. I anticipate this will cause bugs and confusion.

But the key one to me really is (1). I know I'm forming my opinion based on a limited number of examples, but I lack examples that go the other way; it'd do a lot for me to see some. For example, are you using an IR loader in your project that doesn't have this issue? Like I said, I'm aware I have limited experience with this part so I'd love to have more context.

[olilarkin]

Afaik there are no APIs in plugin formats to get the path of the project in order to store relative file paths.

I have been trying to make NAM work well on iOS and the reality is that on iOS and recent macOS you are dealing with sandboxed plugins that can't access some folders. Daw projects and files are synced via iCloud etc. People constantly reorganize their files and if this breaks a precious music project then :(

I think storing the path first and then the serialized model IR as a backup in case the file is not found might be a good solution to enable sharing of "presets" as well as models/irs

[mourner]

Thank you for your thoughtful input @sdatkinson @olilarkin, appreciate this very much!

not the cross-platform aspect, I think, due to differing separators on Unix vs Windows filesystems

Separators normalization should be an easy fix on the plugin side — e.g. quick googling turned up this method from the standard library: https://en.cppreference.com/w/cpp/filesystem/path/lexically_normal

[sdatkinson]

quick googling turned up this method from the standard library: https://en.cppreference.com/w/cpp/filesystem/path/lexically_normal

Good spot. The problem with this is that std::filesystem is unfortunately too new, and works against the goal of being able to support older operating systems (see e.g. #23 , which AFAIK is the main technical issue blocking NAM from working on Mojave, which I get asked about often)... There are functionalities that we get via "WDL" code that's held in iPlug2 (e.g. WDL_String in this case), which has the benefit of lessening our dependencies on 3rd-party code, but with the drawback of being a bit opposed to solutions like you've found.

...The joys of supporting a lot of different users! 😅

[olilarkin]

Explicitly defining a place on macOS (e.g. in ~Music/NAM/Models) and something similar on windows with %LocalAppData% might be a solution, where relative paths can be used rather than absolute paths. Don't think there is a solution for iOS though.

[olilarkin]

It also limits users freedom to store their .nams where they like

[ersheff]

I was just looking to see if this feature had been requested because I'm experiencing the same struggle across 2 of my personal computers and one collaborator's computer. We're syncing Reaper sessions over Google Drive, and so far NAM is our main remaining issue. We're storing .nam files and IRs in the Reaper session folder but need to reload both every time we work on a different computer due to relative vs absolute file paths.

I think relative paths outside of the project folder would still be a big help, even if that doesn't work with cloud services.

[clodobox]

I have the same problem: I use three computers to make music. For the moment, the only solution I've found is to make a folder at the root of the C: drive with my IR and NAM files synchronized between my computers.

Unfortunately, this isn't possible for my Macbook, but it's already a solution for my two main computers.

[ersheff]

Just throwing an idea out there: since there's not a good way for the plugin to reference relative paths in the project folder, what about a preference to designate preferred search paths?

As an example, the program Max from Cycling 74 has a "File Preferences..." panel that allows you to add user paths (and optionally include subdirectories). If I include an audio file, plugin, or any other resource in my Max patches, it will check these paths first, post a warning if the resource was found in multiple locations (in that case, I think it will just use the first one found), or post an error if it can't be found. Obviously, developers are comfortable with the idea of adding paths, but I think Max provides a pretty nice GUI-based way to do so (and provide multiple, not just one).

With multiple computers and multiple users, each person has the ability to put whatever custom paths they'd like in the preferences. As long as the .nam or .wav IR files have the same name, NAM could find them in the user-designated paths. This would also help solve cloud sharing issues as I could add the path for my Google Drive, iCloud, etc folder in my laptop, while my collaborators could do the same on their end.