Waveform "Export Render to a File", Format: MIDI file, using wrong format

[zzz00m]

I was trying to export 3 MIDI tracks as a MIDI file to open up in another DAW, when I noticed this issue.

If you export all MIDI tracks to a single MIDI file, you can only export a maximum of 16 tracks, because all of their notes and events will be mixed together into one track in the rendered MIDI file. So the only way to separate the tracks again will be to assign a different MIDI channel to each source MIDI track (there are only 16 channels to assign).

Not perfect, but so far so good.

The problem is that this exported MIDI file should be rendered as a format "Type 0" MIDI file. But instead it is rendered as a format "Type 1". This is the problem, because some DAWs will not realize the need to separate the track data with a "Type 1" and will just dump it all into the first track.

I can open the MIDI file in another program that lets me separates the tracks by MIDI channel, then re-export again as a MIDI "Type 0" file. Once I do this, I can open the file anywhere.

I really shouldn't have to use three programs to exchange MIDI data between two of them, right?

I did a search back in the forum for the past two years, and it appears that this issue may have been present as far back as Tracktion 6, in this thread here: viewtopic.php?f=22&t=450518&p=6313157&h ... I#p6313157

[dRowAudio]

Thanks, adding "Type 0" MIDI exports is on our FR list but I can't say exactly when we'll get to it.
For now, probably the easiest method is to render each track to a separate file and import all the tracks separately.

[zzz00m]

Thanks, adding "Type 0" MIDI exports is on our FR list but I can't say exactly when we'll get to it.
For now, probably the easiest method is to render each track to a separate file and import all the tracks separately.

Thanks for the support! Waveform is a great program with some truly inspiring new MIDI features.

I plan to make this program a regular part of my workflow, so it is essential that the MIDI export works correctly.

If you are saying that ""Type 0" MIDI export is on the FR list, then that implies that "Type 1" is the current implementation.

I believe that the current "Type 1" MIDI export should be separating the MIDI tracks. If not, that is either an incorrect interpretation of the standard, or a bug.

From MIDI.org:
"In a Type 1 file individual parts are saved on different tracks within the sequence. In a Type 0 file everything is merged onto a single track"

https://www.midi.org/articles/about-mid ... midi-files

[zzz00m]

Thanks, adding "Type 0" MIDI exports is on our FR list but I can't say exactly when we'll get to it.
For now, probably the easiest method is to render each track to a separate file and import all the tracks separately.

Thanks for the support! Waveform is a great program with some truly inspiring new MIDI features.

I plan to make this program a regular part of my workflow, so it is essential that the MIDI export works correctly.

If you are saying that ""Type 0" MIDI export is on the FR list, then that implies that "Type 1" is the current implementation.

I believe that the current "Type 1" MIDI export should be separating the MIDI tracks. If not, that is either an incorrect interpretation of the standard, or a bug.

From MIDI.org:
"In a Type 1 file individual parts are saved on different tracks within the sequence. In a Type 0 file everything is merged onto a single track"

https://www.midi.org/articles/about-mid ... midi-files

From MIDI spec 96-1-3, "The Complete MIDI 1.0 Detailed Specification":

Formats 0, 1, and 2

A Format 0 file has a header chunk followed by one track chunk. It is the most
interchangeable representation of data. It is very useful for a simple single-track player in a
program which needs to make synthesizers make sounds, but which is primarily concerned
with something else such as mixers or sound effect boxes. It is very desirable to be able to
produce such a format, even if your program is track-based, in order to work with these simple
programs. On the other hand, perhaps someone will write a format conversion from format 1
to format 0 which might be so easy to use in some setting that it would save you the trouble of
putting it into your program.

A Format 1 or 2 file has a header chunk followed by one or more track chunks. Programs
which support several simultaneous tracks should be able to save and read data in format 1, a
vertically one-dimensional form, that is, as a collection of tracks. Programs which support
several independent patterns should be able to save and read data in format 2, a horizontally
one-dimensional form. Providing these minimum capabilities will ensure maximum
interchangeability.

MIDI Files contain two types of chunks: header chunks and track chunks. A header chunk
provides a minimal amount of information pertaining to the entire MIDI file. A track chunk
contains a sequential stream of MIDI data which may contain information for up to 16 MIDI
channels. The concepts of multiple tracks, multiple MIDI outputs, patterns, sequences, and
songs may all be implemented using several track chunks.

A MIDI file always starts with a header chunk, and is followed by one or more track chunks.
MThd <length of header data>
<header data>
MTrk <length of track data>
<track data>
MTrk <length of track data>
<track data>
...

Header Chunks

The header chunk at the beginning of the file specifies some basic information about the data
in the file. Here's the syntax of the complete chunk:

