Question

I currently use a Receiver class which receives my Midi Events from my Midi keyboard.

With each event the send() method returns some information along with the timestamp of the MidiEvent.

When I create a Calendar instance and getTimeInMillis() I get a completely different number to the Receiver's timestamp. The difference of the two values change every time, so I know it’s not just a constant value.

Is there a way to get the Receiver's timestamp value at any time without it being through the Receiver's send() method?

By this I mean get a timestamp in a method which follows the same time scale as the Receiver's timestamp.

Answer 1

I believe you may be operating under a misconception – the value of the timestamp Receiver.send() expects is in microseconds, not milliseconds like in Calendar. That means you’re off by a factor of 1000, which would appear to be a ‘constantly changing value’.

I don’t know whether you want to just reduce the resolution of your timestamps, or use the microseconds. It would depend on the exact nature of your application, what data you’re getting in your messages, and what you want to do with them.

---

EDIT:

This is based on the assumption that you’re receiving the data, not that you’re populating the timestamp value.
If you need to preserve the resolution, here are some options:

1. Use the java.sql.Timestamp subclass of Date. This can store resolutions down to nanoseconds (more then what you need). However, all of the standard date utilities in the library have some odd behaviour, and the namespace is perhaps less than ideal.
2. Write your own JRE/JDK/JVM. Calendar and Date are part of the standard library. If you want to distribute your code, you have to expect people to use your version of the standard library. This is inadvisable, for a large number of reasons.
3. Find/Write your own timestamp-type class. There are probably audio libraries that have a relevant implementation. If you do have to write your own, I’d probably grab the code from Joda Time, and just change the resolution – that would still be a fair bit of work, though.
4. Just leave the value as the primitive. It’s unlikely you need anything more than the numeric values, after all (not like you need to translate to year-month-day values). Although it would be good to have type safety for this, especially in light of the resolution differences. If this doesn’t match your use case, I’m sorry.