DRAFT: Multi MIDI File Import

[szydek]

Summary

Enhances the MIDI upload workflow to support multiple files with independent track assignments. Users can now build complete multi-track sets by uploading several MIDI files at once, assigning each to tracks 1-4.

Features

• Multi-file selection: Upload one or more .mid/.midi files simultaneously
• Per-file track assignment: Each file gets its own Track 1-4 dropdown
• Smart slot filling: Multiple files targeting the same track fill empty clip slots sequentially
• Create new or add to existing: Support for both new set creation and adding clips to existing sets
• Visual color selection: Color swatch dropdowns for pad and clip colors
• BPM preservation: Maintains existing set tempo when adding clips

Changes

• Replaces single-file upload with multi-file interface
• Removes "MIDI Type" dropdown (no longer needed)
• Dynamic track assignment UI appears after file selection
• New save_uploaded_file() helper for batch processing
• Path aggregation for multi-file new set creation

Testing

• Single file → new set
• Multiple files → new set (different tracks)
• Multiple files → existing set
• Same track → fills empty clip slots
• Clip colors inherit from pad color for new sets

[szydek]

@charlesvestal - During my testing, this seems to be pretty useful for importing MIDI. I'd be curious to know what you think. Note that it builds upon #563
Thanks!

[charlesvestal]

Thanks for this — multi-file import with per-track assignment is genuinely useful, and the math.ceil clip-length fix (plus the new test for exact-bar boundaries) is a nice correctness improvement. The core note-extraction in assign_midi_to_track reads well.

A few things before it can merge:

1. It's stacked on #563. This branch was cut from the Overview PR, so the diff contains all of #563. Once #563 lands, please rebase onto main so the diff shrinks to just the MIDI-import changes — much easier to review in isolation, and it depends on #563's generate_pad_grid(..., free_only=True) signature anyway.

2. The drum / 808 path is silently dropped. Removing the "MIDI Type" dropdown deletes the midi_type == 'drum' → generate_drum_set_from_file() branch, so all imports now go through the melodic midi_template.abl with no drum-note remapping onto the 808 layout. generate_drum_set_from_file is still imported but never called. If dropping drum import is intended, let's say so and remove the dead import/def; if not, it needs to stay reachable. (Worth noting #559's use case is drum patterns.)

3. A couple of safety basics:

• assign_midi_to_track does os.path.join("/data/UserData/UserLibrary/Sets", set_name) with no sanitization on set_name — a ../-style name would write outside the sets dir. Please sanitize/validate.
• No server-side .mid/.midi check (the accept= attribute is client-only). A non-MIDI upload currently fails deep inside mido with a vague message.
• save_uploaded_file() writes every file to a fixed uploads/ dir by basename, so two selected files named clip.mid overwrite each other before processing (and the server is threaded). Give each upload a unique temp name.

4. "Add to existing" + partial failures. When a set's UUID isn't found, the code falls back to a bare Sets/<name> path that doesn't exist, so it silently creates a new set instead of appending. And when some files in a batch fail, the aggregate is still reported as success: True — the user sees a green banner even though clips are missing. Both should surface as clear errors.

On #559: this adds track-level import but not per-slot targeting in the Set Inspector, so I don't think it closes #559 — I'll keep that open for the inspector-integration work.

Happy to merge #563 first and then take another pass at this once it's rebased.