Bug in GMS Makes High Speed Glitches

I’ve started working again on my Gestural Music Sequencer after putting it down at end of the quarter for grading and paperwork. The main task that I’m working on is managing the timing so that it’s no longer tied to the frame rate. To do this I’m using Java’s Thread class in Processing.org to drive the tempo independently from the frame rate. Thanks to toxi over at PostSpectacular.com and his response to a question on precise timing, I learned what was necessary to set note durations based on tempo created from Java’s System.nanoTime() method. So far I have enabled eleven durations, from a whole note down to a sixty-fourth note.

While implementing this feature I inadvertently created a bug that set the time interval to zero. I quickly fixed the bug, but not before hearing some pretty amazing sounding glitches out of Reason as it received a stream – make that a tsunami – of note on data as fast as the processor could send it. Here’s how it sounds when Reason is flooded with note on information. The high pitch ringing is caused by the frequency of notes being sent, which turns out to be about 739 Hertz, in other words, seven hundred thirty-nine notes a second. Not even Ingvay Malmsteen can play that fast.

GMS: Super Fast Notes

2 thoughts on “Bug in GMS Makes High Speed Glitches

  1. Yeah, that’s pretty much exactly how I had to do the timing junk, though I’m still using timeInMillis() rather than nanoTime(). I didn’t even know about nanoTime(), guess I’ll look in to that.

    Happy accident though, maybe you should make ‘0’ a time interval option (assuming it doesn’t cause a complete disaster in the software’s that are listening to it)?

  2. Hey, this is super & very interesting! Need to check out your GMS and see if there are any overlaps with the composer/sequencer I’ve started building for our Forever installation. Maybe we can even somehow join forces (if you’re up for it)… Will ping you sometime soon about that, cheers!

Leave a Reply