Having a feeling the info in the core.pyr is more particular than expected (at least on my end of understanding and desired use), I tried another test:
1 - Create & Save a Project (Source) with 4 Patterns with note data.
2 - Re-save same Project as a Destination (Destination) Project
3 - Edit a few notes on one of the Patterns of the Source Project & Save
4 - Shut down, move the SD Card, Copy the track01.mid from Source to Destination
5 - Destination Patterns are updated with Source edits, per expectation
Nicely done, right?
Except if I alter Step 3 to be: Open the Source Project, make edits (in my test case, only changing notes on Pattern01 from C to F#) via SONAR or Anvil Studio (which admittedly sticks some extra header info in the .mid file), Pattern01 is nerf’d and all Patterns are shifted (original Pattern01 is now Pattern02, original Pattern02 is now Pattern03, etc)
If I can properly wake up, I can document which files were coming from where and repeat the process clean, zip the files together, and send them…but it would seem there’s either some barf happening from extraneous .mid file header info, there’s some issues with resilience wrt core.pyr and/or Pyramid’s handling of .mid, or the option to Import should include a routine for error checking/cleaning up .mid file headers/updating the core.pyr…?
At least this test has resulted that yes: Pyramid can import its own .mid files properly, which just means back to the grunt workaround. (Although if I can consistently get it to just leave Pattern01 blank but do everything else properly I would consider that a valid workaround)