Import multiple takes

Yes, that’s a part of the story.

The other part of the story is coming up with some heuristic for knowing how the names of similarly named files connect them together. To a human, it may be obvious that “Voices-1.wav” and “Voices-2.wav” have some relationship (even if it is not entirely clear what it is). To a computer, without a heuristic in the code, they are not related in any way other sharing the first 7 characters of their filenames.

1 Like

So are we saying that Ardour could not default to placing MixPreCelloSoloAll1-002%98 after MixPreCelloSoloAll1-002%97 in @jeythekey’s example via simple alpha-numeric ordering as you might see it in a file browser? Likewise, if you are asking to place files sequentially on the same track, again it seems like Ardour should default to importing in alpha-numeric order. I’m doubly puzzled because I feel like I would have seen this happening in my own workflow before now…

Surely alpha-numeric ordering isn’t the same as needing a heuristic? I.e. if you know what you are importing and only select those files, I assume Ardour should import them in order horizontally or synced vertically based on channel/track distribution choice?

We treat foo%N.{wav,aiff,whatever} specially for one reason and one reason only: ProTools does the same.

But as far as I remember, we do this only to identify groups of file that should be collapsed into a single track (i.e. N mono files -> 1 N channel track).

I agree with @bachstudies that I think the first step would be simple alphanumeric ordering in the same way most file browsers do. That means that yes 05 - SomeTrack.wav would come before AnotherTrack01.wav, but I think that would be fine and expected given that 99.9% of software would work the exact same. No need to overthink in this case I believe.

Is it perfect? Nope. Is it better than currently? I would argue yes.

  Seablade
1 Like

But this shouldn’t even come into play then if the user has said to create a new track for each channel, or each file correct?

  Seablade

Waoh, thanks for the prompt reactions and the lively discussion, just great!

As I encountered several, possibly unrelated problems (bugs??): Should I create several issues, one for each problem (bold in my first 2 posts)? Or should we discuss all the issues first here in order to discriminate real bugs from missing knowledge on my side (e.g. how to move regions between tracks in Ardour 6)?

The import-ordering issue seems to already be identified, so I’ll start with that one in the tracker. But what about native support for polyphonic wav-file-import? Should this be a separate issue? I could imagine that it would be rather simple, once the file-ordering is fixed: Just chain the splitting-step (of import to region list) with the import to single/selected tracks and iterate over this for every selected file (if as sequence is selected).

What would be amazing is a fully-featured import for any type of wav so that you can either route channels to existing tracks or create as needed. I guess a little bit like part extraction in Musescore :wink: So, for a specific example: a polywav containing a stereo pair and two mono spot mikes. Let’s say I already have a stereo track and one mono track created. Selecting the polywav in the import dialog would allow me to import channels 1 & 2 to the existing stereo track. Channel 3 could be imported to the existing mono track and channel 4 to a new mono track. I’m not sure of the most intuitive way to do a GUI for that (Catia-style wiring, import grid, assigning channels to import groups and automatic track creation based on number of channels) but it would definitely cut out the need for Wave Agent, SoX etc.

Ideally, this would also allow for simultaneous import of multiple polywav sequentially applying the same mapping for all takes/recordings.

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

(So, this would already be the bug report, I guess ;))

1 Like

That explains it: You probably never used “import to selected tracks”?

Bug-report for file-track-mapping during import to selected tracks here: https://tracker.ardour.org/view.php?id=8271


Below is supposed to be a new post, but I appear to already have reached my allowance of posts :wink:

(from post below)

How far does importing a polyphonic wav file to existing tracks differ in this respect from importing it to new tracks or to polyphonic single tracks? The latter two things work flawlessly, at least for the files created by the MixPre. In my understanding, Ardour just has to figure the number of channels in a wav-file before importing it, in order to decide if the number of selected tracks matches the number of channels in the file, and if, it just has to show the option to add to selected tracks. But probably it isn’t that simple :wink:

Importing several polyphonic/stereo files in a sequence to separate tracks (one per channel) would probably be an additional option, as in the moment it only imports to a single polyphonic track.

So, in my understanding, the “feature” could be split into two (three) separate issues:

  1. Fix filename-channel mapping in import to selected tracks
  2. Make this option also available for polyphonic tracks, if the number of channels in the file matches the number of selected tracks.
  3. Add an option to add several files in a sequence with one track per channel (to selected or to new tracks).

Should we handle it like this, i.e. should I go on and create issues for 2. and 3. above?

That would be the basic support for me. It certainly could be refined later on as suggested by @bachstudies, e.g. by automagically combining stereo with mono-tracks etc.
Also, the option to add files stacked instead of in a sequence would be nice, but again, that would be more a bounty than a core feature.

1 Like

Yes but severity on that one should be set to ‘Feature Request’.

