Thanks for your effort and comment! Yes, it's a Cymatic LP-16. The guys at Cymatic made a big mistake with this. I will check the posts you mentioned. Embedding midi clock sounds good. Of course I prefer the cheaper solution and the less device, but as I'm new to midi I don't know if I can make it work. I would appreciate it if you could do such a script so do all the LP-16 users.

I created the attached HTML JavaScript page to generate a MIDI file that has MIDI clocks in it:


Download: clock-midi-file-generator.zip

Let me know if this kind of clock MIDI file works for you. This esoteric embedding of a MIDI clock in a MIDI file interests me, and I'm interested to know if it turns out to be useful in practice.

The generated MIDI file is set up to send the "F8" clock message the required 24 times per quarter note. But another user reported that their Cymatic LP-16 incorrectly sends "F7 F8" each time, and wondered if that was why some of their devices didn't work.

Bavi_H, thank you so much for the effort you have put into this topic! I can try it on the weekend at the earliest. I’m very excited!

Status report: I've just figured out how to add program changes and CC messages to the midi file generated by Bavi_H's script, because Ableton is not suitable for that, or I just can't handle it enough. So I used Sekaiju. I played the midi file with the LP-16 into a midi monitoring app and it seems ok. I can see all the PC, CC and the F8 messages. There are no F7s. I will test it tomorrow on a real device as well.

Another thing: I contacted Midi Solutions and as it turned out, they added the capability to their Footswitch Controller to enable it to respond to a Note-On message as a tap when operating in Tap Tempo mode, so in this mode the Footswitch Controller sends MIDI Timing Clock messages at a rate of 24 per quarter note. It’s good to know if syncing might not come up with embedding midi clock.

Finally I tried it with my Fractal AX8, works fine. Thanks for your support Bavi_H!

