I did some further testing and came to the conclusion that there must be a veritable bug specific to importing files to selected tracks. Therefore, it probably is best to separate this one from the (maybe, as @bachstudies suggestions suggest, more complex than thought) new feature request. Do you agree?
So here is my little “experiment”:
I copied the same 4 mono-files created by Ardour during the import of a 4-channel poly-file (the ones on the left) to files named “Test1.wav”, “Test2.wav” etc. (using zsh
, if that should matter, and in the respective time-sequence, i.e. it is not sorting by creation date). Importing both, the “original” and the “Test…” files to selected tracks resulted in the same (strange) order, irrespective of file-naming (fist 2 columns). Next, I copied them another time to files “TestTest…”, but this time naming Track 2 as 3 and Track 3 as 2 (i.e. as they are inserted). This indeed imported the audio-content in the right order, because it was again inserting “TestTest2” to the 3rd track and v.v. (3rd column). But when I repeated this with 8 tracks selected and importing all 8 “Test…” respectively “TestTest…” files, the order was totally screwed up (4th column).
However, when importing as new tracks, the order is exactly as expected, both for the “Test…” files and for the original ones (the 2 columns right of the red play head in the screen shot.) Also note that, as humans would do but e.g. bash
doesn’t , …%100.wav comes after %99.wav, so this heuristic is already correctly implemented in principle. It’s just in importing to selected tracks, that things get screwed up.
(So, this would already be the bug report, I guess ;))