class MyClass : public AudioIODeviceCallback, public MidiInputCallback
void MyClass::handleIncomingMidiMessage(MidiInput* source, const MidiMessage& message)
void MyClass::audioDeviceIOCallback(const float** inputChannelData, int numInputChannels, float** outputChannelData, int numOutputChannels, int numSamples)
while (midiBufferIterator.getNextEvent(midiMessage, samplePosition))
// samplePosition is always zero!
The sampleposition found there, in the midi event loop processing is always zero. This is “ok” for small buffer sizes, but running my code with large (6000+ samples) buffersizes makes everything behave craaaaazy
Am I missing something? Are realtime midi events really always timed at zero? Why not add a [buffersize] latency and at least have jitter which is less than a buffersize?
FYI, I’m using Juce standalone, so both the audio and midi are handled by Juce.
Just a guess but the timestamp is relative to the beginning of the audio i/o block. For MIDI inputs, a positive value would mean a keyboard note was pressed in the future? I think the timestamp is more relevant for MIDI output rather than MIDI input. If you want to jitter your inputs for some reason then you can do it yourself.
But more importantly I think if you’re doing live processing, you want your buffer to be as small as possible without getting dropouts this way MIDI input events will have minimum latency.
Disclaimer: I have done very little with Juce MIDI.
This is not entirely correct: incoming midi should be timestamped to avoid midi jitter. And Juce does this, but I think my soundcard/midi input start misbehaving if I put breakpoints in the audio thread.
Imagine all midi events have timestamp zero, the most granular input you can then do is buffersize!
Huh? I’m confused… the best way is to add 1 buffersize of latency (or perhaps the input latency) to all the timestamps, as they come in, not add a random timestamp.
Again, just like Juce does I think!
It timestamps the incoming midi timestamps with a timestamp relative to the current buffer time.