Now.

Some of you may not be familiar with what maybe is.

It stands for musical instrument digital interface, and you may be a word.

It is some sort of music format from decades ago.

You'd be right.

But what's interesting about MIDI is it doesn't transmit audio it all.

There is no sort of way forms off samples sent the committee protocol instead, Midi is a sequence of timing events that could be supplied to musical instruments and equipment as and when necessary.

I think the original creators off the middIe specifications were exceptionally clever and very forward thinking, and as a result, the middIe former has really stood the test of time, so much so that it could be modified with ease to accommodate new developments in the industry.

And it has also become ubiquitous across the industry.

It fully satisfies the needs off, making sure that musical instruments and equipment can talk to each other in a sensible way.

Now, if you're not interested in music, that's very know that Midi can also be used as a general purpose timing protocol.

Um, maybe I'll talk about that a little bit later on.

But from a programming perspective, I think that the middIe final protocol is quite interesting, and I wanted to explore it in a video.

So let's close down south synthesizes and bags full of cables.

Let's get started.

And I thought we'd start with a very brief MIDI primer.

Here I have some sort of digital instrument.

It could be a synthesizer, but these days it could really be anything at all.

And in principle, the user presses the keys on the keyboard.

On it emits some sort of sound that we can hear.

But unlike an actual instrument, it's completely synthetic.

The keys of electronic switches, which switch something on or off on accordingly.

A sound is produced now because it's digital.

We don't need to rely on the clumsiness of a human hands to press the switches.

We can, of course, send an electronic signal instead, so we could send something like an on off event for a particular key.

Has the key been pressed, or has it been released?

We need to identify the key, so that could be a particular note and there may be other parameters that we want to send to, such as How hard did we press the key?

This is called Velocity on These additional parameters allow all sorts of expression in the musical plane we can package.

You're all of this information as some sort of event and send it to the instrument.

Now is the name implies.

This event only does one thing, but of course, for a musical piece, you want to do lots of things, so it's likely we're going to want to send a sequence of events.

But it's no good just smashing out these events as fast as we possibly can welts.

The entire song will be played well instantaneously.

It wouldn't sound very good on as music is a temporal medium.

It's important that we include timing information into these events.

So let's say at the beginning of the song, I want to press this particular note, but I only want to hold it down for a certain amount of time, maybe 100 milliseconds or so.

Therefore, I augment the packet with the information to say that this event is occurring 100 milliseconds after the previous event and subsequently, we might wants this event toe happen 50 milliseconds after the previous event.

In effect, we send the Delta Times between our events and sending the Delta Time is quite an important thing because what if we wanted to events to occur simultaneously?

Well, we just specified Delta Time Off zero.

So even though these events have been transmitted in Siri's, whatever is receiving these events of the other end can accumulate them based on their Delta times and perform them simultaneously.

Now on the actual hardware itself, it doesn't work quite like that's very difficult to do.

Variable numbers of things simultaneously electron ICS hardware.

But the principle is that you run your electronics hard, work far faster, then you're sending these events.

So these are, let's say, we're operating in milliseconds here.

The process on our digital instrument could be quite happily operating in nanoseconds, and so the end result is that it feels like these are happening at precisely the same time.

It's imperceptible to was rather boring and limited human beings, and that introduces two interesting properties of the middIe format.

Firstly, it only has to be sufficient for the bounds of human perception, but Secondly, it is undeniably riel.

Time on we'll see is we're exploring the middIe format that were possible.

Keeping things synchronized and quick takes a priority.

Now there's one was being a programming that I'm also a bit of an audio nerd, and I have quite a sophisticated setup for dabbling about with home audio.

I don't consider myself a skilled musician by any means, but I like to think that I am, and I try and play my best Whenever you start working with audio.

One of the primary concerns you have is Leighton.

See, in my experience, when I'm clumsily hammering my keyboard with my fists, I start to notice that I can become out of sync if there's a latent see greater than 30 milliseconds, and that doesn't seem like a lot.

But it does demonstrate how good brain is.

Trying to synchronize audio to real time actions within your body actually becomes very difficult to play anything as the legs he gets quite large.

And even though I'm not that good on a keyboard, I am actually quite okay with a good time.

Guitar is typically quite a fast instrument to play on when I've dabbled with real time audio effects in the past.

One of the things I noticed is that plucking a note on the guitar, I could only tolerate a far lower Leighton.

See had to be about 15 milliseconds before hearing this sound.

But that's my fingers would be come out to sync with what my brain thinks they're doing.

The new resources of Leighton see in an audio set up.

But as you go towards the higher end that Leighton see tries to reduce.

But where is this late?

See coming from, well, festival physics.

You can't have zero latent seen any kind of system.

But originally when digital audio workstations were starting to be developed and started to be available to the consumer, the latest he was in the cables and the connections between the pieces of equipment, you could only transmit digital signals at low speeds.

Throw into the mix the legacy of converting those signals from digital to analog and then, at the time, some rudimentary effects processing on.

Eventually you end up by pressing a key on a little bit later on, only hearing the final processed sound.

Interestingly, as we've progressed with the technology, the communications bandwidth has got much faster.

We got things like USB two USB three now, but at the same time, we're demanding a lot more from our C P used to produce more interesting effects and more realistic sounds.

The one thing we have going for is an audio is that we're still talking about Miller Seconds hit into a computer.

A millisecond is an eternity.

Anyway.

I'm getting sidetracked.

Let's get back to the middIe video.

There's several layers to a MIDI sequence.

At the most bottom layer is the concept of a channel where each MIDI event is associating with issuing information to a certain channel on that channel typically reflects a specific instrument on it's usually down to your studio.

Set up or dedicated.

MIDI process is to make sure that these events are sent to the appropriate destinations.

