[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!
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.)
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
-------------------------
Thanks broc, that's very helpful. What about when [detonate] reads a higher tick resolution MIDI file? Does it automatically scale the resolution down?
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.
@Broc:
How do you convert a MIDIfile to text as shown in this thread?
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.
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?
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.
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
Hello,
I am experiencing a related issue with [detonate]. When I create notes programatically the timing parameter appears to be 0 on playback even though when i open the detonate piano roll the pitches are shown at the correct times.
If i dump the event list then the 'internal event list' shows all of the event times to be zero while teh 'external event list' shows the times as entered .
If i mouse-edit a note event through the piano roll (drag or change length or pitch) and then dump [detonate] then the edited note has a non zero event time in the 'internal event list' while all of the programmaticaly entered but non-mouse-edited events remain zero.
Thanks for any insight or feedback !!!
(and sorry! im not sure how to include the example patch modified from above)
best ....
... deleted broken patch
hm, you fist send time and pitch as list into detonate and then you press "record"? that´s not ideal.
first of all, note on needs velocity or it is not a note on. and then message order in max is left to right and not right to left. ;)
detonate.maxhelp
trigger.maxhelp
sorry my example was adapted from above and i was in a bit of a rush earlier ... here is an updatded patch that is more explicit to the problem that I am encountering. Thankyou for your patience!
thanks roman !
"message order in max is left to right and not right to left. ;)" I think you mean the reverse, but thanks for catching the bug in the example i posted!
For good measure I added velocity and duration and increased the duration values to differentiate my issue from the thread above ... the new example is more explicit, but the problem remains in any case: "programatically generated events in [detonate] appear to report their timing parameter as '0' on playback"
... i'm going to dig around to see if i can uncover a work-around but any advices will be appreciated.
cheers
... so i've realized that i can duplicate the timing parameter to X1 and retreive it from there. That works for me but if anyone has any deeper insights in to what is going on with the above issue i'm interested and curious.
Cheers
works for me.
hi Roman, the problem i have specified refers to the internal event list or the [detonate] output when you click an nth msg in the example. Your post does not specifiy which part of the dump you are quoting (cropped out). The external part of my dump also looks just like this, so more context is needed.
You appear to be working on a mac so im wondering if this is exclusive to the windows ver. but without context im not sure.
best
i only pressed dump and that is all it outputs, which is correct. let me check the nth again.
"nth int" and "int" only outputs 0 as delta time, which could be wrong (i cant tell you offhand that is really wrong, but it does not make much sense because the piano roll shows the correct positions - and we need the time to replay the sequence)
8.3 win10 noaudio overdrive
"start", "next, next" also does not work. :/
bingo ... yes that's what i'm seeing. If i mouse-edit an even in the piano roll then the delta time is out put correctly. i'll grab a screen shot of my dump out ...
[detonate] dump
and this is what i get after i mouse drag an event in the piano roll ...
... weird no? The edited note now shows a time and its output reflects that when you click on the nth msg also, while the other two events continue to output an event time of 0 ... :/
i'm getting around it by using [coll] as a parallel data structure to manage playback and extend my dataset so really [detonate] is just an editing interface for me now, but would be nice to more seamlessly integrate playback with external midi data. and x1 or x2 could be used to work around it, but its a bit of a hassle ;)
maybe it is deprecated, like most useful objects.^^