NSM + Ardour 6: Session created with Ardour 5 won't open correctly

I’ve been using NSM with Ardour 5.x for almost every recording I did. Now I’ve switched my OS from Fedora to Debian (Sid) which uses Ardour 6. Unfortunately, my NSM sessions won’t open properly anymore. Ardour 6 just opens an empty project when launched via NSM.
I can open the Ardour.ardour file in my session folder directly in Ardour, though, and it gets converted to the Ardour 6 format.
Is this a known issue? Does anyone know a workaround?

Kind regards,
Felix

This is expected behavior. The session format changed in an incompatible way, so the first time you load an old session it is converted and a backup of the original is created.

This has always been the case for new major versions (except Ardour 3.5 -> 4.0).

I assume the problem is that this may be an interactive process that is not supported by NSM, and you can only use NSM after manually converting the session at least once.

Hi Robin,

thanks for your very quick reply!
Unfortunately, opening the project once without NSM to convert it into Ardour 6 format doesn’t do the job. Yes, there have been some dialogs to answer. In the end I got a project that I could open cleanly (without any questions) in Ardour 6. But when I use NSM to open the project within the NSM session it yields an empty Ardour project again.

Further hints are highly appreciated.

Kind regards,
Felix

Does it work with new projects?

Yes, it does. Just checked.

I didn’t dive into it deeply, but I had a similar issue with Ardour in NSM, the Ardour version in kxstudio I think, whereas the one Debian did work IIRC:
Installed: 1:6.3.0+ds0-1

edit: hm not sure if it’s the same issue. I got a small dialog window where Ardour says that it couldn’t open the session, because it was made with a previous version of Ardour. The Debian version was able to open it though IIRC.

Hi rozea,
thanks for your comment! Actually, the Ardour version from kxstudio, which is a 5.x version, doesn’t even launch on my machine. So I only used 1:6.3.0+ds0-1 on Debian.
My main machine is still on Fedora 32 which ships Ardour 5.12. I created a very simple Ardour 5 sessions there within NSM and then tried to open that NSM session with the Ardour 6.5 nightly from a couple of days ago. I got the same behaviour as on the Debian machine.

I can’t even find a kxstudio ardour package atm it seems, maybe the package is removed from the repo recently?
$ apt policy ardour
ardour:
Installed: 1:6.3.0+ds0-1
Candidate: 1:6.3.0+ds0-1
Version table:
*** 1:6.3.0+ds0-1 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status

I do not have an immediate idea why it works for new sessions, but fails after converting old ones.

After converting manually, can you try to remove and re-add Ardour to the session? Does that work around the issue?

I have to admit that I’m not very familiar with NSM, it’s mostly user-contributed code, and I also don’t know to to best debug it since that would require passing debug options and/or looking at output.

We could add some debug output, can you see what ardour reports on stdout/stderr in the NSM session-manager?

Ardour 6.5-12-gba9e310d4d (available from https://nightly.ardour.org/ in a few hours time) does print some debug output.

Please check if you can see “NSM_Client::command_open …” and “ARDOUR_UI::load_from_application_api” messages.

Ideally we’ll continue this on tracker.ardour.org. The forum is not great to keep track of issues.

OK, I’ll open an issue on the tracker tonight. But since I’m at it right now and will be busy for the rest of the day here’s what I guess might be important to track it down (will repeat that in the tracker):

I’ve created a simple NSM session called ‘Ardour5’ with just Ardour in it.

session.nsm

Ardour:/usr/bin/ardour:nEIET

I’ve converted the Ardour.nEIET/Ardour.ardour project by opening it once manually.
Opening the Ardour project now with ‘ardour Ardour.nEIET/Ardour.ardour’ works just fine when ardour points to an Ardour 6 version.

When I open that project from NSM at the end of Ardour’s output I find this:
Ardour: [INFO]: Loading menus from /opt/Ardour-6.5.0-dbg/etc/ardour.menus
actually writing state to /home/fex/NSM Sessions/Ardour5/Ardour.nINAE/Ardour.tmp
renaming state to /home/fex/NSM Sessions/Ardour5/Ardour.nINAE/Ardour.ardour
saved state in 1.9 ms
locate to 0 took 156 usecs for 1 tracks = 156 per track
Ardour: [INFO]: Loading user ui scripts file /home/fex/.config/ardour6/ui_scripts
Ardour: [INFO]: Loading plugin order file /home/fex/.config/ardour6/plugin_metadata/plugin_order
Ardour: [INFO]: Loading history from /home/fex/NSM Sessions/Ardour5/Ardour.nINAE/Ardour.history
Ardour: [INFO]: Ardour: no history file “/home/fex/NSM Sessions/Ardour5/Ardour.nINAE/Ardour.history” for this session.
actually writing state to /home/fex/NSM Sessions/Ardour5/Ardour.nINAE/Ardour.tmp
renaming state to /home/fex/NSM Sessions/Ardour5/Ardour.nINAE/Ardour.ardour

The Ardour.nINAE/Ardour.ardour project file does not contain any Playlists.

Shot in the dark here, is it possible NSM is trying to use the Ardour5 binary to open the Ardour6 session?

  Seablade

Good shot, but no :wink: I symlinked the respective Ardour versions to /usr/bin/ardour and the logs clearly show that the 6.x version is being used.

I wonder where this message comes from. I would seem like it comes from Ardour, but it’s not.

Could it be that some other tool in your NSM session is also in reading the *.ardour session and fails to do so because the session-format has changed?

Sorry, that last line (“The Ardour.nINAE/Ardour.ardour project file does not contain any Playlists.”) was just my own comment.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

Hi,
sorry for being silent so long after asking for help.
I found a solution for my issue with NSM sessions created with Ardour 5, see this:

I found that in my original session.nsm files Ardour was referenced with the full path, e.g.:

Ardour:/usr/bin/ardour5:nWJWM

Linking an Ardour 6 version to /usr/bin/ardour5 doesn’t work, neither does changing that line to

Ardour:/usr/bin/ardour:nWJWM
or
Ardour:/usr/bin/ardour6:nWJWM

with /usr/bin/ardour being the Ardour6 binary or /usr/bin/ardour6 being a link to the Ardour6 binary, see the original discussion.

What does work is not using the full path in the session.nsm file, i.e.:

Ardour:ardour:nWJWM
or
Ardour:ardour6:nWJWM

Hope this helps if someone else stumbles upon the same issue.

Kind regards,
Felix

Heh so the shot in the dark actually was it? I need to start a chalkboard somewhere…

Seablade

No, it wasn’t - as I’ve already said in the original discussion. NSM did not try to use the Ardour 5 binary as you suspected. It always launched Ardour 6.There isn’t even an Ardour 5 binary on the respective Debian machine on which I first ran into this issue.
It’s just that starting Ardour 6 from NSM using the full path ‘/usr/bin/ardour’ will yield a new, empty Ardour session each time you open the NSM session, while using just ‘ardour’ or ‘ardour6’ or ‘ardour-whatever-6-is-in-your-path’ will open the session correctly.

So, to make it a bit clearer:

  1. It’s not an issue with Ardour5 vs Ardour6.
    Even sessions created with Ardour 6 won’t open correctly if for whatever reason (see below) there’s an absolute path in the session.nsm file. In that case Ardour 6 will create a new, empty session instead of using the old one.
  2. At least current versions of NSM’s UI won’t allow passing in an absolute path.
    I’ve created all my sessions from a rather old template, though, which happened to use an absolute path for ardour. I don’t remember if I have once edited the respective session.nsm file by hand. But I guess it’s reasonable to assume that that was the case.