Im trying to make a program that reads a midi file, extracts the signature and tempo data to make a programable metronome. But I dont find the way, becase the Midibus library doesn’t reads midi files, and also I don’t know how to understand a midi file, because when I open a midi file with a text editor seems like is writen on hex or binary or kind of. As you can see, im not an expert, but I have some idea.
Also, I should say that i want to export the project to android, that’s why im doing that project on processing. How I can do it? I dont find any library that helps me.
Hi … I’m part way through writing a routine to parse and extract midi file data. It is as you say lots of hex to sort through! I hope to have something in next couple of weeks if you can wait until then?
Now, Im trying to improve the accurate of the metronome. I’ve made it with millis(), but it has 1-30ms delay sometimes, and it is noticeable. I’ll report any improvement!
If anyone has any idea, it’s welcome haha
Very nice How do you measure that delay? I don’t see any use of millis(). The only thing that comes to mind is, it’s important to measure times in an absolute time, and not relative, so tiny errors don’t add up to become big errors. Not sure if that applies in your program…
You on Windows by any chance?! The resolution of the clock used for this on Windows is about 16ms so that’s kind of expected. If you want an accurate time, you need to use System.nanoTime() - you can’t measure the accuracy of the accurate clock (nanoTime) using an inaccurate clock (millis). Also, you should cache the value of the clock (long ns = System.nanoTime()), not call it 3 times, because it might change.
btw - the post you cited is for a visual metronome. Attempting to control audio through a timer in the animation loop of draw() is never going to work very well!
That as well, but I was more meaning the 17ms with occasional 1ms and nothing in between, which suggest it’s reflecting the precision of the clock.
I actually changed the semantics of millis() in PraxisLIVE to reflect the high precision clock, and to always be the frame time (doesn’t change during draw()), which is far more useful for most things.
Yes, should be, and probably by running at even higher fps. Unless vsync kicks in of course. All of which are good reasons that this should be driven by logic in an audio specific thread rather than by the animation timer. Unfortunately, Processing is really lacking in this regard! Maybe Minim’s AudioListener can help?