SMF Header = See "RP-001_v1-0_Standard_MIDI_Files_Specification_96-1-4.pdf"
https://www.midi.org/specifications/file-format-specifications/standard-midi-files

The "division" header field is a 16 bits number, meaning the ticks per quarter note (when it is a positive number). (Pg. 4)
The delta times are expressed in ticks. (Pg. 5)
The "set tempo" meta event tells you the quarter note duration in microseconds. (Pg. 9)
tempo / division = quarter note duration in microseconds / ticks per quarter note = duration of one tick in microseconds. To convert microseconds into milliseconds, just divide by 1000.

Nothing in those calculations requires the time signature. The denominator of the time signature indicates a notation figure, for instance 4 = quarter note/crotchet. Even if the song is notated with a different figure, like 8 = eighth note/quaver, this doesn't change the division, tempo or tick values (only the notation representation).

Hello,

Trying to understand what this is about.

The Delta time represents a 'wait state' between the start of one event, and the start of the next. Everything in a midi stream does something, but usually this does not affect delta times. Why should the Reset commands?

There may be a problem if there were three events, all critically timed, all immed following each other, or following with a delta time less that the times suggested (50 ms or 100 ms). THEN, the delta time available between the events would not be enough to accommodate the time required to process the reset, and so the following event would be delayed. So maybe something would need adjusting.

Normally, the reset instruction would NOT be so time critical, so it could be moved to a position where there WAS enough delta time to accommodate it?

Note that ADDING delta time to one track would require adding delta time at the same point to ALL tracks. Not such a problem if you're using a type 0 midi file, but they are not common these days?

Or am I getting confused?

Or would this need to work to a different logic, depending on the 'system' being say a virtual system where the same 'computer' is doing everything, or where the playing software is on one computer whicj is merely sending the data to another device ('computer') which is processing the data and which separately may be suffering the time delay required to complete the processing.

Geoff

I am making a MIDI instrument editor that lets you change any instrument in a MIDI file to any other instrument. For maximum flexibility and functionality, I am trying to do everything as "official" as possible. The specs for GM, GS, and XG all state that there is a certain wait period after each of the resets before the system can be expected to fully respond to the new reset settings. I'm allowing insertion of each of the three main types of reset SYSEX commands in to MIDI files that do not contain one already. If it does already have one, then I will attempt to modify it to the new type selected by the user (which will work in most cases, but some files are just too complex for it to work properly). On a computer, these timings are probably irrelevant. On real MIDI hardware, especially older devices, not leaving enough time after a reset could cause undesired or delayed playback of the beginning of the tune. So to save some trouble, I plan to add the listed amounts of delta time after each insert (and to all other tracks hopefully, and hopefully with the resets at actual time of zero, or it could get hairy).

So if the resets are already there, I will not need to adjust any delta times (except maybe when changing to XG). Otherwise, I want to add in the extra time for safety's sake.

Or, that's how I currently understand it anyway 😉

Just a comment, I think you've got the timing reversed for the resets.
As I read it it's 100ms for the GM reset, which has to reset pretty well all controllers back to their default state.
Then 50ms for for an XG or a GS reset.

In assorted Roland documentation, I see this for GM1 System On, GM2 System On, GM System Off, and GS Reset:
"* There must be an interval of at least 50 ms between this message and the next."
For example, in here (but I originally found it in another)
http://lib.roland.co.jp/support/en/manuals/res/62472403/F-120R_RP301R_MIDI_Imple_e.pdf

In Yamaha documentation, I see this:
...
"Since approximately 50[ms] are required in order to execute this message, please allow an appropriate interval before transmitting the next message."
Err, well, in the SW1000 docs it only has 50ms for XG System On and GM System On.

I'm actually not sure where I saw the 100 ms for XG System On. I tried going through my history for the past few days and can't find it again. My guess is it was for a super old device.

I did see a couple of references to needing 100 ms for GM System Off, but I think those were super old Roland manuals, plus I'm not inserting any "off"s.

So maybe I'll just stick with 50 ms for everything and hope for the best (and chances of it affecting anything I'LL ever see IS pretty slim.)

Jason,

If you go adding delta time into a midi file, what does this mess up?

It may not be important for some things, but the timing, and the beats, relate to the bars in the music, and these will not be affected by the extra delta time, so a lot of notes will be adrift from the bars. This may not affect the sound? But if the midi file is loaded into a score prog, it will show up, and make a mess. Pauses added into the start of each bar?

