The MIDI Forum

The Standard MIDI File specification allows you to store MIDI clock messages in the F7 "escape" or "continuation" form of the sysex event. To check if your MIDI file player will actually send MIDI clocks that are stored in a MIDI file like this, you can try playing the attached MIDI file that contains four 4/4 measures of MIDI clocks at 95 beats per minute.

If this works, then the next step is to explore if there's a way you can make a MIDI file containing MIDI clocks at the right tempos for your tracks. For example, you can try editing the example MIDI file in whatever MIDI file editor you normally use. Maybe you can copy and paste the measures to whatever length you want, modify the starting tempo, and insert any other tempo changes needed.

(If editing the example MIDI file doesn't work, it might take more technical work to generate a MIDI file. For example, to make the attached MIDI file I used the MIDI sequencer software Sekaiju to create the first event and saved it as a MIDICSV file, then used spreadsheet software to help me generate the other events and pasted them into the MIDICSV file. I can explain further, and/or maybe someone else here can come up with alternative ideas to generate a MIDI file.)

Hello,

I'm not really sure what you're looking for here.

If you're talking about live performance, then the midi data being transferred may well include no timing information, as everything is supposed to be happening in real time. Your midi interface, for example the MPU-401 type, may well be generating timing data, but this may well be for 'internal' use only?

If you are using midi files (SMF) then really this file contains all the timing data you might need anyway, so there should be no need to add anything extra. However, the data may not be there in the specific format you're thinking of?

I assume you're thinking of the bar/beat type of format, where the bar is a number from 1 to whatever, and the beat will show as 1 to 4 or 1 to 3 (or whatever) depending on the time signature of the music. Many software systems will display this data while playing a midi file. BUT, it is CALCULATED on the fly while the file is being processed, based on other data in the file. This calculation is not a big deal. There is no point to add it, as it can be calculated anyway.

The problem then is that most playback hardware does not need this information, and does not display it. A computer system probably will.

Also, normally, the purpose of listening to the midi file playback is to listen to the music, and NOT to a boom-bip-bip-bip-boom-bip-bip-bip addition.

Some software MIGHT have this facility as an option, I'm not aware of anything.

I have written my own software to play midi files, this does NOT do this, but it COULD. I'd think that this 'beat' track could be sent out separately from the computer?

So, the solution to your question is really dependant on the software/hardware that you're using? I'm not sure there is any solution within the bounds of MIDI?

Geoff

The Standard MIDI File specification allows you to store MIDI clock messages in the F7 "escape" or "continuation" form of the sysex event. To check if your MIDI file player will actually send MIDI clocks that are stored in a MIDI file like this, you can try playing the attached MIDI file that contains four 4/4 measures of MIDI clocks at 95 beats per minute.

If this works, then the next step is to explore if there's a way you can make a MIDI file containing MIDI clocks at the right tempos for your tracks. For example, you can try editing the example MIDI file in whatever MIDI file editor you normally use. Maybe you can copy and paste the measures to whatever length you want, modify the starting tempo, and insert any other tempo changes needed.

(If editing the example MIDI file doesn't work, it might take more technical work to generate a MIDI file. For example, to make the attached MIDI file I used the MIDI sequencer software Sekaiju to create the first event and saved it as a MIDICSV file, then used spreadsheet software to help me generate the other events and pasted them into the MIDICSV file. I can explain further, and/or maybe someone else here can come up with alternative ideas to generate a MIDI file.)

Thank you very much for your response! I'll try playing back the file with the uTrack as soon as I get a chance. I already imported the file to Logic and uTool, the software editor for uTrack. Logic imported the tempo information but didn't show the file as a region. uTool did recognize the file being 0:12 long.

Hello,

I'm not really sure what you're looking for here.

If you're talking about live performance, then the midi data being transferred may well include no timing information, as everything is supposed to be happening in real time. Your midi interface, for example the MPU-401 type, may well be generating timing data, but this may well be for 'internal' use only?

If you are using midi files (SMF) then really this file contains all the timing data you might need anyway, so there should be no need to add anything extra. However, the data may not be there in the specific format you're thinking of?

I assume you're thinking of the bar/beat type of format, where the bar is a number from 1 to whatever, and the beat will show as 1 to 4 or 1 to 3 (or whatever) depending on the time signature of the music. Many software systems will display this data while playing a midi file. BUT, it is CALCULATED on the fly while the file is being processed, based on other data in the file. This calculation is not a big deal. There is no point to add it, as it can be calculated anyway.

The problem then is that most playback hardware does not need this information, and does not display it. A computer system probably will.

Also, normally, the purpose of listening to the midi file playback is to listen to the music, and NOT to a boom-bip-bip-bip-boom-bip-bip-bip addition.

Some software MIGHT have this facility as an option, I'm not aware of anything.

I have written my own software to play midi files, this does NOT do this, but it COULD. I'd think that this 'beat' track could be sent out separately from the computer?

So, the solution to your question is really dependant on the software/hardware that you're using? I'm not sure there is any solution within the bounds of MIDI?

Geoff

Hi Geoff,

DAWs like Logic or Ableton generate a MIDI beat signal timed to the session tempo. I'm working with a live player (uTrack 24) that doesn't do that. I'm trying to find out if it's possible to replicate that signal with a SMF.

Hello,

One possibility is that you might try to 'record' the midi output of one (or both) of the systems - Logic or Ableton. Thereby create a midi file that includes this extra timing data.(along with some note data ?) Looking at the resultant midi file would then be MOST helpful.

I'm not sure though that the timing (midi beat) data is actually midi data at all, and therefore it might not be being sent anywhere.

Is the data you wish to be available the sort of thing I described above, i.e. a bar/beat?

Geoff

Oh, I've had a look at the ,MID file that was attached by 'Bavi', and as far as I can tell this contains no immediately useful data at all. Of course, a receiving, or playing, system could be programmed to interpret the data in some way, which may be useful, but how many systems or devices allow that flexibility?

Geoff

Hello,

One possibility is that you might try to 'record' the midi output of one (or both) of the systems - Logic or Ableton. Thereby create a midi file that includes this extra timing data.(along with some note data ?) Looking at the resultant midi file would then be MOST helpful.

I'm not sure though that the timing (midi beat) data is actually midi data at all, and therefore it might not be being sent anywhere.

Is the data you wish to be available the sort of thing I described above, i.e. a bar/beat?

Geoff

I actually did try to record the outgoing clock by routing it from my soundcard's MIDI out to MIDI in but got nothing. Yes, bar/beat would be enough since I don't need absolute time value like in MIDI timecode.

As I suspected, the data you're referring to is not actually midi data, but something internal to the software you're using? I'd guess.

There is one avenue you might consider.

You create your midi file, which when played does everything musically you require, but your midi file does NOT use one midi channel. The receiving/playing devices are set to NOT respond to the one midi channel.

On that one channel, in the midi file, you create a beat track. Use a drum machine, or create it via program a bit like Bavi was suggesting. I could prob create something for you? Then you need another device, this one is set to receive/respond to ONLY the one channel. The output of this device could be heard by someone? And cue them? Not sure if there's anything that would allow any automatic trigger, but there may be. You could be cleverer, and have this beat track be mostly silent except for a pre-arranged leadin to the cue point?

This last device can be something cheap/simple. Doesn't matter what it sounds like, it's for cue info only.

There may be hardware along these lines already?

I'll think some more about this, but does this in any way relate to what you're looking for?

Geoff

As I suspected, the data you're referring to is not actually midi data, but something internal to the software you're using? I'd guess.

There is one avenue you might consider.

You create your midi file, which when played does everything musically you require, but your midi file does NOT use one midi channel. The receiving/playing devices are set to NOT respond to the one midi channel.

On that one channel, in the midi file, you create a beat track. Use a drum machine, or create it via program a bit like Bavi was suggesting. I could prob create something for you? Then you need another device, this one is set to receive/respond to ONLY the one channel. The output of this device could be heard by someone? And cue them? Not sure if there's anything that would allow any automatic trigger, but there may be. You could be cleverer, and have this beat track be mostly silent except for a pre-arranged leadin to the cue point?

This last device can be something cheap/simple. Doesn't matter what it sounds like, it's for cue info only.

There may be hardware along these lines already?

I'll think some more about this, but does this in any way relate to what you're looking for?

Geoff

I checked and the data is MIDI System Real-Time messages. I think the clock has to be in that format to be correctly interpreted by other MIDI instruments.

Geoff: Be aware that a making a recording into a MIDI file usually won't record most System Real-Time or System Common messages (status bytes from hex F0 through FF). Only System Exclusive messages are typically recorded in a MIDI file.

In particular, there are several clock, position, and start/stop messages that can be sent on a MIDI cable, but that don't usually make sense to store into a MIDI file. MIDI sequencer software will often have optional settings:

• to obey these kinds of messages coming in on its MIDI input port to control the playback, position, or speed of a loaded MIDI file, and
  
• to send these kinds of messages out its MIDI output port to help control other devices to play at the same speed and/or position.
  

Because these messages are normally an option you turn on or off when desired in your MIDI sequencer, it usually doesn't make sense to store them in a MIDI file.

It sounds like Saku's audio player will mainly be playing audio files (like WAV or MP3 files), but Saku would also like it to send MIDI clock messages out on its MIDI port to sync other effects equipment to the same tempo as the audio file. Saku's audio player can play a MIDI file simultaneously with the audio file, but it doesn't have the option add MIDI clock messages into the MIDI output. So Saku asked if there was a way to store MIDI clock messages inside a MIDI file to get the player to send them that way. The way you do that is by putting the F8 MIDI clock message inside a "sysex continuation event". When the MIDI player sends this message, it just sends whatever bytes are inside the sysex continuation event, even though it's not really part of a sysex message at all.