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.
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:
1 Like
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
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?
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 
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.