If a piece of music is legato (?) such that the notes fill the bar, then the extra delta time will cause the notes to spread over into the next bar?

If anyone later tries to do any sort of quantize on the piece, will this totally mess things up?

Oh, what would this do to the 'oiano-roll' display as well, which also uses the bar structure?

Just adding some delta time could be a major problem.

I still think that it would be far better to find a space in the midi data where there is enough delta time to accommodate the ?? Reset, then you don't need to add anything in?

Geoff

[quotePost id=10461]Jason,

If you go adding delta time into a midi file, what does this mess up?
[...]
I still think that it would be far better to find a space in the midi data where there is enough delta time to accommodate the ?? Reset, then you don't need to add anything in?

Geoff[/quotePost]Hmm, I am actually trying to NOT mess things up 😉 Honestly, I have no idea how I would try to find a spot to fit it in. There are too many things to consider if doing that. Ideally, if ALL MIDI files followed recommended practices (leaving a full measure "empty" at the beginning of the song for the system to do it's thing) then it would be a piece of cake just popping it in. I suppose I could insert an entire measure's worth of delta time, but that seems... excessive? But maybe also correct. I actually hadn't thought about how the offset would affect most of the other things you mentioned, because in my head the song was still "together" even if shifted over slightly.

So, maybe I just don't worry about adding any delta time after all, and hope for the best. And again, chances that I will ever see/hear anything messed up by not having that extra 50ms are pretty darn slim. And then someone can send me a bug report if it causes a problem for them 😉

And now I'm curious how other software handles adding a SYSEX reset to an existing song. I know some players can do it, but maybe they do it before starting the actual song.

No, recommended practice is not a full measure "empty", it's a measure empty of music notes so that all the necessary setup messages, such as these SysExes, can be inserted here.

There are many very useful files authored by/for Yamaha XG demonstration (and for Roland GS) that warrent analysis at the List View level.
(Actually, it's how I learnt much of what I know about MIDI programming.)
They simply set up with a GM system on at 0001:01:000 (at 480 TPQN) then (most often) the XG on occurs at 0001:02:000.
(Leaving that much time for the GM on is an overkill in my view.)
All the subsequent setup messages the occur from 0001:02:120 onwards.
See the attached setup picture with the master track at the top and the first instrument track below.

The calculation is straightforward.
At 480 TPQN 240 ticks are 250 milliseconds. Very approximately 1 tick per millisecond.
At 120 bpm there are two beats per second in an X/4 measure, e.g. 4/4. (So a 4/4 measure takes two seconds to complete.)
Therefore 1 beat of 4/4 at 120 BPM is 500 milliseconds long.
Halve the BPM to 60 and each tick is twice as long, double the BPM and each tick is roughly half a miilisecond.

Look around for some examples of XG files authored by or for Yamaha and you might be amazed what you can learn from them.

Just my 0.02c worth.
JohnG.

Jason,

Yes, I agree with your comment about 'not worrying'.

As you say, there is every chance that no problem will be noticeable.

To cover yourself, your notes for any user could explain this point, and say that the software is trying to do something automatically that maybe should be done intelligently, and that this MIGHT lead to missing or delayed notes immed after the reset. If this DOES happen, then the reset event should be moved slightly (I assume to an earlier point) where it will not cause the problem.

Geoff

[quotePost id=10469]No, recommended practice is not a full measure "empty", it's a measure empty of music notes so that all the necessary setup messages, such as these SysExes, can be inserted here.[/quotePost]
Haha, yes, that is why I had quotes around "empty". I meant empty of notes. 🙂 Thanks for all this info. I do have quite a few official XG MIDI files to look at, and I had noticed in the few I checked a while back that there seemed to be a "huge" gap between the two resets, but often times there was other stuff in between.

I'll have a look through assorted files that I have that I know have the different types of resets to see where they all are located.

Hi Jason,

Yes, it's also not uncommon in many professionally authored files to see the GM reset at the very start of measure one, and the XG reset about half way through the first 'beat'.
My own feeling is that this is probably about right.

Some years back I found a file that was absolutely choc-a-bloc with SysEx and other setup messages, that caused an MU128 (with additional PLG cards) to complain with an "input buffer full" message. As I recall, the file was using three ports of the MU128 (i.e. more than 32 channels) and setting up a DX, a VL and an AN card.
Moving all the messages along a bit and leaving sufficient time for the two resets to complete cured the problem.

JohnG.