Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

MIDI files clock / quantization / settings


#1

Hi Guys,

Do you have a quick way to find out with what clock resolution midi file was created/saved/exported?
I know that Ableton export files with resolution of 96.


#2

Personally, I use python with a MIDI package like Mido:

https://mido.readthedocs.io/en/stable/#

However, you can also use this online MIDI editor:

http://www.midipro.org/Editor.php


#3

Thanks Brian! I would continue here with another question.

I`m exporting single midi clip that contains 4 steps (4/4 signature - 16th notes)
So After exporting this to ER102 i have this result:

Step 1: D48 G12 
Step 2: D48 G12 
Step 3: D48 G12
Step 4: D12 G12

As you can see duration for the last step is being shortened. Anyone experienced that?
I have attached this midi file if you`d like to check.
Tomek.zip (202 Bytes)

So another question is those setting in config.ini
In order to have those 16th notes with quantized while importing to 6 pulses (I`m using 24ppqn clock)
I have set those settings there:

 [MIDI]
; Temporal quantization: shift events to the nearest quantization grid boundary. (v2.00-)
;
; none - do not quantize
; 1 to 256 - # of divisions per quarter note (e.g. 2 for 8th notes, 3 for triplets, 8 for 32nd notes, etc.)
quantize = 16	

; How is the MIDI clock interpreted when loading MIDI files?
;
; 1 to 96 - Divide the MIDI clock by this number when loading MIDI files.
; auto - Scan the file for the smallest time interval and use this as the divider.
divider = 16

Divider is set to 16 but since the midi clock was 96 so shouldn t the divider be set to 4 (96/4=24)? I m guessing there a math happening here which I don t understand. I m just asking to understand this.

So the result was succesfull, but last step was again shortened.

Step 1: D6 G1
Step 2: D6 G1 
Step 3: D6 G1
Step 4: D1 G1

#4

The shortened last step is expected behavior in this case. If you analyze the MIDI file:

format: 0, nTracks: 1, division: 96
----------------------------------

Start - track #0, time:0 (0)
('META EVENT:', 3)
sequence_name: 
('META EVENT:', 88)
time_signature: 4 2 36 8
('META EVENT:', 88)
time_signature: 4 2 36 8
note_on (1)  - ch:00,  note:30,  vel:64 time:0 (0)
note_off - ch:00,  note:30,  vel:40 time:24 (24)
note_on (2)  - ch:00,  note:30,  vel:64 time:72 (96)
note_off - ch:00,  note:30,  vel:40 time:24 (120)
note_on (3)  - ch:00,  note:30,  vel:64 time:72 (192)
note_off - ch:00,  note:30,  vel:40 time:24 (216)
note_on (4)  - ch:00,  note:30,  vel:64 time:72 (288)
note_off - ch:00,  note:30,  vel:40 time:24 (312)
('META EVENT:', 47)
End of track, time:0 (312)

You can see that the track ends right after the last note_off message (at timestamp=312). Understand that a note_off MIDI message corresponds to a gate going low in the CV/gate world. I think the underlying cause is that any loop/clip/track length information that was assumed in the DAW was not (can not?) be included in the MIDI file.

Unfortunately, I don’t understand your second question. This one looks like you used a divider of 2 or perhaps auto:

Step 1: D48 G12
Step 2: D48 G12
Step 3: D48 G12
Step 4: D12 G12

96/2 = 48 pulses per beat

and this one looks like you used a divider of 16:

Step 1: D6 G1
Step 2: D6 G1
Step 3: D6 G1
Step 4: D1 G1

96/16 = 6 pulses per beat

Can you rephrase the question in the light of this explanation?


#5

You can see that the track ends right after the last note_off message (at timestamp=312). Understand that a note_off MIDI message corresponds to a gate going low in the CV/gate world. I think the underlying cause is that any loop/clip/track length information that was assumed in the DAW was not (can not?) be included in the MIDI file.

That makes sense now to me. Thanks a lot :slight_smile:

Can you rephrase the question in the light of this explanation?

My understand of the Divide the MIDI clock was i guess different. I was trying to adjust this setting to the clock that drives the device (in my case that 24ppqn). I can see that this was incorrect interpretation.