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.