In the middIe message, you can have a book to 16 channels, which doesn't seem like very many, but this is where the second layer comes in.

The concept Off tracks tracks are sequences of midi events that are occurring in parallel on here.

In this new track, some of these events may be mapped onto the same channels that we already have a peer.

But other events can be mapped too well, new channels, so we can quickly build up quite a large library of virtual instruments before we go on.

Dissect the MIDI file format for ourselves.

I thought it would be useful to actually look att a MIDI file and I found this piece of software it's free to download, but they encourage a donation simply called MIDI Editor.

Bye, Marcus Schwank.

It's very nice.

It's very simple, but it allows us to analyze the tracks and the channels, and the message is in some detail.

And it's typical of media editors to look a bit like this in the Y axis of this frame we've got which particular note on the keyboard is being played.

Now they're always keyboards, even if the instrument doesn't have a keyboard.

Say it's a drum kit.

Of course, the drums can't play notes, but you could assign different types of drum to different keys.

In this editor.

The tracks are all over, laid on top of each other on the old, different colors.

Here, I've isolated Track one, and I'll click on this big event in the middle and you probably heard it just made a sound.

The nice thing about this.

Editors that allows us to analyze the event in information that might be relevant to a programmer so we can see we've got this on ticking off tick.

That's the Delta time from the previous event.

It's actually visualized here in what is called wall types.

This is really time, but the event itself will only contain the Delta to the previous event.

It tells us that he's playing notes 77 and it's using a velocity of 100 so really hit that key heart on the channel it's associated with is Channel zero.

Now.

Don't forget, Midi doesn't contain any audio information.

It's simply a way of rooting thes event packets around a system.

So Channel Zero needs to be associate ID with something that produces sound.

And in this case, Channel zero has been mapped onto string ensemble one.

In fact, we can have a listen.

These instruments on the site are virtual instruments provided by my Windows operating system.

They sound a little bit flat and old fashioned typical middIe sounds.

If you're familiar with those, and that's because on window she get this Microsoft GS wave table, since which is a basic selection off virtual instruments.

In fact, I can change the channel to something else.

So let's emulate a piano sound instead.

One of the nice things about events in time and pitches is they can be visualized Ana to de Graff like this, and so I think that's what we'll aim for.

First will try reading in a midi file on visualizing it, and I just love watching the complexity of things like this.

When it all comes together, it produces something round, like it a lot.

As with anything that is considered a standard somewhere, there exists ex specifications for that standard, and this is the middIe specifications official website, and it contains lots of information about how we can interpret what's going on inside a file files a little bit different to just regular midi streams between instruments as they contain additional information that the instrument simply don't care about.

Regardless, there's nothing will see in my code today that we can't find listed somewhere on the specifications website.

Now, as usual, I'll be using the OLC pixel game engine for the visual ization.

Quite a high definition one, this time at 12 80 by 9 60 in one toe, one screen pixels.

However, interpreting the MIDI file we're going to be doing from scratch so it doesn't require the pixel game engine to understand how the MIDI file format works.

So we'll be coming back to all that later on because I want to develop a class that I can use in subsequent projects.

I'm going to create a simple MIDI file class.

I'll give it a constructor on all of the work is going to happen in a function called Pars file, which takes in a path to that particular MIDI file.

So just for convenience, I'll add an additional constructor, which can take in the path and just call the past file function.

Now I'm going to treat the MIDI file as a stream because, in effect, many messages are sent as a stream.

You don't really know what's going to happen next, And so maybe by constraining ourselves to work with the file stream will produce better code for working with MIDI streams in the future.

So I'm just going to create a standard input file stream object, open the file in binary mode on.

If there's a problem, I'm going to return false.

The first curiosity when it comes to Midi is understanding how to be values from the file.

Midi was developed way back when literally billions of years ago, but when processes used a different bites order to store numbers than what we're familiar with on our modern desktop computers, So every time we read, say, four Bites interview, we need to swap all of the bites around.

So I'm going to create some little Lambda functions to do just that.

I've got one here called Swap 32.

It takes in an unsigned interview.

Now that will be a different bite order than what we actually want.

So the contents of the land of function simply swaps all of the bite's over.

I'm also going to create one for 16 bit numbers, too.

As I mentioned before, MIDI files contain lots of additional information that the instruments don't care about.

But perhaps the editing system for that file does so they can contain things like strings.

Fortunately, strings in the file are going to be stored sequentially on will know the length of the string in advance, so I'll create a little Lambda function.

Read String, which takes in that length on allows access to the input file Stream on just successively reads the characters on depends them to a standard string object.

Now we get to the second curiosity with MIDI files.

Most MIDI files will never contain information that requires more than seven bits to store, and that might seem like an unusual design choice for platforms, which routinely work with a bits.

But some way it does make sense.

Firstly, you want to minimize the amount of bandwidth you're going to transmit, as hopefully this will reduce the lake and see.

But also 127 in terms of musical equipment is quite a lot of different things.

For example, if you had a keyboard with 100 and 27 keys on it, that's going to be quite some keyboard.

Alternatively, if you want some sort of expressionistic tool included in your mini event, while 127 levels of differentiation within that expression is quite finite on high resolution.

So this comes back to that human perception on real time thing we were talking about earlier.

It's good enough to get by but limiting yourself to seven bits does start to raise some interesting problems with the file.

Former.

So what if we wanted to, for example, reading a 16 bit number 32 bit number.

They're on several occasions.

Situations where?

127 isn't he?

No, specifically, but timing the Delta Time between the events that could be many thousands off ticks, clock cycles, milliseconds, whatever we want to call it.

And so we can't store that in just seven bits alone.

And this is where I think the Creator's admit he did something rather clever.