I don't remember seeing anything like this mentioned in the midi spec.

I'd rather assume/expect that the number of tracks available - on average - has increased a LOT over the years, and exactly how each piece of software handles this will be subject to some variation. So I'd expect possible 'loopholes', and plan accordingly.

If you use 100 tracks, and a given channel is used in a number of tracks spread through the file, and you do a PC for that channel in tr 99 I'd not expect that change to take effect immed, it might take an extra ms or so? If it was important that this did NOT happen, then put the PC in the first Tr to use that Channel. Help the system a little bit?

Of course, the Virtual Synth of the Tone Module may have a hand in things as well. Either of those may maintain a table re 16 (or whatever) channels each set to voice/sound xxx. At what point in the 'Processing Cycle' does that get updated?

Geoff

Tracks are only a concept in MIDI files. Tracks are only visible to the software that reads the MIDI file. Once the MIDI file player sends MIDI messages to a MIDI device, the MIDI device has no way to know what track in a MIDI file a MIDI message came from. So if multiple tracks contain MIDI messages for the same channel, the MIDI device can only see that the messages are for the same channel.

Although a MIDI file track can contain messages for multiple channels, and a MIDI channel can appear in multiple tracks, this makes it confusing to tell what is going on. When creating MIDI files, it is usually a good idea to keep the messages for a channel together in one track so the MIDI file is easier to understand.

Thank you for the replies.

[quotePost id=19487]Tracks are only a concept in MIDI files. Tracks are only visible to the software that reads the MIDI file. [/quotePost]

Where in the MIDI file spec are tracks defined? To parse MIDI files into other formats, it's unclear whether a program change for some channel on track A should change the program for the same channel on track B. Even though devices receive a single stream of messages, I would expect the specifications to define the scope of program messages in a track (and equivalently how tracks should be interpreted by software translating to other formats).

Tracks are referred to in the midi spec, but only in the most general way. More or less, as in 'tracks exist, but they're nothing to do with us'!

My experience regarding converting midi files is that the receiving file will try to leave the existing tracks as they are, as far as it can (i.e. the structure/contents of the existing tracks do not break any rules for the new file, otherwise data could be lost, although you should get a warning message).

Some software I use, on loading a midi file, may offer to alter the track structure (I usually say No to this), for example, if a track contains data for multiple channels it will want to split the track to form separate tracks for each channel.

If the data was seen as a problem for the system loading it, again, I would expect it to issue a warning.

Most systems will load the data from the midi file into it's own data structures, in RAM. This data will probsnly have no bearing at all with the structure/format of the data in the midi file. Your query here should REALLY be with the structure of the data stored in RAM by the software you're using? If you have changed the data in any way, then the system should save a new version of the midi file, otherwise the data in RAM would be discraded.

Geoff

[quotePost id=19488]Where in the MIDI file spec are tracks defined?[/quotePost]
In the Standard MIDI Files Specification, tracks are mentioned in the section about "Formats 0, 1, and 2" on PDF page 7 (printed page 5). Unfortunately, as Geoff said, the spec doesn't have the kind of details you want.

The last few pages of the specification (PDF pages 14 to 16 or printed pages 12 to 13) describes every hex byte of an very small example Format 0 MIDI file and Format 1 MIDI file with the same notes. The example Format 1 MIDI file splits each of the three channels used into their own tracks. Although there is nothing in the specification the forces channels to be on unique tracks*, this small example in the spec could be interpreted as some small evidence that this is suggested or commonly expected behavior.

*In fact there is a sentence in the later RP-019 that makes it clear that a track is allowed to contain multiple channels ("Each track of a MIDI File can contain one MIDI stream, including SysEx and up to 16 channels.") I would still suggest it's usually a good idea to stick to one channel in a track for maximum clarity.

[quotePost id=19488]To parse MIDI files into other formats, it's unclear whether a program change for some channel on track A should change the program for the same channel on track B.[/quotePost]
In that situation, I agree it can be unclear. Did the person who made the MIDI file really intend for a Channel 1 Program Change in Track 2 to apply to the Channel 1 Notes in Track 3? Or did they make a mistake?

The only thing I can do is suggest that people who make MIDI files avoid confusing situations like this and keep all the messages for a channel on the same track.

People converting MIDI files to other formats that encounter a channel on multiple tracks will have to make case-by-case judgements to decide if the messages were meant to go together or not.

The RP-019 document I mentioned added a new Device Name meta event that lets you specify that different tracks go to different MIDI devices. There is also a non-standard Port meta event that has the same purpose of indicating a track should go to a different MIDI device. Unfortunately, the Device Name meta event isn't usually supported by MIDI file software, and the non-standard Port meta event is supported by some but not all MIDI file software. However, if you see tracks with different Device Names or Ports specified, that suggests the person who made the MIDI file intended the channels in those tracks should not affect each other.

