Hello.
I've written some software that receives MIDI note on/note off messages from my drum kit. The messages include a timestamp that increases over time. What I would like to do is use this timestamp to elminate the latency between when I strike a drum pad and when I receive the MIDI message. Is there a way I can send a message to my drum kit to set the timestamp to a particular value or to zero?
I have looked through the specs, but I'm a bit confused about whether or not this is possible.
Thanks,
Carl
Hello,
You say that it is your own software that is receiving the messages from the drumkit. Are the timestams you refer to being generated by your software, or are they originating from the drumkit. If the latter, what sort of messages are they? Some sort of example of the data received, incl the timing data, would be a help.
What is the drumkit? You don't say. Would need to check the manual etc for the equipment to see what options there might be. Your software maybe could send one of the 'System Real Time' messages, but the drumkit would need to know about these and be able to respond to it. Check the Midi Implementation Chart to see if this is indicated for 'Received' data.
Geoff
Hello.
Thanks for replying. I am using the Java MIDI library, specifically Receiver. I get the "timestamp" field, which I believe is being sent from the drum kit, since if I restart the kit, the timestamp resets (although it could be being generated by the receiving hardware, but I have no way to know for sure)
The specific drum kit is a Roland TD1-DMK. Unfortunately the information provided by Roland regarding the MIDI capabilities is sparse, although the user manual states that the interface is "USB MIDI (Transmitting only)", so I am probably flogging a dead horse.
If it is the case that the drum kit does not accept MIDI commands, presumably the timestamp can only be use to determine the time between MIDI events from the drum kit, and can't be used to synchronise those events with external events?
Thanks,
Carl
Hello,
Thanks for the update.
What is running the 'Receiver'? According to the notes for 'Receiver' that you link to, 'Receiver' is generating the timestamp, in ms. So this is not MIDI data, it would be up to you to do something with this data and convert it to valid delta time if you wanted to do anything 'midi' with this.
I'll look up regarding the Roland device, there OUGHT to be a MIC. However the bit you quote regarding 'Transmit ONLY' suggests that the device will NOT respond to Real Time messages.
I've lookd at the manual online for the TD-1DMK - I assume this is the correct one?
The manual does not include any Midi Implementation Chart. I understand that any midi device SHOULD include this, but maybe the midi implementation is so limited that there is little point.
Yes, as you say, there is a note to say that the device does not receive (recognise) any midi messages. If this is the case then you cannot do what you were hoping.
Geoff
Just to add to the conversation so far, if you look at page 10 of the owners' manual (TD-1_eng02_W.pdf) you will see in the second (right hand) column, underneath the list of MIDI note numbers the following "* The TD-1 does not receive any MIDI messages".
JohnG.
An electronic drum kit that can't receive midi.....
One wonder what Roland where thinking there, selling upgrade modules LoL
Hello.
The code I am using is
[code type=markup]
Transmitter transmitter = midiDevice.getTransmitter(); // midiDevice is the drum kit
transmitter.setReceiver(new Receiver() {
@Override
public void send(MidiMessage message, long timeStamp) {
// This is where I receive the drum kit messages
.
.
.
}
@Override
public void close() {
}
});
[/code]
MIDI 1.0 does not have any timestamps. You did not say what platform your software is running on. I assume those timestamps are from the operating system's MIDI API, not from the Roland device. The API hands you MIDI data with timestamp that indicates when the MIDI event arrived in the OS. There is no way to use that to remove latency of the incoming transport.
Mike.
Chair of MIDI 2.0 Working Group