View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008271 | ardour | bugs | public | 2020-06-27 00:21 | 2020-06-28 22:19 |
Reporter | jeythekey | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Platform | GNU | OS | Linux | OS Version | (any) |
Product Version | 6.0 | ||||
Summary | 0008271: [IMPORTANT] Importing multiple/multi-channel file(s) to selected tracks: "random" file-to-track mapping | ||||
Description | Selecting tracks in editor and importing several files with the option "add files: to selected tracks" inserts them in seemingly random order. Importing the same files to new tracks inserts them in the expected order, also respecting natural sorting (%100.wav after %99.wav). First reported by BartVaes and further explored here: https://discourse.ardour.org/t/import-multiple-takes/103997 | ||||
Steps To Reproduce | Below, a post copied from that discussion (https://discourse.ardour.org/t/import-multiple-takes/103997/22?u=jeythekey): ![image|690x427](upload://v3bOoLTn2un94uViOUdYcb9nOtv.png) 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 `cp`, 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 `ls` 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. | ||||
Additional Information | This issue is really important, as, together with several other problems (see https://discourse.ardour.org/t/import-multiple-takes/103997/3?u=jeythekey) it currently renders importing more than one multi-channel take/file (or several mono-files) to separate tracks into an Ardour session impossible. There is no currently working workaround. | ||||
Tags | 6.0, Import | ||||
|
The current workaround (which for some reason temporarily seemed not work): Add files as new tracks at play head and manually move the inserted regions up using middle-click and drag; then delete the obsolete tracks. The 2nd workaround to insert multiple files as sequence to a single polyphonic track and split the regions to multiple mono-tracks via context menu afterwards should work as of Ardour 6.0-89-g4c5ad08e81 (see: https://tracker.ardour.org/view.php?id=8228). Could not test it yet, though. |
|
IMPORTANT UPDATE to the bug report: After first realizing today a similar apparent oddity in the order of tracks (regions?) in the FFT-Analysis window (see screenshot), on further inspection, I believe to have narrowed down the bug, which also makes it far less severe than first thought: Apparently, Ardour respects the order in which the tracks (regions) were selected, so that file1 is put into the track selected first, file2 into the track selected 2nd etc. (This is irrespective of the order in which the files were selected, i.e. the order of file-names is (correctly) determined by intelligent/humanized alpha-numeric sorting.). This works perfectly when using ctrl+click and selecting one track after the other, and therefore is certainly a (useful) feature and not a bug. The bug is just that apparently, when selecting several tracks at once, the resulting internal "order" of selection is undefined/random. This happens when selecting a group of tracks by clicking on one track in a group, as well as when selecting a range of tracks using click and then shift+click on the last track in the range. I hope this helps in narrowing down the problem. And it would probably make sense to solve it generally, i.e. e.g. also for FFT-Analysis, but there are probably more occasions where selection order is respected. My naive guess would be that one needs some consistent fallback strategy to determine the selection order in the case of selecting multiple tracks/regions/... at once, e.g. the visual order of tracks in the editor window or (in other situations) alpha-numeric order. In any case, it would probably be useful (and maybe even an interim solution, if the real solution is more complicated) to have some tool-tip or similar note in the import window informing the user of the feature that the clicking-sequence determines the file-track mapping. |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-06-27 00:21 | jeythekey | New Issue | |
2020-06-27 00:21 | jeythekey | Tag Attached: 6.0 | |
2020-06-27 00:21 | jeythekey | Tag Attached: Import | |
2020-06-27 01:07 | jeythekey | Note Added: 0024512 | |
2020-06-28 22:19 | jeythekey | File Added: Screenshot_Ardour_TrackOrder_FFT-Analyses.png | |
2020-06-28 22:19 | jeythekey | Note Added: 0024522 |