Polyphonic WAV support could be a bit more tricky, as it will depend on other things outside Ardour as well, first of which being support in libsndfile for it, which I don’t remember off hand if it supports more than stereo files or not.

But my standpoint is get what is already there working correctly first;) Then work on new features.

    Seablade
2 Likes

We already support arbitrary channel counts in any file format supported by libsndfile (which is more or less any file format except mp3).

The commandline gives you the ability to automate things with scripts. Sox is able to split and combine files / channels any way you like. If sox refuses to process the BWF created by a SoundDevices recorder, then you can first convert it to standard wav or flac with ffmpeg. This might be unnecessary though.

ffmpeg -i 6_channel_file.wav -acodec pcm_s24le 6_channel_output_file.wav
ffmpeg -i 6_channel_file.wav -acodec flac 6_channel_output_file.flac

Splitting a multichannel file
Export channel 1 to another file:
sox 6_channel_file.wav channel_1.wav remix 1

Export channels 1 and 2 to a file:
sox 6_channel_file.wav channels_1_and_2.wav remix 1 2

Export channels 1 - 3 to a file:
sox 6_channel_file.wav channels_1_2_3.wav remix 1 2 3

Combine 6 mono files to a 6 channel file
sox -M channel_1.wav channel_2.wav channel_3.wav channel_4.wav channel_5.wav channel_6.wav 6_channel_output_file.wav

2 Likes

+1 for fixing the column widths. Thus is really the only thing that is stopping me recommend Ardour for what I teach where organisation of files & regions is crucial.

1 Like

I made an important observation today concerning the file-track mapping on import to selected tracks. I have reported it in the bug report, but also wanted to share it here, because it might allow to work around the problem in the meantime, especially for @BartVaes (?) (maybe also interesting for paul, @seablade and bachstudies? [sorry, only 2 mentions allowed ;)])

Apparently, Ardour respects the order in which the tracks are 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. I.e. there is nothing wrong with this step.). 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.e. currently one has to select one track after the other using ctrl+click.

Hope that helps.

PS: Thanks mhartzel for the detailed info, very useful.

1 Like

Yes, I was discussing this with Paul on IRC the other day. I am personally not convinced this is the correct way to approach this. I personally believe it should always drop the files in order (Based off file name) into the tracks top to bottom. If you want to import specific files to specific tracks you need to reorder the tracks temporarily yes, but it gives easier visual feedback provided everything is working correctly, and is much easier to predict/understand what is happening in my opinion.

I would love to hear from those that think the current way is the best option though as I just am not seeing it myself yet.

BUT my major issue I think centers around visual feedback to the user. I don’t think there is enough of it personally, and I would like to focus a bit on drag and drop import instead of dialog based import. I need to do a bit more thinking on this topic before I propose something though.

   Seablade
1 Like

If I may add my thoughts:

  1. I would be fine with either way, always top to bottom or as it is now, but with top to bottom behavior when selecting several tracks at once (shift click or group). I would opt for what requires less complex code changes (and inform the user of the respective behavior in e.g. a tool-tip).
  2. Drag and drop would be certainly convenient if it works on multiple files/sources at once. Currently, drag and drop from the sources list only works one source at a time, which is not usable for multi-track recordings.
  3. Drag and drop from a general file browser would also be convenient, but certainly cannot replace the current import window, which provides very many important info/features.
  4. Judging on the gain in convenience, drag-and-drop import would have a low priority for me compared to:
  • Importing several multi-channel files in a sequence, one track per channel
  • Importing multi-channel files (optionally as sequence) to existing tracks (both could, of course, be solved also by drag-and-drop, which would be nice, but the basic function is more important to me.)
  • Leave the option to import to selected tracks selected or make it the default option as soon as there are a matching number of tracks selected.
  • (As an alternative/work-around) Converting multi-channel tracks/regions to several mono-tracks; currently (v. 6.0.178), only mono-sources are created (in the list view), but without the possibility to add them to tracks time-locked (e.g. drag and drop together, see above), this feature is not very convenient. (At least I can align the regions easily after dragging, so that could be another current workaround for multi-track import, but a rather tedious one.)

Yes, and it’s the same behaviour in plugin manager as well. You can resize the view but the columns are fixed. Sometimes part of the texts are unreadable this way.

I’ve now created issues for all bugs and feature requests that came up in this thread:

  • Bug: File-channel mapping on import to (batch) selected tracks (as posted above): #8271
  • Feature: Polyphonic import part I: #8281
  • Feature: Polyphonic import part II: #8283
  • Feature: Converting polyphonic tracks to mono and v.v.: #8284
  • Bug: Make column widths adjustable: #8286
1 Like

Spam filter: new user tried to create multiple posts with links. I’ll unblock them, one sec…

Edit: Thanks for filing the issue reports, links in the post are now updated and live.

1 Like