Ye The "Kiki Lab" also send start and stop message. The Sub37 not need the start to sync but need it in you want to make sure that that if you stop and in a point of a song (may be @ reharsal) that is not properly the quarter note, it goes out of sync so i wrote the code to send start and stop so i'm sure that every time the sequence stops or the song end the moog is in STOP and before sending F8 to set to START. This way he is in lock in every situation.

That is a good point.

When I made the original Clock MIDI File Generator, I wondered if I should include a Start message at the beginning and a Stop message at the end, but I thought it might be weird -- if you had to stop in the middle, you would still need something else to send the Stop message. So I took the easy way out in the initial version and thought if you need the Start and Stop messages, you would have to use something else to send them.

When I made the original Clock MIDI File Generator, the only use case I thought of was if the clock messages get sent to an arpeggiator that starts a pattern whenever you play a keyboard key. In that case, I was assuming the performer would press the key close enough to the beat that the arpeggiator pattern would sound in good enough sync.

But there are probably many other uses where you need to ensure the beat position is correct. As you say, sending the Start message at the beginning will force the beat position to restart and ensure the beats are where you want.

Why u send a bit of F8 before the start?

Note that I left the definition of the F8 message in the same place, but it doesn't get stored by events_accumulator.push() until later. I made the change quickly. To be more clear, I should move the definition of the F8 message later, right before it gets used for the first time.

Also, I originally thought that putting the FA start and the first F8 clock in the same F7 message would be easier and quicker. I think the MIDI file should mean the same thing either way -- if FA and F8 are in the same message or in separate messages, the player should send both FA and F8 to the MIDI output port. But now I suspect that in some cases, like maybe when you send just a few MIDI bytes at once using a Windows MIDI call, perhaps it might not like two status bytes getting sent in the same call? For example, when I played a test MIDI file containing FA F8 in one message into MIDI-OX using a virtual MIDI cable, MIDI-OX only saw the FA and not the F8. So I now think it might work better in more cases to put the FA and F8 in separate messages, like you did in your modifications.

I mean a modified the code this way...it is correct?

Your modifications look good to me. The generated MIDI file has the expected messages when I open it in MIDI sequencer Sekaiju. When I play the file to MIDI-OX over a virtual MIDI cable the MIDI-OX position display behaves as expected (resets to 1:1:0 at start of play and shows the expected tempo).

If i want to have on the same midi file all my cc and pc i have found only a not easy way to do it... [...]

[Cubase] automaticcaly trasform very F7 F8 in F0 F7 where in between u can put a varible...but we cannot input 248 (F8) as the argument of a sysex message is max 127 (dec.) Same problem in logic.

So after addiig all my stuff and saved the file i had to open it in an hez editor and batch replace al F0 with F7, all F7 wi F8 and the firts to FA and the last to FC.

Unfortunately, it sounds like Cubase isn't properly handling the F7 MIDI file message.

The F7 MIDI file message can be used for two different purposes:
1. The second or later packet of a System Exclusive message that is split into mutiple packets.
2. Any arbitrary bytes that you want to send to the MIDI output port.

Either way, the only thing the MIDI file player has to do is send all the data bytes in the F7 MIDI file message directly to the MIDI output port.

However, it sounds like Cubase is trying to convert the F7 MIDI file message into a System Exclusive message. This isn't correct per the MIDI file specification, but since using the F7 MIDI file message to store arbitrary bytes isn't typically needed, handling the F7 MIDI file message wrong probably doesn't affect any normal MIDI files.

If you have a Windows computer, try the free MIDI sequencer Sekaiju. It calls the F7 MIDI file message "SysEx(Arbitrary)" and respects whatever bytes it contains without forcing it to start with F0 or end with F7 or have only bytes between 00 and 7F.

I think I will start looking into making something that will add the start, clock, and stop messages to an existing MIDI file. That way people can use their favorite MIDI software to make a MIDI file containing their desired control messages, then use a tool to add the start, clock, and stop messages to their MIDI file afterward.