I actually am just now coming across this with my current project. My MIDI player/software uses the most "recent" program change on a channel, in track order. So if multiple tracks contain a program change at the same time, the last track (higher track number) with one for that channel prevails. I had a percussion track with a snare, which had a program change that I wanted, and then a second track with the same snare, but the program change was the default 0, so no matter what I changed the first one to, nothing seemed to happen. Learn something new every day 😉

Nic,

I did manage to have a bit of a play with the midi file (plus attached bits) that you posted, it took a while as MACOS has done it's usual messing about so I had to disentangle the actual midi file from everything else.

Firstly, I did mamage to 'play' the file. and I did not notice anything unusual, so if there were any PC instructions out of place I did not hear them. Maybe you could be more specific about the bar or the time spot where anything unwanted happened.

Given when we were discussing above in this thread, when I looked at the data in the file I see that Track 2 in fact contains all the 'settings' for all the Channels/all the tracks. Not very tidy, but everything is there rather than spread about the other tracks, which rather undermines your query? The software I was using (SynthFont, which allows viewing of the Events List as well as playing the midi file using VST) shows quite a lot of un-necessary commands (maybe they were once relevant, but over time other controllers have been removed but separate related bits have not?)

The bulk of the percussion has been split over a number of tracks, so each track is for one percUssion instrument, but all show as Channel 9 (i.e. 10). There is nothing wrong with this, but it is a potential confusion. Also, this file relies on the fact that Ch 10 defaults to percussion, so no instrument is set explicitly (i.e. there is no PC command) - this is OK if you can be sure that nothing else has messed with the default setting. Another track shows as Piano (PC 0) which is the default, it is quite possible that Piano is intended but I cannot be sure. Again, there was no explicit PC command?

Regarding the track that is clearly intended as a 'control track), the normal think would be to use a Delta time of Zero for everything, but here Track 2 has different delta times for each line so if you can be sure that all the times are valid then OK, otherwise things are risking messing some timings up.

Generally, some of the tracks could do with quite a bit of a tidy up?

Geoff

A bit late to the party, but here goes.

This has to be one of the strangest files I've seen in my 35+ years of messing about with MIDI!

First of all, were you aware that this file started its life as a commercial file?
In the track marked as "#TR909 Bd" at measure 30 there is a copyright notice dating the file to 1995. I suggest you look at this.
It suggests the copyright owner is a company in Holland.
I suspect there's no problem if you just want to learn from the file and not use it in any way publicly.

Secondly there's the proper song name embeded in the 'control track' calling it "Rainbow In The Sky". Were you aware?

Next, as has been said before, all the Program Change commands for the 12 MIDI channels used (i.e. 1-10 & 12-14) are put together, one for each channel, in the initial 'control track'. This is, in my experience, a most unusual way of doing things. I can't recall ever having come across it before.
It's not 'wrong' per se, it's just extremely confusing. Maybe that was the intention of the original commercial programmer.
Normally the Program Change and associated Bank Select messages and Volume, Expression, Pan, etc. are put in each track that carries channel note messages.

Ideally the setup messages for each channel should be moved from the control track to their respective MIDI channel tracks to make the whole thing more legible and easier to understand.

Geoff, moving all these setup commands to Delta time zero can work okay with most modern VSTs but is not a good idea for older hardware.
The file starts with a GM reset and that can take hardware many milliseconds to implement.
This file has these setup commands seperated into beat two of the 1st measure - good practise.
Then all the commands seperated by a few ticks, also good practise.

My old Yamaha MU128 used to throw a "Buffer Overload" message if too many commands arrived too quickly, where some of those messages took a little time to implement.
A GM System On needs the hardware to go through all the buffers of each channel setting voice to piano, pan to centre, expression to 127, volume to 100, and so on.
The MU128 has 4 x 16 channels, so that could take, as far as I recall, 100ms, or something like that.
It's well worth looking at the Yamaha XG recommendations, which you should find a copy of here
JoSoSoft DK, thanks to Jørgen Sørensen.

I'll do some work on the file later today and see if I can post a copy of what I think it should look like later.

JohnG.

Here's an update.

We're getting off topic here, but yes, this is an "interesting" file. Aside from what is mentioned above, it contains only Bank Select LSBs. My instrument changer breaks the file if I try to save it. Sema's test-midi-files flags all of the LSBs as missing associated MSBs. Additionally, the track names are all incredibly long with tons of spaces and 3 special characters at the end of each one.
Now I need to determine why my software doesn't like it and how I can fix it. (Chances are because my LSB code assumes the presence of MSB)

In case you're interested, I think that part of the problem (re file names etc) is because the file/files have been manipulated on a MAC at some time, and it's MACOSX that has messed things up. Rather, it's done MAC things for MAC purposes and to hell with any evil non-MAC user! I've seen this before with some other files sent to me.

Geoff