[detonate] timing question

Sep 14, 2010 at 6:30am

[detonate] timing question

Hi, I’m having difficulty getting [detonate] to store and/or report timing correctly. I’m including a patch below that demonstrates the problem. Basically, when I store events (using delta time in ticks), write a MIDI or text file, read the file back into [detonate], then report the events using the nth message, the timing of the reported events is different from the originally input time.

I’m assuming there is something going on with a milliseconds conversion somewhere. I’m also aware of the arguments for the read and write messages to [detonate], but I’ve tried them and just can’t get it to save the timing correctly. If someone could tell me what I am doing wrong, please let me know. Thanks!

– Pasted Max Patch, click to expand. –
#52302
Sep 14, 2010 at 11:42am

First, keep in mind that delta time is given in milliseconds, not ticks.

1 quarter note (qn) at 120 BPM (default) is 500 ms.
So, 200 ms means 200/500 = 0.4 qn.

Within MIDI files the timing must be represented by ticks. I’ve looked into the generated file and found that it uses a resolution of 96 ticks per quarter note (ppqn).

So in this case, 200 ms corresponds to 96*0.4 = 38.4 ticks.

But unfortunately, MIDI files can represent ticks only as integer values.
So some rounding takes place which explains the differences you observe.

Detonate is especially problematic due to the low tick resolution.
Most programs export MIDI files at much higher resolution, eg. 480ppqn.
(For example, 480*0.4 gives 192 exactly.)

#187957
Sep 14, 2010 at 3:51pm

BTW, when converting the generated MIDI file to readable text, it looks like this.
———————–
Format 0
NumTracks 1
Division 96
ProgramOffset 1
BarOffset 0
Track 1
0000:1:000
0000:1:038
NoteOn Ch1 d2 64
0000:1:048
NoteOn Ch1 d#2 64
0000:1:055
NoteOn Ch1 e2 64
0000:1:076
NoteOn Ch1 d2 0
0000:1:086
NoteOn Ch1 d#2 0
0000:1:094
NoteOn Ch1 e2 0
EndOfTrack
————————-

#187958
Sep 14, 2010 at 6:37pm

Thanks broc, that’s very helpful. What about when [detonate] reads a higher tick resolution MIDI file? Does it automatically scale the resolution down?

#187959
Sep 14, 2010 at 8:02pm

Yes. Imported MIDI files are converted to the internal representation of [detonate] and then exported as usual, i.e. with tick resolution of 96.

I just noticed from the help file that [detonate] seems to support also millisecond-based timing of MIDI files. It conforms to the MIDI standard, but I’ve never seen such files in practice.

#187960
Sep 15, 2010 at 7:53am

@Broc:

How do you convert a MIDIfile to text as shown in this thread?

#187961
Sep 15, 2010 at 10:43am

Hi Roald,

I’m using a Java program which was written as part of a student project back in 2000. The basic functionality is provided in the attached .jar file. It can be launched by double-click like any other application. Help files are not included but I think the usage is simple and self-explanatory.

#187962
Sep 16, 2010 at 6:25am

Thanks for your help broc.

There seems to be another [detonate] timing problem. When I send it three notes with the same note-on time, save a MIDI file, and read it back into [detonate], the duration of one of the notes gets messed up, and not due to a rounding error. In the example below, I’m sending it three notes with the same note-on time, with durations of 100, 125, and 150. After writing and reading a MIDI file, the resulting durations are 99, 10, and 151. I can see that the 99 and 151 are rounding errors, but what about the 10?

– Pasted Max Patch, click to expand. –
#187963
Sep 16, 2010 at 9:56am

I’m able to reproduce the issue here.

The written MIDI file appears to be correct.
——————–
0000:1:038
NoteOn Ch1 d2 100
NoteOn Ch1 d#2 100
NoteOn Ch1 e2 100
0000:1:057
NoteOn Ch1 d2 0
0000:1:062
NoteOn Ch1 d#2 0
0000:1:067
NoteOn Ch1 e2 0
——————–

So there seems to be a bug with reading the file.
I’ve also noticed that reading takes ages (~ 1 minute) which is highly suspect.

#187964
Sep 16, 2010 at 6:06pm

Thanks for the report. There are definitely some timing issues with detonate, some of which we are aware of.

This last one regarding the duration has been fixed but I’m not entirely sure when it will be incorporated into a build.

Apologies for the inconvenience in the meantime.

-Ben

#187965

You must be logged in to reply to this topic.