Exported Midi file format

[dftlm]

In what format (SMF 0, 1, 2) does MusE export a midi file?

[j_e_f_f_g]

Format 1.

Almost no software deals with format 2.

[dftlm]

@j_e_f_f_g

Ok, that's cleared up and thanks for the reply. I make some midi parts in MusE, which I want to use in Rhythm Style, with the help of python script. I chose to make them in MusE because I saw that in the exported midi file, MusE transmits tempo map info, tempo and ts. For example, I export 4 bars 3/4 to 96 ticks resolution part (my keyboard hardware has max quantize 32) in myfile.mid.
Now if I check with

midi2abc myfile.mid -sum

to see a midi file summary, ts and tempo match. But at a unit length of 1/8 using 192 pulses per unit length producing 3 bars.
If I check with

midi2abc myfile.mid -b 4 -sum

(I need 4 bars), tempo=163 changes.
What's the trick?

[j_e_f_f_g]

my keyboard has quantize 32

I assume you mean that you can quantize to 32nd notes.

But that doesn't tell you what "pulses per quarter note" (PPQN) base your keyboard uses. Note that there are 8 32nd notes in a quarter note. If your keys uses 192 PPQN, then each 32nd note is (192 / 8) or 24 clocks. If your keys instead uses 96 PPQN, then each 32nd note is 96 / 8, or 12 clocks.

So at 96 PPQN, your keys outputs a quarter note every 96 clocks. But at 192, it outputs at 192 clocks. (Internally, it is counting down twice as fast at 96 PPQN).

Let's assume your keys always plays midi files at 96 PPQN (very likely. It's the most common base on hardware sequencers in workstations).

If you save a MIDI file at 96 PPQN in Muse, then everything works out fine. Muse and your keys are internally playing at the same speed.

But if you save a MIDI file at 192 PPQN in Muse, and your keys doesn't convert it to 96 PPQN (which seems like it's the problem), then all those timestamps (at 192 PPQN) will be twice as long as they should be. Your keys will calculate the wrong timings and therefore it will seem like the tempo is changed.

What's the trick?

Make sure you set MUSE to the PPQN supported by your keys when you save midi files.

BTW, if this in fact the problem, then you have a really badly designed hardware sequencer. It should convert timebase to what it needs. What product is this??

[dftlm]

Yes, my hardware sequencer plays at 96 PPQN, quantize from off to 32nd (32. 32t) notes.
I save a MIDI file at 96 PPQN in MusE.

The problem is that until playing MIDI files in the hardware sequencer, I check this file with the midi2abc app, but now I understand that midi2abc calculates its pulses per unit length, to display the information, just as my hardware sequencer will calculate it in the his.

I set MusE to 96 PPQN, like my keys.
Thank you very much for the clarifications!

[dftlm]

@j_e_f_f_g

I solved it, from the Config Midi File Import/Export dialog window. I didn't know these settings existed.
So it's not from hardware keys, now everything works perfectly. My hardware keys need note on note off messages, not just note on note on vel=0.
Thank you!

[j_e_f_f_g]

My hardware keys need note on note off messages, not just note on note on vel=0.

You're kidding!? Recognizing "note-on 0 velocity" as a "note-off" is a requirement of the MIDI 1,0 specification.

Your hardware product has a defective MIDI implementation.

What product is it?

[dftlm]

With note-on zero velocity, only drum track sounds, the other melody tracks don't, like a very very short stacato. That's how I figured it out and looking in hardware keys manual, I saw the ranges of the event settings. Now, with note-off, it sounds perfect, as it should. Defective or not, the important thing is that it works.

[j_e_f_f_g]

That is a defective MIDI implementation. The manufacturer should either issue a firmware update, or recall the defective product.

Be aware that you will not be able to play the vast majority of existing midi files without changing all the "running status note-off" (note-on with 0 velocity) messages to explicit note-offs messages. Almost no hardware uses note-off release velocity, so the running status note-off is almost always used in midi files (it can significantly reduce the file's size). That's a major limitation of your sequencer, and will cause you a lot of extra work and annoyance.

I'll look into writing a utility that at least you can use to quickly convert a directory of midi files to what your sequencer will accept. But I think you're going to find your hardware's "bug" a continual source of annoyance.

[Tim E. Real]

It's a Casio CT-X**** right?

From the Midi Implementation chart:

Note Off
Format
Message Format: 8nH kkH vvH
9nH kkH 00H(receive only)

So it is compliant.

Our drum editor notes are very short by default unless length is entered manually.
1: Maybe accidentally trying to drive a melodic non-drum voice with notes exported or played from our drum editor?
2: Or trying to drive a drum voice with our drum editor notes and the note-offs are being sent but the device doesn't like drum note-offs?
If the instrument is in a drum voice mode, it is usually supposed to ignore note-offs (except for certain drum sounds: hi-hat etc).

So this situation comes up from time to time when drum samplers are played to. Short staccato sounds.
It's the reason our built-in simpledrums MESS sample player synth has 'ignore note-off' checkboxes for each sample.
The checkbox's usage depends entirely on whether the sample is a melodic sample or a percussive sample.

A real drum synth's voices should mostly ignore them.

So I suspect the problem may be #1 (above) or some variant.
And as usual... It might just be MusE's fault.
I'll try to double check a few things.

Note that the 'Note off mode' settings found in the Instrument Editor relate to 'live' or 'playback' material streamed to a device,
whereas the note off settings in the Midi Export Dialog control the exporting of such notes.

[j_e_f_f_g]

It's a Casio CT-X**** right?

I had a feeling it was a casio. I bought their first digital sampling keyboard the FZ-1. What a piece of junk it turned out to be. I also bought a Privia, which was better quality. But Casio, like Behringer, is a brand that I tend to avoid because they seem to have a knack for cutting the corners in the wrong places.

From the Midi Implementation chart:
So it is compliant.

You're no doubt citing the midi implemention on the built-in sound generation. I would be utterly appalled if they had actually omitted support for 0 velocity note-ons there.

But my impression is that the OP's trouble was importing midi files into his keyboard's built-in sequencer. It didn't seem to deal with 0 velocity note-ons in those files (which shouldn't be the case if it was properly implemented).

Our drum editor notes are very short by default unless length is entered manually.

I think it's a good idea to default to at least a quarter note length for every drum note. If you've made it shorter, I assume you've done so because you figure most drum modules are going to ignore the subsequent note-off anyway and play the drum sound at its full length (ie the note-off is not going to affect the VCA envelope). But sending that note off very soon after the note-on will hopefully streamline voice allocation and tracking. That's aa logical approach in theory. But in practice, I find that most voice management ignoring note-offs, uses a voice allocation implementation that isn't affected by how soon a followup note-off is received. So you gain nothing by rushing out the note-off. But on implementations where that note-off does affect the vca envelope, too short a note length won't even get the VCA time to open. The net result is the note doesn't even sound, and the reason why isn't apparent to the enduser. He usually wastes hours trying to trouble-shoot why his sound module "isn't Receiving/responding to notes"' (when it actually is, but not in an audible way.)

[dftlm]

@Tim E. Real

Tim guessed well... If MusE didn't have the default settings for midi file import/export, or if I had found them before, I would have succeeded on the first try and this subject would no longer exist.
The problem is not the hardware keys defect, it has more defects than this...
The important thing is that with what I have and with Muse, I can do what I want. And I see that it is possible.
Thank you all for your help!

According to the Midi Implementation Chart, it recognizes zero velocity note-ons as note offs, so it cannot be considered defective. Anyway, from my point of view, I happily consider the problem solved.