Midi Files (again) with multiple tracks

According to LoopOP (https://youtu.be/E5FZSKcsLxI?t=3355) and at 56:20, and I quote:
[sic] …as a matter of fact, if you import a midi file with multiple tracks, they will be imported as patterns in your project…[/sic]

HOW THE HELL DID HE DO THIS? I know this question keeps popping up, but can we at least get an answer how to import midi files downloaded from this internet?

I have spoken to LoopOP and he said:
Aubrey Kloppers hi - I haven’t tried this just took their word on it - did you contact support?

The manual states:
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.

I have raised a bug-request…

this works fine for me…

a) create a project on the pyramid
b) make sure patterns are enabled on track
c) on your daw, select tracks
d) export as type 1, with name track01.mid
e) load project in pyramid, each track has appears as a separate pattern.

the only oddity, Ive found is it assumes the track length is 1, so you need to go to each pattern and set the real track length.
(this is because track length is saved in the project file, allowing you to shorten a track with destroying midi data)

I’ll elaborate on c, d for bitwig, as its the daw I use

what I do is group the tracks I want to have as patterns on the pyramid,
then simply select the group, and do export midi.
in bitwig, it will automatically save as type 1 when you are exporting multiple tracks.

(note: not all DAWs support type 1, e.g. last time i tried Ableton Live it did non support type… hmm, I should try again with ableton live 10)

4 Likes

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

Thank you for the incredible amount of work you have spent on this!

I do not use a DAW and would like to keep it that way. My problem is that I would like to “rework” some music, but can not get the files I download from the internet in the correct format to use as a start-off point in Pyramid.

There is also the problem of not actually knowing if the file I downloaded is of MIDI TYPE 0 or 1. I did find a converter that claims to convert from 1 to 0 (and reversed) - it is quite old, but seems to work. (I will check tonight). It is called NAudio_MIDI_File_Converter and here is a DropBox link to it - FILE

So, I hope this works for anyone who wants to do the same.
kind regards
cyber7 (aka Aubrey - Cape Town, South Africa)