Forums > MaxMSP

[detonate] timing question

September 14, 2010 | 6:30 am

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. –

September 14, 2010 | 11:42 am

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.)


September 14, 2010 | 3:51 pm

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
————————-


September 14, 2010 | 6:37 pm

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


September 14, 2010 | 8:02 pm

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.


September 15, 2010 | 7:53 am

@Broc:

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


September 15, 2010 | 10:43 am

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.


September 16, 2010 | 6:25 am

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. –

September 16, 2010 | 9:56 am

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.


September 16, 2010 | 6:06 pm

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


Viewing 10 posts - 1 through 10 (of 10 total)