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