detonate reads out a delta time value of -1 when reporting the last note event. You can use this to test that the read is complete.

Thanks, but I'm not sure that's the same issue. Just to clarify, I meant when [detonate] is finished reading a MIDI file from disk via the "read" message. How I could use the -1 identifier to test that the read is complete? The only idea I have with that method is to use an [uzi] every second or so after "read" is sent to [detonate]. I made a sample patch below, but it seems a bit clunky because there's no way (that I know of) to know how many bangs the [uzi] should send, and also if the user clicks "Cancel" when prompted for a MIDI file, it will continue checking for that -1 indefinitely.

The problem is essentially that if a user clicks a button in the GUI to read a MIDI file, browses for the file, and clicks "Open," the file will load into [detonate], but nothing will be output until something causes [detonate] start stepping through the data. In my case, as soon as the MIDI file is loaded, I want to rapidly step through its contents in order to draw the notes in the sequencer.

Try replacing metro in your patch with a [deferlow]-- it _may_ work for all circumstances, and at least _should_ work for most situations, I think.

OK try this-- should be reliable

Thanks a lot Terry, that's perfect. I actually replaced the [dropfile] with [opendialog] because this also defines the file path at the same time the read command is sent to [detonate], but yeah... pretty much the same thing. Thanks!