Comments on: Converting 24PPQ Midi Sync in Java/Processing http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/ Mr. Anti-Focus Wed, 01 Feb 2012 12:07:53 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Edmund Klaus http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-847 Edmund Klaus Fri, 25 Feb 2011 07:32:11 +0000 http://www.grantmuller.com/?p=664#comment-847 <p>Right. The sequencer is a little beast.</p> <p>But last night i did some speed test on it. I tried to play 1/512 notes with the speed set to 240 BPM, what is something that maybe only Aphex Twin will ever use ;-). And it did well. At this rate the time between two notes is at 1,953125 ms. I measured that, and it matched well, except of sometimes a latency of 1 ms appeared. What mybe was because of System.out.println statements. So i think it is nice to use the java sequencer, to get a nice timed midi sequencing.</p> <p>I will give the syncing problem another try. I've worked out some new strategy to sync it. Hopefully this will finally work.</p> Right. The sequencer is a little beast.

But last night i did some speed test on it. I tried to play 1/512 notes with the speed set to 240 BPM, what is something that maybe only Aphex Twin will ever use ;-) . And it did well. At this rate the time between two notes is at 1,953125 ms. I measured that, and it matched well, except of sometimes a latency of 1 ms appeared. What mybe was because of System.out.println statements. So i think it is nice to use the java sequencer, to get a nice timed midi sequencing.

I will give the syncing problem another try. I’ve worked out some new strategy to sync it. Hopefully this will finally work.

]]> By: ed.klaus http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-845 ed.klaus Thu, 24 Feb 2011 20:31:47 +0000 http://www.grantmuller.com/?p=664#comment-845 <p>So i will have a look at your GOLSequencer code. Thank you for your replies.</p> So i will have a look at your GOLSequencer code. Thank you for your replies.

]]> By: Grant Muller http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-844 Grant Muller Thu, 24 Feb 2011 18:47:51 +0000 http://www.grantmuller.com/?p=664#comment-844 <p>Thats correct. For the GOLSequencer, I have basically built a sequencer, and all the event handling for starts, stops, syncs, etc take place right in there. The Sequencer class is a little draconian, you should be able to do it without needing that class.</p> Thats correct. For the GOLSequencer, I have basically built a sequencer, and all the event handling for starts, stops, syncs, etc take place right in there. The Sequencer class is a little draconian, you should be able to do it without needing that class.

]]> By: Edmund Klaus http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-843 Edmund Klaus Thu, 24 Feb 2011 18:19:55 +0000 http://www.grantmuller.com/?p=664#comment-843 <p>Yeah it's very tricky. :-)</p> <p>So if i get that right, you don't even use the "javax.sound.midi.Sequencer" class to handle your MidiEvents / MidiMessages. And send your midi messages by yourself? Directly from your step sequencer application? Is that correct?</p> Yeah it’s very tricky. :-)

So if i get that right, you don’t even use the “javax.sound.midi.Sequencer” class to handle your MidiEvents / MidiMessages. And send your midi messages by yourself? Directly from your step sequencer application? Is that correct?

]]> By: Grant Muller http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-842 Grant Muller Thu, 24 Feb 2011 17:26:22 +0000 http://www.grantmuller.com/?p=664#comment-842 <p>This is where it would get a bit tricky. To feed these message back in you effectively have to intercept the original sync messages from some external device (say, from your DAW) and use another thread to sub divide and resend those new pulses to your application. In the case of the RWMidi library, the MidiInput class is simply an implementation of javax.sound.midi.Receiver. The overridden 'send' method in this class contains the code to create a thread, subdivide the incoming pulses and send them out to a 'plug' method. The plug methodology is based on reflection and assumes you have an event handler in your app that can do something with the incoming values. You can see that code <a href="https://github.com/gmuller/rwmidi/blob/master/src/rwmidi/MidiInput.java" rel="nofollow">here on github</a></p> <p>Let me know if you have any questions, but that is how I handled it in a raw fashion. I'm not certain how you would do that with the Sequencer object, but you could create a separate Receiver method like this and feed that sequencer with the new pulses.</p> This is where it would get a bit tricky. To feed these message back in you effectively have to intercept the original sync messages from some external device (say, from your DAW) and use another thread to sub divide and resend those new pulses to your application. In the case of the RWMidi library, the MidiInput class is simply an implementation of javax.sound.midi.Receiver. The overridden ‘send’ method in this class contains the code to create a thread, subdivide the incoming pulses and send them out to a ‘plug’ method. The plug methodology is based on reflection and assumes you have an event handler in your app that can do something with the incoming values. You can see that code here on github

