Synchronise to beats per minute / Send quantised messages

Question

I'm getting periodic signals (beats per minute) from a Transmitter and now want to call methods in a fraction of the period, e.g. send 1/1, 1/2, 1/4, 1/8, 1/16,.. notes.

My solution for this is to create a thread, do a busy wait and then execute the methods. The problem here is that listening to the signal, processing it and sending it back creates a delay of a few milliseconds (depending on the system).

So now I want to determine the delay between the incoming signal and the periodic signal of the thread and if the delay is != 0, stop the current thread and start a new thread after "bpm - delay" milliseconds. How can this be done ?

Illustration:

transmitter signal: |----|----|----|----|

******runner signal : |----|----|----|----|

delay runner signal by "onePeriod - delay" milliseconds:

transmitter signal: |----|----|----|----|

***"runner signal :**** |----|----|----|----|

Both signals are now in sync.

public class Quantiser implements Receiver{
    private int[] bpmsInMillis = new int[4];
    private int bpmInMillis=0;
    private double smallestNote = 1;
    private long period=0;

    private long fire=0;
    private long prevTimeStamp=0;

    private Runnable runny = new Runnable() {
        @Override
        public void run() {
            while(true){
                fire = System.nanoTime() + period;
                while(System.nanoTime() < fire){} // busy wait
                // Call some methods here.
            }
        }
    };
    private Thread thread = new Thread(runny);


    @Override
    public void send(MidiMessage message, long timeStamp) {

        // Calculate average bpm
        for(int i=0; i<bpmsInMillis.length-1;i++)
            bpmsInMillis[i] = bpmsInMillis[i+1];

        bpmsInMillis[bpmsInMillis.length-1] = (int) ((timeStamp - prevTimeStamp) / 1000);

        bpmInMillis = arithmeticMean(bpmsInMillis);
        prevTimeStamp = timeStamp;

        period = (long) (bpmInMillis * smallestNote * 1000000);

        if(!thread.isAlive()) {
            thread.start();
        }
        /*
        else{
            Calculate delay between signal and thread-signal.
            if(delay != 0){                    
                Delay new thread by "bpm - delay" milliseconds.
                Stop old thread.
                Start new thread.
            }
        */            
    }

    @Override
    public void close() {

    }

Answer 1

One option would be to implment a Phase-Locked Loop (PLL).

http://en.wikipedia.org/wiki/Phase-locked_loop

Basically, you'll need two threads: One thread sits in a loop waiting for the input beats, and each time it gets a beat, it records the time of arrival.

long time_of_last_beat;
while (true) {
    wait_for_next_beat();
    time_of_last_beat = System.currentTimeMillis();
}

The other thread sits in a loop that goes sixteen times as fast:

long semiquaver_duration = <starting guess>;
while (true) {
    notify_whoever_cares_that_its_time_for_the_next_semiquaver();
    Thread.sleep(sixteenth_note_duration);
    long phase_error = System.currentTimeMillis() - time_of_last_beat;
    semiquaver_duration += estimate_phase_correction(phase_error);
}

I'll leave it to you to write the estimate_phase_correction() function. A linear function of the given error with the right coefficient may be all you need. If you get it right, the 16x loop should "lock in" so that every sixteenth semiquaver happens exactly on the beat.

---

Improvements:

• have the beat loop compute the tempo.
• Base the starting guess for the semiquaver period on the current tempo.
• Notice significant (i.e. abrupt) tempo changes and re-set the semiquaver loop as needed.

Answer 2

In general, when I work with sound (usually sampled, not MIDI), I find it more accurate to use frame counts than elapsed time. With elapsed time there are too many unknowns (thread slicing, garbage collection, etc.). Latencies may vary, but 44100 frames (if that is the format) is always 1 sec.

With MIDI, doesn't every event have a field with the time that event is supposed to occur? I've seen readouts with both beats/measures and elapsed-time. I would use that info rather real-time time stamps when figuring any sort of positioning onto an existing Midi stream.

If this is something where the incoming is ASAP/real time, but you want to pass it through quantised, can you put scheduling info on the out-going Midi even if the incoming doesn't have it? Then you'd have a solid reference points for the positioning.

Reference on Real-Time. Low Latency Audio Processing in Java: https://diuf.unifr.ch/main/pai/sites/diuf.unifr.ch.main.pai/files/publications/2007_Juillerat_Mueller_Schubiger-Banz_Real_Time.pdf