I just ran another test; this time looking at the behavior of changing the session directory. In order to issue the change, I used the directory chooser within File/Properties dialog to create and then select the new location. I then saved the session using File/Save and exited Qtractor.
In case it's not obvious, session2 is the new location.
So I'd have expected 1 of the following things to occur... either all artifacts from the old session path would have been copied (safest approach) or moved. As the information above shows, neither of those occurred and our .qtr file now exists in what I'd call a "split brain" state where the directory element now holds the correct value of session2 but all of the file references within the midi-list element point to a file residing in ../session. For whatever reason, even though no changes were made to the session, saving appears to have written
all the automation-related .mid files to the new session directory.
Aside from the fact the new session path isn't truly being used to persist dependent artifacts (though I'm confident new ones would be written there as needed), I may have stumbled onto a thing where automation data is needlessly being rewritten?
In case it's not obvious, I'd expect the old session directory to become expendable where a user took the action to specify a new location on the filesystem to be used to persist session data. If the old location isn't made expendable (by way of a move or copy), the user could easily take on a false sense of things and think it's OK to purge that directory from their system.
I just ran another test; this time looking at the behavior of changing the session directory. In order to issue the change, I used the directory chooser within File/Properties dialog to create and then select the new location. I then saved the session using File/Save and exited Qtractor.
Here's the result:
'''
❯ find session | wc -l
374
❯ find session2 | wc -l
35
'''
In case it's not obvious, session2 is the new location.
So I'd have expected 1 of the following things to occur... either all artifacts from the old session path would have been copied (safest approach) or moved. As the information above shows, neither of those occurred and our .qtr file now exists in what I'd call a "split brain" state where the directory element now holds the correct value of session2 but all of the file references within the midi-list element point to a file residing in ../session. For whatever reason, even though no changes were made to the session, saving appears to have written
all the automation-related .mid files to the new session directory.
Aside from the fact the new session path isn't truly being used to persist dependent artifacts (though I'm confident new ones would be written there as needed), I may have stumbled onto a thing where automation data is needlessly being rewritten?
In case it's not obvious, I'd expect the old session directory to become expendable where a user took the action to specify a new location on the filesystem to be used to persist session data. If the old location isn't made expendable (by way of a move or copy), the user could easily take on a false sense of things and think it's OK to purge that directory from their system.