Let me know if you have any questions, but that is how I handled it in a raw fashion. I’m not certain how you would do that with the Sequencer object, but you could create a separate Receiver method like this and feed that sequencer with the new pulses.

]]> By: Edmund Klaus http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-841 Edmund Klaus Thu, 24 Feb 2011 10:51:29 +0000 http://www.grantmuller.com/?p=664#comment-841 <p>This is a very interesting article. I am at the moment working on a flexible midi looper that meets my needs. The way it works, is that i let it run and play some notes and it repeats them on and on again. This is the first stage. Later i want it to manage more tracks at one time, change loop positions, ...</p> <p>I found out that the standard Java Midi sequencer is not synchronizable at all. So first i started to calculate the incoming clock data bpm and set this in the sequencer (setTempoInBPM(...)). But that is no synchronizing at all. Next i did it in another way, i took the incoming sync messages (24 per quarter note) and everytime i got one, i called "setTickPosition(...)" on the sequencer. The correct tick position is taken from an array that i instanciated before. This works perfect. My sequencer is perfectly synced, even at fast BPM changes.</p> <p>The problem is: I don't want a step sequencer, with a hard resolution of 16th or 32th notes. I want the sequecer to play a note event on every position it is recorded and to hold the note a slong as it has been recorded.</p> <p>But: "setTickPosition(...)" behaves in a way that it send an "all notes off", when it is called to go to a specified tick. I think that is a good idea, because if it has to move a few ticks away from the current position it could loos for example a "note off" event and hold a note forever!</p> <p>I took a look at your code, where you split the 24 sync messages up to several ones, but did not find the code where you feed the sync messages to the sequencer. Do you also do it in the way, i am trying to do that?</p> <p>Maybe you have some idea, how to "really" synchronize the java sequencer (not step sequencer). Or is it already synchronized proper, int the way you do that.</p> <p>Would be great if you'd have some idea on that.</p> This is a very interesting article. I am at the moment working on a flexible midi looper that meets my needs. The way it works, is that i let it run and play some notes and it repeats them on and on again. This is the first stage. Later i want it to manage more tracks at one time, change loop positions, …

I found out that the standard Java Midi sequencer is not synchronizable at all. So first i started to calculate the incoming clock data bpm and set this in the sequencer (setTempoInBPM(…)). But that is no synchronizing at all. Next i did it in another way, i took the incoming sync messages (24 per quarter note) and everytime i got one, i called “setTickPosition(…)” on the sequencer. The correct tick position is taken from an array that i instanciated before. This works perfect. My sequencer is perfectly synced, even at fast BPM changes.

The problem is: I don’t want a step sequencer, with a hard resolution of 16th or 32th notes. I want the sequecer to play a note event on every position it is recorded and to hold the note a slong as it has been recorded.

But: “setTickPosition(…)” behaves in a way that it send an “all notes off”, when it is called to go to a specified tick. I think that is a good idea, because if it has to move a few ticks away from the current position it could loos for example a “note off” event and hold a note forever!

I took a look at your code, where you split the 24 sync messages up to several ones, but did not find the code where you feed the sync messages to the sequencer. Do you also do it in the way, i am trying to do that?

Maybe you have some idea, how to “really” synchronize the java sequencer (not step sequencer). Or is it already synchronized proper, int the way you do that.

Would be great if you’d have some idea on that.

]]> By: RWMidi, GMS, and GOL Sequencer: Adventures in Social Coding | Grant Muller http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-835 RWMidi, GMS, and GOL Sequencer: Adventures in Social Coding | Grant Muller Fri, 18 Feb 2011 16:43:24 +0000 http://www.grantmuller.com/?p=664#comment-835 <p>[...] A short time after that, Mr. Keston approached me with what I thought at the time was a strange requirement: modify the library to support greater than 24PPQ for recognizing 64th and 128th note resolutions. In plain English, John wanted the GMS to support 64 and 128 notes using plain-jane MIDI clock. I thought it couldn’t be done, but loved the challenge, and modified the RWMidi library accordingly. It was a doozy. [...]</p> [...] A short time after that, Mr. Keston approached me with what I thought at the time was a strange requirement: modify the library to support greater than 24PPQ for recognizing 64th and 128th note resolutions. In plain English, John wanted the GMS to support 64 and 128 notes using plain-jane MIDI clock. I thought it couldn’t be done, but loved the challenge, and modified the RWMidi library accordingly. It was a doozy. [...]

]]> By: Grant Muller http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-329 Grant Muller Fri, 01 Jan 2010 17:33:54 +0000 http://www.grantmuller.com/?p=664#comment-329 <p>No problem Daniel, thanks for the comment. Let me know what you come up with in the end. One of the harder things to wrap your mind around is that amount of time that passes in-between each pulse, and that your implementation will be limited by the number of instructions you can process in that span of time. In a C++ or lower level code implementation its not an issue to drop to 48 or 96 PPQ, but with something like Java you'll never be able to handle that many pulses per quarter note at "regular" tempos (120 bpm+). One non-code workaround is of course just to double the tempo of the source clock, and count two measures for one on your client. Let me know!</p> No problem Daniel, thanks for the comment. Let me know what you come up with in the end. One of the harder things to wrap your mind around is that amount of time that passes in-between each pulse, and that your implementation will be limited by the number of instructions you can process in that span of time. In a C++ or lower level code implementation its not an issue to drop to 48 or 96 PPQ, but with something like Java you’ll never be able to handle that many pulses per quarter note at “regular” tempos (120 bpm+). One non-code workaround is of course just to double the tempo of the source clock, and count two measures for one on your client. Let me know!

]]> By: Daniel Rosenstark http://grantmuller.com/converting-24ppq-midi-sync-in-javaprocessing/comment-page-1/#comment-328 Daniel Rosenstark Fri, 01 Jan 2010 11:32:58 +0000 http://www.grantmuller.com/?p=664#comment-328 <p>I am so amazed and glad I found this article. I just realized that reacting to 24-pulses-per-quarter is totally wrong, but I had no idea what to do. Of course I still have to read, understand, and implement what you wrote, but finding your article was half the battle. I'll report back when I've finished that, but thanks in advance!</p> I am so amazed and glad I found this article. I just realized that reacting to 24-pulses-per-quarter is totally wrong, but I had no idea what to do. Of course I still have to read, understand, and implement what you wrote, but finding your article was half the battle. I’ll report back when I’ve finished that, but thanks in advance!

]]>