<Header Chunk> = <chunk type> <length> <format> <ntrks> <division>

As described above, <chunk type> is the four ASCII characters 'MThd'; <length> is a 32-bit
representation of the number 6 (high byte first).

The data section contains three 16-bit words, stored most-significant byte first.

The first word, <format>, specifies the overall organization of the file. Only three values of
<format> are specified:

0 the file contains a single multi-channel track
1 the file contains one or more simultaneous tracks (or MIDI outputs) of a
sequence
2 the file contains one or more sequentially independent single-track patterns
More information about these formats is provided below.
The next word, <ntrks>, is the number of track chunks in the file. It will always be 1 for a
format 0 file.

[dRowAudio]

Thanks for the info. I've had a closer look and it does look like the files are written as "Type 1" so that's correct but when rendering, the MIDI output from all the tracks is coalesced in to a single track. I think this is where it is going wrong.
Each track should be rendered in to a new MIDI track in the file.

Hopefully this shouldn't be too difficult to change but right now we're focusing on stability and plugin compatibility so I can't really change the way MIDI is rendered until that is stable. I'll try and get to it in the next few weeks though.

[zzz00m]

Thanks for the info. I've had a closer look and it does look like the files are written as "Type 1" so that's correct but when rendering, the MIDI output from all the tracks is coalesced in to a single track. I think this is where it is going wrong.
Each track should be rendered in to a new MIDI track in the file.

Hopefully this shouldn't be too difficult to change but right now we're focusing on stability and plugin compatibility so I can't really change the way MIDI is rendered until that is stable. I'll try and get to it in the next few weeks though.

Awesome! Thanks for acknowledging that.

That was the conclusion I had come to that when opening the Waveform MIDI file in my primary DAW (Sonar), it was flagged as a "Type 1", yet when opened all track data in the file was in a single track.

I found that when opening the same MIDI file in Reaper, it asks me if I want to import the MIDI channels as single-channel items on multiple tracks. Then by exporting project MIDI from Reaper I can select either "Type 0" or "Type 1" MIDI file, which I can finally open in Sonar with multiple tracks.

Maybe Reaper is smarter because it asks the user what to do, rather than just relying on the file header.

Looking forward to the fix!

Thanks again!

[bungle]

Reaper is smarter because it has a vast amount of users who input their needs on their specific use case, so Reaper ends up with a lot of options, Tracktion does not have such a vast userbase and for a long ling time many users where ignored, lets see if this current crop of owners change that.

[zzz00m]

Reaper is smarter because it has a vast amount of users who input their needs on their specific use case, so Reaper ends up with a lot of options, Tracktion does not have such a vast userbase and for a long ling time many users where ignored, lets see if this current crop of owners change that.

I wasn't actually comparing Reaper with Waveform.

Reaper is smarter than Sonar as far as actually importing MIDI files.

Sonar apparently takes the file without questioning the format and asking what to do with the tracks. Sonar is probably compliant with the MIDI spec, but that is why I noticed the discrepancy here.

I keep Reaper around for DAW testing and comparison because it does some things differently with tracks and routing, and is good for testing plugins. It also has a few nice new features, such as ripple editing, that has yet to be implemented in Sonar. It is a young product, without decades of baggage that make some feature changes difficult. Like Tracktion, it apparently has a group of enthusiastic users who are trying to make the product better. I look forward to seeing Waveform develop into a strong creative composition tool that it has the potential to become. Although I think it would be better to learn and use only one tool well, it seems that there is not one ultimate DAW that does everything the way everyone needs it to.

So far, from what I can see, the Tracktion devs are very responsive. I also noticed that they were quick to address your other recent concerns ...

[bungle]

Actually in reality Reaper is older than Tracktion if you remove the "Mackie years"
Always keep Reaper, no other host will ever be Reaper, Reaper has become a cumbersome behemoth that takes a while to set up for a new user, but once it is set up and learnt it is more of a toolkit than any other host out there.
Tracktion has a quickness to it for recording basic band stuff that not many can compete with, but it lacks massively when any kind of micro/quick editing comes in to place (Audio here, the MIDI is getting better to be fair) hopefully the developers will take note and push forward with this side so that it can become an amazing fast tool for editing too.
However while Tracktion developers may take this on board and make it a great editor too, it will never be Reaper and Reaper should always be kept in your toolbox, quick example....
I had 600 drum kits that i had to convert from Maschine to Akai MPC format, the mapping is all completely different, there was no app around that could change the mapping of the MIDI patterns.
Twenty minutes experimenting in Reaper with actions and i had created my own action macro that saved me probably a week or two in manual remapping.
Reaper is a cumbersome behemoth but it is the most likely candidate to save your life in a pinch in the studio.