Still a Pyramid n00b here - 1 week!
(Not quite a MIDI n00b tho )
Importing Type 1 .mid files into the Pyramid:
Create a Track with multiple patterns on the Pyramid.
Save the project
Move the SD Card to the laptop, open the .mid file in software sequencer
Edit the notes on the separate tracks on the sequencer
Save as a Type 1 .mid file, paying attention to all appropriate naming conventions
Move the SD Card back to the Pyramid
Load the Project and all note data is on the last Pattern only (All note data as in: All note data for all tracks in the .mid file)
Have tried 2 different software sequencers (Sonar & Anvil).
Semi-verified these are Type 1 .mid files by their behaviour opening them in Live
Tested importing a Type 0 .mid file into a Project with multiple Patterns on the Track, and behaviour is different (so, therefore kind of verifying it’s not .mid file type issue)
Note: importing a Type 0 .mid file into a Track with multiple Patterns puts all the note data on the first Pattern
Right hand side: Note: if your track includes multiple patterns, it will be saved as a type 1 midi file (multiple track file). In the same way, if you import a type 1 midi file, all tracks will be imported as multiple patterns.
Is this a known bug?
Has anyone had expected results with this type of process?
Is this another edition of Stupid n00b Tricks?
Just in time! I am about to try to import 2 .mid files then translate them to anologue synths via the squarp.after my nap ofcourse. If it triggers the ol ADD then i’m just going to have to play them into the sequencer myself.( hope it works the pieces are kinda hard to sight read)… a guitar player wrote them on encore, live with his guitar…let guitar player jokes begin cuz we know they are funny cuz they are true.
squarp load screan is as follows. 2nd +save/load. result. backup and …(dot,dot,dot) that’s it
I check sd on compy and clearly there are the (now)3 midi files complete with names(5kb .mid files
looks likes like it’s back to ol’ mmt8 way.play the notes in.at least that’s way faster than step entry.
nope.but transferring a standard .mid file should be easier and should take what 3 seconds?
I’m thinking now …i’m going to need to hook squarp to compy,play sequences and record them as midi direct into tracks. just setup track lengths etc… and record them as they play off compy.
ive done that with EMX so it might work with squarp.
It’s a bit more complex i think. Ive only had my Pyramid a week, but it doesnt use just a standard midi file.
Im not at my computer (on my phone right now), but for the Pyramid to recognise the Project, there is a directory for it, it has a core.pyr file (i think), and then the .mid files for the tracks: track01.mid to track64.mid.
What I’d suggest in my ignorance is:
Create a project on the Pyramid with a Track with patterns enabled that is the length of the track you want to import. Save it. Then transfer your mid file to replace the Track file created in that dir and name it correctly.
Its my understanding that loading that Project should have your imported midi tracks. However, what I and technobear are experiencing is that data for all separate midi tracks in the Type 1 file are put in only the last Pattern on the Pyramid, which is counter to what the documentation would indicate.
Im thinking one workaround would be going through the steps for importing a bunch of Type 0 files on separate Pyramid tracks and then copy/ paste to Patterns on the salient tracks, but I’d swear i saw someone post that they couldnt copy tracks that had been imported ( possibly same or related bug, if it’s a bug). I havent tested that yet.
Or realtime recording is an option.
Ive got a lot of data to import so Id rather just transfer files instead of getting into gruntwork.
Oh. I didnt fully read your last post.
Unless you’re trying to import where the destination is one Pyramid Track with multiple Patterns, none of this applies. Separate Pyramid Tracks with Patterns not enabled are Type 0 mid files (I think), where Pyramid Track 01 = track01.mid, etc
Yeah - still haven’t heard back from Squarp Support, but grunt workaround:
Create a Type 0 .mid file for each Pattern, Import as separate Tracks, Copy/Paste via [Step] mode into Patterns on the destination Track. Not sure if there’s any drama due to some tweak or other undocumented…“feature” (read: bug), so YMMV, but I was able to do it in a test environment. I’m still too new to the workflow to trust myself with real data…give me an hour or two. heh
Ridiculous workaround IMO considering the documentation states you can import Type 1 .mid files, but perhaps I’ll hear back from Support.
chill out, everything has bugs … given you are the first one to report it, its obviously not used that much.
hopefully they will fix in 3.0 now you have reported it.
personally, Ive only used the exporting , since my workflow is create on the Pyramid, then move it to the DAW for ‘finishing’, so never really been interested in moving it back to the Pyramid.
also the workflow is kind of ‘broken’ going back anyway, as the whole thing is ‘flattened out’ into tracks (patterns and tracks) when doing into the daw… so if your going to import back, you then have to manually start selecting ‘groups’ of tracks, to import back into a pattern.
… and of course it doesn’t work anyway with Live, which I like using … as patterns turn naturally (if not automatically) into
anyway, I can see it important if you use the Pyramid for performance , so hopefully they will sort you out for 3.0