Apart from that, there is only a partial implementation in mpc's MpcMidiInput:
if (syncScreen->in == index && syncScreen->getModeIn() != 0)
{
switch (mce->getStatus())
{
case ShortMessage::START:
sequencer->playFromStart();
break;
case ShortMessage::CONTINUE:
sequencer->play();
break;
case ShortMessage::STOP:
sequencer->stop();
break;
case ShortMessage::TIMING_CLOCK:
break;
}
}
Apart from that, we should revise behaviour of START, as per http://midi.teragonaudio.com/tech/midispec/seq.htm. In particular:
"In practice, most masters allow a 1 millisecond interval inbetween the MIDI Start and subsequent MIDI Clock messages in order to give the slave an opportunity to prepare itself for playback."
vmpc-juce
currently does not forward MIDI clock input messages tompc
, see https://github.com/izzyreal/vmpc-juce/issues/87.Apart from that, there is only a partial implementation in
mpc
'sMpcMidiInput
:So let's implement the
TIMING_CLOCK
case. One way to derive BPM from the current timing can be found here: https://forum.arduino.cc/t/read-midi-clock/1022060/14 But its correctness still needs to be verified.Apart from that, we should revise behaviour of
START
, as per http://midi.teragonaudio.com/tech/midispec/seq.htm. In particular: "In practice, most masters allow a 1 millisecond interval inbetween the MIDI Start and subsequent MIDI Clock messages in order to give the slave an opportunity to prepare itself for playback."