Midi Files (again) with multiple tracks

ok, so I tried with a few other daws I have :slight_smile:

Live 10, still the same, imports type 1, but cannot export them
Reason 10, seems to work fine
Cubase 9, seems to work fine
Logic 10, seem to work fine

what I did as a simple test was,
create 2 tracks in each daw, group if possible -
then use the export or save selected tracks , as applicable, as track01-track04.mid
(Id already created a pyramid project where tracks 1-16 all have patterns enabled)

the only ‘odd thing’ that seemed to happen, on all except bitwig, is that they seem to all be on patterns 2&3.
give 3 daws did the same thing, I suspect this may be an oddity with track 1 , vs other tracks… rathe than to do with the daw, and bitwig was different just because I happened to do it first.

anyway, in practice it’s not really an issue, you could either use ‘as is’ , or copy the patterns.
(you probably would need to test this if you were going back n’ forth between the pyramid and daw)

note: this is not extensive testing, which I do not have time to do, but rather just to see what i had that works and what no… as I stated previously, I do not really use the Pyramid in this way, i tend to use it standalone.


anyway, as far as i could tell seems to ‘just work’, basically as its described in the manual.

the key is :

a) check your daw supports export type 1
the easiest way to do this is… select multiple tracks, and export them as one file as midi , then drop that file back into your daw, if it loads back multiple tracks you good to go, if its only loads 1, then its not exported as type 1 - so wont work with pyramid

b) make sure your pyramid project has patterns enabled.
(I dont know if you can do this ‘after’ , possibly , possibly not)

c) make sure you save as track01.mid ,
note: the extra 0, for tracks less than 10, and its .mid NOT .midi

d) you will need to set things like track length, tempo etc… as these are stored in the project, not loaded from the midi file.


some things to bare in mind/remembers … as aids understanding:

  • the pyramid does not IMPORT these midi files, there is no ‘conversion’ process, this is how it actually stores the midi data for the project.
  • the pyramid only looks at the midi data in these files, it is not interested in extra headers like tempo, track length etc, as these are stored in project file,

these are important, as it shows good reason why things work as they do…
i.e. you might ask yourself, why does it not use the track/pattern length from the midi file.
and the answer is above… because the file might conflict with what the project file says, and which is correct?
also the pyramid allows you to do things like shorten then length of a track non-destructively,
i.e. its perfectly valid to create a 4 bar loop, shorten it to 1 bar, then expand it back to 4 … you will not loose data
… therefore the project file dictates what the current length of the track/pattern is NOT how much data ‘happens’ to have been saved.

furthermore, there is no concept of import (as above) , so it cannot decide to just do this, if its ‘a new import’, it doesn’t have this knowledge/workflow.

this is actually quite beneficial at times, as it means if you go back n forth to the daw, you are actually editing the underlying data, not some interpretation of it :slight_smile:

8 Likes