Track Name Filtering for MIDI File Import

UI-wise, this might work:

So, if for example, the Tracks page was used to limit the import to one track, like so:

then checking "All Same" would apply that choice to all the files in the directory being imported.  In this case, that would mean importing only track  'Bass (BB)'  from each file.

I think this is pretty logical.   Indeed, it is the current behavior which seems illogical.   (By that I mean importing just the one track from the first file, as selected, but then all the tracks from the rest of the files in the directory.)

I appreciate your reply, as always.

And this is merely one import scenario. There are potentially a dozen more. 

You could say that, but aren't there really just two import scenarios  -   a) the tracks in the incoming files are all the same,  b) the tracks in the incoming files are not all the same.

I'm thinking your potential dozen is really is just a)  and 11 cases of b).   <g>

Now, I will not be the one to tell anyone advocating for the other 11 (do these people exist?) that their use case is unworthy!

What I will say though is that IMO the use case for a)  is MASSIVE.  

The reason why is:

Any time another MIDI-generating program creates a directory full of MIDI files, those files could potentially be a), and that goes for any MIDI-generating program, now and forever.

--

I know I've got a fistful of MIDI-generating programs that I would like to use as phrase sources for Synfire, and there are many more that I do not have but other people do.

Adding the import capability for retaining multiple track settings across files is thus highly expanding of the user's universe of interoperabiity, and in a very important way.

This of course does not negate "not easy to implement".   It does perhaps though perspectivize the effort that would be involved.   For the pain, it's a major gain!

In the meanwhile, how about separating the instruments before you import?

Yes, if possible and practical, of course that is what I or anyone would/will do to proceed.  But it is often not possible, or not practical.

Solving the issue on the Synfire side would truly solve it.

Track Name Filtering and  "Files All Same" assumption are two different approaches with non-identical requirements on the input side.

Both ideas serve the same goal:  building a single-instrument Synfire Library from multi-track MIDI file source input.  

IMO this is an important goal for Synfire and it's users.

Maybe Track Name Filtering is actually the more flexible, and also the easier to implement.

I mean, programatically, how tough can it be to subject a track name to a textual comparison before a go/no-go decision to process that track for import?

when someone uses the option you are proposing

To dive deeper, if desired, it's important to keep clear what proposal we are diving deeper on.

At the moment this there are really 2 proposals in this thread, I'll call them  -

1.  "Track Name Filtering"
2. "All Same"

to which I'd like to add a third

   3.  "Channel Filtering"

Using channel filtering the user would specify like so:    I want to import what's on channel 2, only.  For the picture in the OP, that would be the Bass.

If there is a file in the directory that doesn't have Bass on ch2 then that non-bass content would also get imported into the presumably intended bass-only library, but that is on the user.   I would say such is both easy to avoid and of minimal consequence if not avoided.   

All 3 of these possible approaches are aimed at the goal:  building a single-instrument Synfire Library from multi-track MIDI file source input.  

Should we have 3 threads/topics because 3 approaches are on-the-table, or should we have 1 thread because we are pointing at one goal?   I'm thinking probably the latter.   It looks like the topic title can be edited to rename it to reflect the goal rather than just one of the possible approaches.    Should I do that?

Currently we can tell Synfire to visit every file in a directory and swallow it whole, applying the most complicated of processing (the current processing) to make some useful sense of it.   OK, that's great!   We need that, and we've got it.

We also need (IMO) to be able to tell Synfire to visit every file in a directory and only swallow the part(s) of interest.    The reason we need this is to service the goal of building a single-instrument Synfire Library from multi-track MIDI file source input in an efficient manner.

It seems offhand that the "part(s) of interest" would be specified either by (exact or partial match on) track name, or channel number (or both).    Would there be any other such ways to add to this list?   Either of these ways would work for me!   In a perfect world, we would have both.   In a "good enough" world one or the other will suffice.   In today's world, we have neither, and that's a really serious limitation.

The ultimate solution of course would be user-defined scripting, but that's not currently a priority and probably a bridge too far.

Sure, I see that. <g>

For now, the only option I consider feasible is "All Same" where a batch of equally structured files can be imported in one go.

I will have a look at the "All Same" option. If that could be done in 1-2 hours, fine. If it looks more like a whole day it will have to wait.

I much appreciate you taking a look at this Andre!

Oh, and maybe attach a ZIP with a few files for testing here.

Sure.   Two files attached.    BluJam01.zip has 80 files in it (you can always throw some out for a smaller test), all the same layout.   It's probably fairly representative as a source file to be batched.   KM.zip only has 3 files in it (also all same layout).  These are more complex files, and might be more challenging in large groups (?), but I can generate such files at will and would very much like to be able to ingest such efficiently into Synfire libraries as their groove nature makes them highly desirable as compositional source material IMO.

Cheers!

Actually the BluJam01 files may not all be exactly identical.   Might be a good test of:

Files that don't match the submitted layout can simply be skipped.