About the timing...u right, i do my homework too and i arrived at the same conclusion...but 80 instead of 81 show on the programm is only a display issue, the real midi tempo will still be 89.9999... so no problem (if you don't play a song of 20min) right?

I agree this is what a MIDI player SHOULD do: If a MIDI player is playing a MIDI file that specifies a tempo of 740741 microseconds per quarter note, it should play at a tempo as close to 80.999... quarter notes per minute as it can. If it can only play integer tempos of 80 or 81 quarter notes per minute, then it should choose 81. It shouldn't use or display 80 quarter notes per minute.

However, to confirm what any particular MIDI player ACTUALLY does, we'd have to test to make sure.

You got the point!!
U need the Start and Stop message and also a stop message if the sequence stops. So i embedded a script that checks if the Beat Clock is running, if not it sends stop message and reset the count of the 24ppqn to send to the device. Little tricky but works fine.

I will be super if you could write a script that adds MBC to a midi file but i think is quite hard beacuse you have to inserte the F7 F8 and delta beetween acutal midi message...u can figure it out? 🙂 We need a sort of midi merger.
At this time i'm working on a bash script to fix the incorrect bytes of the midi file after adding midi messages from cubase...it quite simple in theory

The first encounter of F0 F7 - > F7 FA
All the others F0 F7 - > F7 F8
The last one -> F0 F7 - > F7 FC

Sound right?

I have tested with another midi player "midi quick fix" and it dislays actually 80.999. So i'ts fine i suppose

@Bavi_H:

I'm glad I included my own disclaimer about being "green" to this. After writing my initial post, I discovered that the MDR does indeed capture the F8s. While it may seem like their presence in the MDR file should have been obvious to me, it wasn't until I discovered that other real time MIDI messages like FC are encoded as two bytes, "FE 7C". Suddenly it became clear what those hundreds and hundreds of "FE 78" pairs were: Yamaha's way of encoding an F8. Indeed, these files are NOT to MIDI 1.0 file standards! In their header they have the text "COM-ESEQ" and from other posts I've read, I think this format is some variant of the one used for their disklavier devices.

Anyway, the good news is that I can translate all FE 78s to F8s as I build my MIDI events and MIDI headers for streaming with the Windows midiStreamOut command. The organ's rhythm machine is now driven by the external clock source (in my case, my Windows program firing all those F8s) and everything plays back perfectly synchronized as if it were playing from the floppy disk through the MDR device. It's a beautiful thing! My original solution of somehow generating my own F8s at the precise times required for synchronized playback would never have worked.

Thanks for your feedback. I only delved into this a few months ago and getting my brain around this has been a challenge. I now understand why your program generates the same delta time regardless of tempo and appreciate your explanation.

Mahlon Houlihan:

I discovered that the MDR does indeed capture the F8s. [...] FC are encoded as two bytes, "FE 7C". [...] "FE 78" pairs were [] Yamaha's way of encoding an F8. Indeed, these files are NOT to MIDI 1.0 file standards! In their header they have the text "COM-ESEQ" [...] I think this format is some variant of the one used for their disklavier devices.

Great! I've always wondered how Yamaha's E-SEQ format (formats?) work, but couldn't find examples or descriptions of it online. If you ever post your findings somewhere, I'd enjoy reading it.

Gabriele:

So after addiig all my stuff and saved the file i had to open it in an hez editor and batch replace al F0 with F7, all F7 wi F8 and the firts to FA and the last to FC.

The first encounter of F0 F7 - > F7 FA
All the others F0 F7 - > F7 F8
The last one -> F0 F7 - > F7 FC

Sound right?

That might work, but be aware that doing "find and replace" on the bytes in a MIDI file could replace more than you want. You only really want to change F0 when it is a status byte in the MIDI file, but doing a plain "find and replace" will change every F0 in the MIDI file, which could happen in other spots that aren't a status byte. Likewise, you only really want to change F7 when it is the single data byte of an F0 MIDI file message, but F7 could happen in other spots.

Mahlon Houlihan:

I discovered that the MDR does indeed capture the F8s. [...] FC are encoded as two bytes, "FE 7C". [...] "FE 78" pairs were [] Yamaha's way of encoding an F8. Indeed, these files are NOT to MIDI 1.0 file standards! In their header they have the text "COM-ESEQ" [...] I think this format is some variant of the one used for their disklavier devices.

Great! I've always wondered how Yamaha's E-SEQ format (formats?) work, but couldn't find examples or descriptions of it online. If you ever post your findings somewhere, I'd enjoy reading it.

Gabriele:

So after addiig all my stuff and saved the file i had to open it in an hez editor and batch replace al F0 with F7, all F7 wi F8 and the firts to FA and the last to FC.

The first encounter of F0 F7 - > F7 FA
All the others F0 F7 - > F7 F8
The last one -> F0 F7 - > F7 FC

Sound right?

That might work, but be aware that doing "find and replace" on the bytes in a MIDI file could replace more than you want. You only really want to change F0 when it is a status byte in the MIDI file, but doing a plain "find and replace" will change every F0 in the MIDI file, which could happen in other spots that aren't a status byte. Likewise, you only really want to change F7 when it is the single data byte of an F0 MIDI file message, but F7 could happen in other spots.

But as far as i read, F0 and F7 are, as for other midi messages are unique. I mean F7 has no other use aside of sysex messages. Yes...u can say i can destroy other sysex...but...usually i do not use them. And so F0 too is unique...what i'm missing?

Bavi_H wrote:

be aware that doing "find and replace" on the bytes in a MIDI file could replace more than you want. You only really want to change F0 when it is a status byte in the MIDI file, but doing a plain "find and replace" will change every F0 in the MIDI file, which could happen in other spots that aren't a status byte. Likewise, you only really want to change F7 when it is the single data byte of an F0 MIDI file message, but F7 could happen in other spots.

Gabriele wrote:

But as far as i read, F0 and F7 are, as for other midi messages are unique. I mean F7 has no other use aside of sysex messages. [...] And so F0 too is unique...what i'm missing?

The bytes in a MIDI file are more than just the bytes you would find on a MIDI cable.

The following items are things in a MIDI file that do not appear on a MIDI cable. These things might possibly contain an F0 or F7 sometimes.

chunk headers
delta times
length bytes (variable-length quantities)
meta events

If you do a simple "find and replace" you might corrupt some of these things if they happen to contain an F0 or F7.

You can try my app to reconvert the file generated by MBC javascript after saved in cubase...let me know. (Mac only)