thanks a lot for the answer
it’s very clear now
1 Like
Yes Type 1 file workflow would make this thing a beast. please work
3 Likes
this is great news! thank you!
…and…nope
ETA: For those wondering, getting weird results in that it doesn’t want to recognise the first Pyramid Pattern/MIDI File Track 01. Naming conventions have been maintained and tried a few things (but haven’t thoroughly documented my tests/results for an official “Bug Report”), but so far it seems that my workaround will be:
- Create a Type 1 .mid file for Patterns 02-32
- Use Copy/Paste/Step Mode: Edit, etc to re-create Pattern 01 data
At least a better workaround than previous…? So…not looking a gift horse in the mouth and all…YMMV.
Cheers!
Hi @CreepyPants
Can you send me your .mid via email, so I can test it and fix this shift problem.
Thanks!
1 Like
Actually, even easier:
1 - Create a Track01 on the Pyramid containing 3 Patterns & Save the Project
2 - Create a New Project with no note data, enable Patterns on Track 01 & Save it
3 - Shut down Pyramid, move the SD card to a laptop, copy the track01.mid from the Project in Step 1 to the Project in Step2
4 - Eject the card, move it back to the Pyramid, boot up
5 - Load the destination Project and the Patterns which were originally on 1, 2, & 3 are now on Patterns 3, 4, & 5
ETA: Ooooh…I just realised core.pyr is a txt file! I’m wondering if I edit some stuff in there…?
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)
Been reading this thread and want to make sure I understand the status.
Squarp is working on a solution that will be ready for the next Beta and until then there’s a workaround solution that CreepyPants posted?
This is something I’m trying to accomplish right now for drum patterns, glad to see there’s a thread here about it.
Workaround: import Type 0 midi files into unused Tracks and then Copy/Paste into Patterns in destination Track
Or
Since current Beta shifts Patterns over by 1, when creating your Type 1 MIDI file, make the first track your 2nd Pattern and put your first Pattern as your last track. Import, then Cut/Paste the last Pattern into the empty first Pattern slot.
2 Likes