So end result is that the issue came from #2 in the post above, NSM isn’t handling absolute paths very cleanly. That could be by design, not sure, would have to ask NSM at that point.
Though saying it always launched Ardour6 is a bit deceiving if it directly referenced the ardour5 binary name in the NSM file, in that case it would launch the ardour5 binary or nothing I believe on most machines as there is not a symlink from ardour5 to ardour6 on most machines, though I could see a package maintainer doing something like that I suppose. In the end there is also definitely a problem there as well to be addressed in your template (Which you did with the symlink, though I would argue the better option is to fix the binary referenced in the NSM file)
let me quote my reply to your shot in the dark in the original discussion:
Good shot, but no I symlinked the respective Ardour versions to /usr/bin/ardour and the logs clearly show that the 6.x version is being used.
and from the initial post in this discussion (admitted: I’ve edited it a bit after your first reply):
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.
I can’t see how that is deceiving.
IMHO there’s nothing to fix in Ardour or NSM w.r.t. this issue. It’s just a matter of a non-standard session.nsm file. So the source of this issue is most probably my editing of the session.nsm file a long time ago.
Oi this is kind of a pointless discussion but just for clarity:
I originally posted in that discussion:
To which you replied as you quoted above:
Which is great, but reads as you symlinked /usr/bin/ardour -> /usr/bin/ardour6
But your file you quoted in the first post here has:
Which is obviously the absolute path to an ardour5 binary. Now presumably in your original response to me you meant that you also symlinked /usr/bin/ardour5 -> /usr/bin/ardour6 (Or really presumably to the appropriate location in /opt as that is where the official binary installs to obviously). But even so your NSM file was trying to load an Ardour5 binary(And as people can have both installed simultaneously, is an important detail), you had just worked around it outside of NSM. That was my original point in the posts since you posted the solution. Yep my first response to your solution was incorrect, but it doesn’t change that your session was trying to load an A5 binary. Yes it was not the cause of the problem you were experiencing there, but it is a problem that should be addressed (And I clarified it here in case others run into similar issues so that they know things to check as well).
I didn’t say that it was intentionally deceiving. Probably bad terminology on my part, misleading may be better?
Ok, not sure I had noticed you mention manually editing the file before either, glancing back doesn’t look like you clarified that. As the UI doesn’t allow for passing an absolute path, then as I mentioned in my above post, that seems like an intentional behavior, and it was primarily luck that it worked to start with, but honestly I don’t deal enough with NSM to worry about it myself.
Either way, glad it is solved. I will merge this thread and the other so that all the info can be combined.
I symlinked the respective Ardour versions to /usr/bin/ardour and the logs clearly show that the 6.x version is being used.