Sleeping during iteration over MidiFile with merged tracks

[obrejla]

Hi, thanks for a very nice library. I just have a feeling, that there is a bug in examples...during the iteration over the messages of the merged tracks like this

for msg in MidiFile('song.mid'):
    time.sleep(msg.time)
    if not msg.is_meta:
        port.send(msg)

You actually "sleep" on every message, but as far as I understand it, in multi-track file, it usually happens that a note is played on more tracks at exactly same time, right? So in fact, when you merge it and compute relative and absolute times, you will have more message objects with the exact same time, right? And because you are iterating these "merged" messages, then each of these "messages played at the same time" will be iterated separately...and hence, separate time.sleep() will be called for each message.

E.g. you have 2 tracks and both have note_on at time 3s...so during the iteration, it will time.sleep(3) for the first message and then time.sleep(3) for the second message as well...even though they should be played at the exactly same time, right?

Am I right and the example is wrong? Or am I missing something? Or is that example only for "single track" midi file? Should there be also an example for "multi track" midi files?

Thanks a lot!

• Operating system name & version: Raspberry PI 5 - Raspberry PI OS
• Python version: 3.11.x
• mido version: 1.2.2 installed via pip

[rdoursenaud]

Hi and thank you for your interrest in mido.

The short answer is yes and no, the provided example is fine.

The long answer:

First, MIDI is a serial protocol which means there can’t be any overlapping messages. They all happen in sequence. Given these are sent out fast enough they give the illusion of simultaneity.
It has a concept of channels to address specific sounds or features in the receiver.

MIDI Files store MIDI protocol data with a few metadata to help presentation and/or reproduction. These have a concept of tracks which are not related to MIDI’s channels (Each track may contain data that adresses multiple channels).
Furthermore, 3 standard layouts are defined and commonly refered as types: 0, 1 and 2.

• 0: is a single track MIDI File which closely mimicks the "on-the-wire" protocol
• 1: is a multi track MIDI File where tracks are intented to play simultaneously
• 2: is a multi track MIDI File where tracks are independent

mido provides facilities to deal with MIDI protocol data and MIDI Files data. However, it is not a MIDI engine (yet) and will never be a Digital Audio Workstation (DAW). It does not deal with all the intricacies of processing, recording or playing back the data. It only provides simple building blocks for you to use.

The example provided is a very simple and naive approach to demonstrate where relevant data are stored in the objects. It is fine for playing back MIDI files (with one or more tracks) on a single MIDI port with loose accuracy (sleep has very rough precision). It is not its intended use though, it’s there merely to inform developers on how they can use the library.

If you want to play back complex files with overlapping events across multiple ports and/or need precise accuracy, you’d have to write the playback engine yourself or use another tool. I may add further capabilities in mido after finishing the tedious refactoring needed for version 2 but don’t hold your breath!

Confusien may arise when iterating over type 1 and 2 MIDI Files as mido naively converts these to type 0. This is where we could issue a warning maybe.

Hope this helps you understand the context and use mido appropriately for your project.

[obrejla]

Hi! Thanks for the quick answer :) Yep...so it is actually how I thaught...that it's intentional.

Confusien may arise when iterating over type 1 and 2 MIDI Files as mido naively converts these to type 0. This is where we could issue a warning maybe.

That could help understanding the problem IMHO :)

Thanks again!