I'm struggling with a similar problem. Certain Yamaha devices generate MIDI Clock for their own internal use--like rhythm machines--but also allow the user to select an external MIDI Clock to drive the device's rhythm machine. In my specific case, I'm using some 80's era Yamaha gear, specifically an HX-1 (Electone organ) and an MDR (Music Disk Recorder, 3½" floppy based). When an artist uses MDR to record a performance using the organ's rhythm machine at a set tempo, the MDR does not capture the F8s from the organ and write them to the file, only the tempo (in BPM) setting. For playback, the MDR first tells the keyboard to use an external synchronous source and the MDR hardware generates the F8s to drive the organ's rhythm machine while streaming the file's MIDI events. At the end of playback, a SysEx from the MDR tells the organ to return to using the organ's internal MIDI clock.

This makes sense given the imperfection that can arise from a tempo (in BPM) expressed as an integer and fractional rounding the occurs during recording compared to the higher resolution possible from ticks relating to microseconds. This drifting of timing is evident when you use (no offense intended) the Clock MIDI File Generator program above to create two files, each of 99 measures at 4/4 time, but one at Tempo 120 and the other at Tempo 123. The two files are identical (aside from the Set Tempo Meta-Event) and don't account for the rounding that occurs when calculating delta times. Both files send the F8s using a delta time of 5. At 120 the delta time is 5.208 and at 123 the delta time is 5.125.

My analysis leads me to conclude that Yamaha dealt with this issue by periodically adjusting to any inaccuracy that may have occurred due to rounding. At a convenient tempo like 125 BPM there should be no loss due to rounding. At 125, I *almost* always get F8s every 20 (decimal) ticks and in the rare cases when a 19 comes across, it's followed up shortly there after with a 21 which makes me wonder if it's checking itself against another onboard clock for accuracy. At BPMs not evenly divisible by 24, I see the same error-correcting occurring rather than a steady stream of a single delta time. At the end of x number of events, the accumulated delta times will be as close as possible to real time by having added back time lost from any truncation or rounding calculation.

Back to the 123BPM example: For exact timing, the delta times should be 5,5,5,5,5,5,5, 6 ,5,5,5,5,5,5,5, 6 ,5,5,5,5,5,5,5, 6, a sum of 123.

I admit to being a little "green" to all this, so please correct me if any of my assumptions are wrong. My goal is to achieve accurate playback of these recorded performances not from the MDR device, but my own program using the Windows MIDI stream APIs. I think I have no choice but to add my own F8 MIDI messages to the performance data (making sure there's an F8 every BPM/24 ticks) and hope the API can process them accurately. Regrettably, playback of the event data using the organ's clock for the rhythm machine points out the timing drift after a few measures.

the MDR does not capture the F8s [...] and write them to the file [...]. For playback, [...] the MDR hardware generates the F8s [...] while streaming the file's MIDI events.

Recording MIDI clock messages into a MIDI file is not typical. The Clock MIDI File Generator is only intended as a possible workaround for devices that can play MIDI files but do not have the ability to generate MIDI clock messages in their MIDI output.

The behavior exhibited by your Yamaha Music Disk Recorder is the expected typical behavior. MIDI file recorders do not store MIDI clock messages in the MIDI file, but they might have an option to interpret incoming MIDI clock messages to determine the quarter note-based position that has elapsed or calculate the intended tempo. MIDI file players might have an option to generate MIDI clock messages at the MIDI file's current tempo value and mix them into the output.

when you use [...] the Clock MIDI File Generator program above to create two files [...] one at Tempo 120 and the other at Tempo 123[, t]he two files are identical (aside from the Set Tempo Meta-Event) [...]. Both files send the F8s using a delta time of 5.

The Clock MIDI File Generator generates MIDI files with a resolution of 120 ticks per quarter note.

When MIDI clock messages are used, they are sent at a rate of at 24 clocks per quarter note. Since the generated MIDI file resolution is 120 ticks per quarter note, this means the generated clocks are always 5 ticks apart, no matter what the tempo is.

The software that plays back the MIDI file is responsible for converting the quarter note-based ticks into absolute time-based seconds. To make that conversion, the playback software will use the tempo value stored in the MIDI file (microseconds per quarter note) to know how long each quarter note should be in seconds.

The Clock MIDI File Generator allows you to enter a tempo value in quarter notes per minute with any number of decimal places. It will store a value in the MIDI file in microseconds per quarter note that is the closest match to the tempo value you enter. This is the most precise tempo representation possible in a MIDI file.

Hi i try the script but is send out F7 before F8 so F8 is recognized as an argument of F7 (System Exclusive message). F8 is a realtime message and only need 0XF8 argument to be passed.

i tried to modify your script without success...any suggestions? Thanks

let clock_event_buffer = new ArrayBuffer(1);
let clock_event_array = new Uint8Array(clock_event_buffer);

clock_event_array[0] = 0xF8;


events_accumulator.push(clock_event_buffer);

Hi i try the script but is send out F7 before F8 [...]

i tried to modify your script without success...any suggestions?

Be aware that certain status bytes in a MIDI file have a different meaning than the same status bytes on a MIDI cable. (For example, F7.) Also be aware that some status bytes you can encounter on a MIDI cable are not allowed as status bytes in a MIDI file. (For example, F8.)

In a MIDI file, a status byte of F7 is used to store bytes that will be sent verbatim to the MIDI output port. The status byte of F7 itself is not supposed to be sent to the MIDI output port, just the data bytes of the message.

The code changes you described will put messages containing a single F8 in the generated MIDI file. Unfortunately, a message containing a single F8 isn't allowed in a MIDI file. Software or devices that try to handle a MIDI file like that could refuse to open the file or crash. Why? When you are reading a MIDI file, there are specific rules so you know how many bytes are part of each message at every point in the MIDI file. If you encounter a status byte of F8 in a MIDI file, there are no rules defined for how many bytes to expect next.


Storing MIDI clock messages into a MIDI file is not typical. The Clock MIDI File Generator is only intended as a possible workaround for devices that can play MIDI files but do not have the ability to generate MIDI clock messages in their MIDI output.

The only possible way to store a MIDI clock message in a MIDI file is to store it inside of an F7 message in a MIDI file. MIDI players are supposed to send the bytes stored in an F7 message directly to the MIDI output port. The status byte of F7 itself is not supposed to be sent to the MIDI output port.

When you play the generated MIDI file containing clock messages, if you are seeing incorrect "F7 F8" bytes getting sent, and if this causes your target device to ignore the F8 clock message, then you'll need to figure out some other way to generate a clock message.

Other people have had ideas to possibly purchase a device that will transform some simple MIDI message (like a note or a control change) into a clock message. But I don't know if anyone has tried that yet.

Earlier in this thread, Gabe reported "I contacted Midi Solutions and as it turned out, they added the capability to their Footswitch Controller to enable it to respond to a Note-On message as a tap when operating in Tap Tempo mode, so in this mode the Footswitch Controller sends MIDI Timing Clock messages at a rate of 24 per quarter note. It's good to know if syncing might not come up with embedding midi clock."

Hi i try the script but is send out F7 before F8 [...]

i tried to modify your script without success...any suggestions?

Be aware that certain status bytes in a MIDI file have a different meaning than the same status bytes on a MIDI cable. (For example, F7.) Also be aware that some status bytes you can encounter on a MIDI cable are not allowed as status bytes in a MIDI file. (For example, F8.)

In a MIDI file, a status byte of F7 is used to store bytes that will be sent verbatim to the MIDI output port. The status byte of F7 itself is not supposed to be sent to the MIDI output port, just the data bytes of the message.

The code changes you described will put messages containing a single F8 in the generated MIDI file. Unfortunately, a message containing a single F8 isn't allowed in a MIDI file. Software or devices that try to handle a MIDI file like that could refuse to open the file or crash. Why? When you are reading a MIDI file, there are specific rules so you know how many bytes are part of each message at every point in the MIDI file. If you encounter a status byte of F8 in a MIDI file, there are no rules defined for how many bytes to expect next.


Storing MIDI clock messages into a MIDI file is not typical. The Clock MIDI File Generator is only intended as a possible workaround for devices that can play MIDI files but do not have the ability to generate MIDI clock messages in their MIDI output.

The only possible way to store a MIDI clock message in a MIDI file is to store it inside of an F7 message in a MIDI file. MIDI players are supposed to send the bytes stored in an F7 message directly to the MIDI output port. The status byte of F7 itself is not supposed to be sent to the MIDI output port.

When you play the generated MIDI file containing clock messages, if you are seeing incorrect "F7 F8" bytes getting sent, and if this causes your target device to ignore the F8 clock message, then you'll need to figure out some other way to generate a clock message.

Other people have had ideas to possibly purchase a device that will transform some simple MIDI message (like a note or a control change) into a clock message. But I don't know if anyone has tried that yet.

Earlier in this thread, Gabe reported "I contacted Midi Solutions and as it turned out, they added the capability to their Footswitch Controller to enable it to respond to a Note-On message as a tap when operating in Tap Tempo mode, so in this mode the Footswitch Controller sends MIDI Timing Clock messages at a rate of 24 per quarter note. It's good to know if syncing might not come up with embedding midi clock."

Ye i build myself, before studiing the SMF way, an arduino based tool that do the same as Midi Solution!! The box can translates notes into MIDI CLOCK, MIDI START, MIDI STOP and it works like a charm. But, u know, the idea of going direct from the cymatic to a midi device in more strong.

I try your script but my hardware (Moog sub 37) cannot sync to that...dunno why!!

Any idea or anyone had success with the code?


another thing. I noticed in your code wehn you parse the tempo that you add 0.5. It is right? and why? I mean the meta event will ever display wrong infos about bpm! If you set 81 bpm the meta event will say 80. I think is not a real probelm in the program cause the time is calculated in microseconds...but can u explain this to me? Thanks

Thanks!

anyone had success with the code?

Earlier in this thread, Gabe said a generated MIDI file containing clock messages successfully got his Cymatic LP-16 to send clock messages to his Fractal AX8. Gabe reported his Cymatic LP-16 does not send the incorrect F7 bytes. (However, as I mentioned earlier in this thread, there is an older thread in which user Florent reported their Cymatic LP-16 does send the incorrect F7 bytes.)

Ye i build myself, before studiing the SMF way, an arduino based tool that do the same as Midi Solution!! The box can translates notes into MIDI CLOCK, MIDI START, MIDI STOP and it works like a charm. But, u know, the idea of going direct from the cymatic to a midi device in more strong.

Cool!

Does your Kiwi Lab MIDI Box send an FA start message before the F8 clock messages? Maybe your Moog Sub 37 requires an FA start message in order for its sync to work. The MIDI file generated by the Clock MIDI File Generator only contains F8 clock messages. The attached test modification to the Generator changes the first message to a start and a clock (FA F8).

Download: clock-midi-file-generator-v1.01-test.zip

Maybe updating your Moog Sub 37 firmware will help? In the Moog Sub 37 page Downloads section, the firmware zip file includes a PDF file with instructions and a list of changes introduced in each firmware version. I see the following changes to sync behavior in the list:

NEW IN 1.0.4
[...] Change in External Sync behavior: does not require MIDI Start message [...]

NEW IN 1.0.2
[...] MIDI sync behavior fixes and improvements

If your Kiwi Lab MIDI Box is only sending F8 messages and your Moog Sub 37 works with them, but your Cymatic device (is it a Cymatic LP-16?) playing a MIDI file generated by the Clock MIDI File Generator is sending "F7 F8" bytes and your Moog Sub 37 doesn't work with them, that would suggest the problem is the incorrectly sent F7 bytes. Unfortunately, I don't think there's a way to get your Cymatic device to stop sending the incorrect F7 bytes by changing the MIDI file.

I noticed in your code wehn you parse the tempo that you add 0.5. It is right? and why?

In JavaScript, parseInt ignores everything after the decimal point:

parseInt(1.1) // returns: 1

parseInt(1.9) // returns: 1

I want to round to the nearest integer, so I add .5:

parseInt(1.1 + .5) // returns: 1

parseInt(1.9 + .5) // returns: 2

To be more clear, maybe I should use Math.round(x) instead of parseInt(x + .5). I don't remember why I got in the habit of using parseInt(x + .5).


For example, 81 quarter notes per minute is exactly 740740.740... microseconds per quarter note. I round that to 740741 microseconds per quarter note because that's the closest value to the exact value that is possible to store in a MIDI file:

A: microseconds per quarter note

B: offset from 740740.740... microseconds per quarter note

C: quarter notes per minute

D: offset from 81 quarter notes per minute



A       B        C           D

740740  ≈-0.741  ≈81.000081  ≈+0.000081

740741  ≈+0.259  ≈80.999972  ≈-0.000028

If you set 81 bpm the meta event will say 80.

740741 microseconds per quarter note is exactly 80.99997165... quarter notes per minute. If you are seeing that show up as "80", then it sounds like your display device is ignoring everything after the decimal point. It would be better to do something like round the value to 2 decimal places.

Does your Kiwi Lab MIDI Box send an FA start message before the F8 clock messages? Maybe your Moog Sub 37 requires an FA start message in order for its sync to work. The MIDI file generated by the Clock MIDI File Generator only contains F8 clock messages. The attached test modification to the Generator changes the first message to a start and a clock (FA F8).

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.

I manage to modify your script to send start message before reading you comment

Why u send a bit of F8 before the start? I mean a modified the code this way...it is correct?

/* MIDI START */





  let start_event_buffer = new ArrayBuffer(4);

  let start_event_array = new Uint8Array(start_event_buffer);



  start_event_array[0] = 0; // delta time 0

  start_event_array[1] = 0xF7;

  start_event_array[2] = 1;

  start_event_array[3] = 0xFA;



  events_accumulator.push(start_event_buffer);    





  /* ... First clock event at time zero: */



  let delta_zero_buffer = new ArrayBuffer(1); // one byte of value zero



  events_accumulator.push(delta_zero_buffer);



  let clock_event_buffer = new ArrayBuffer(3);

  let clock_event_array = new Uint8Array(clock_event_buffer);



  clock_event_array[0] = 0xF7;

  clock_event_array[1] = 1;

  clock_event_array[2] = 0xF8;



  events_accumulator.push(clock_event_buffer);





  /* ... Repeating clock events: */



  let ticks_per_clock = ticks_per_q / 24;

  let variable_length_quantity_stack = new Array();



  for(let i = 0, remainder = ticks_per_clock; (i < 4) && (remainder > 0); ++i, remainder >>= 7)

  {

    variable_length_quantity_stack.push(remainder & 0x7F);

  }



  let delta_size = variable_length_quantity_stack.length;

  let delta_buffer = new ArrayBuffer(delta_size);

  let delta_array = new Uint8Array(delta_buffer);



  for(let i = 0; i < delta_size - 1; ++i)

  {

    delta_array[i] = 0x80 | variable_length_quantity_stack.pop();

  }



  delta_array[delta_size - 1] = variable_length_quantity_stack.pop();



  let clocks_per_measure = clocks_per_time_sig_bottom * time_sig_top;

  let measures = parseInt(document.getElementById("measures").value, 10);

  let total_clocks = clocks_per_measure * measures;



  for(let i = 0; i < total_clocks; ++i)

  {

    events_accumulator.push(delta_buffer);

    events_accumulator.push(clock_event_buffer);

  }

    

  /* MIDI STOP */





  let stop_event_buffer = new ArrayBuffer(4);

  let stop_event_array = new Uint8Array(stop_event_buffer);



  stop_event_array[0] = 0; // delta time 0

  stop_event_array[1] = 0xF7;

  stop_event_array[2] = 1;

  stop_event_array[3] = 0xFC;



  events_accumulator.push(stop_event_buffer);     

Also there is another problem. 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...maybe you can suggest me something more smart...i explain...

Midi clock generated file -> Cubase -> Add pc cc etc...

At this point cubase recognize all the sysex msg in proper timeing position but he assume they are Sysexmessage so he 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. Works but is a little bit tricky Any idea?


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?

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.