vgmrips

In actual hardware, writes to synthesizer registers/memory typically have a mandatory waiting period before another write can be made, ranging from a few to a few hundred cycles depending on the chip (and some chips have different delays for different registers/memory). How would this typically look in a VGM file?

Say we have a synthesizer that requires 1/132300 s (1/3 sample) delay between writes. If a VGM had 4 back-to-back writes to this synthesizer, there would be 1 sample time between the first and last write. Would this be represented in VGM as write, write, write, delay 1 sample, write, or would the delay be implicit and you would simply see 4 back-to-back writes?

It is really interesting how people regularly come up with the idea of "implicit" delays in VGMs. (Yes, I've seen that question multiple times now.)

Short answer: There are no implicit delays. If a game writes 4 commands at 132300 Hz, you will see: [command 1] [command 2] [command 3] [delay 1 sample] [command 4]

And there are a few very good reasons for NOT having implicit delays:

• It is not manageable. We have one stream that mixes all commads from all chips.
  By doing implicit delays, you'd have differing delays depending on what chip you'd write to.
  And then you have things like MegaDrive + 32X, where 2 processors generate commands simultaneously (MD -> YM2612/PSG, 32X -> PWM). Implicit delays would mean that one causes to wait for the other, which is definitely not true.
• For a lot of chips we don't know how much time you'd need to wait. Some of them (e.g. SN76489 and OPLL) don't even have a status bit and the manual only recommends certain wait times.
  OPNA and OPL4 also require different wait times depending on what register you write. Implicit delays would make this way more complex than it has to be.
• I have yet to see any format that does implicit writes.
  I often compare VGMs to MIDI files. I really can't imagine how MIDIs would look if you'd assume 1 ms of delay (regardless of the set tempo) after every note and command.

Furthermore a VGM is the log of the activity of a sound driver, which is already expected to behave correctly with regard to waiting for a chip to respond (and each driver will do so differently, with different results for the exact amount of time waited). Therefore, the necessary delays should already be encoded in the timing of the commands and the explicit delays in the VGM stream? Or does that not happen in practice and hardware VGM players have major issues?