I have an issue with the MidiMessage positionning into the buffer. It seems that some messages are regularly shifted from the duration of the buffer. This is obvious: if I have a buffer of 20ms, some pulse occur 20ms too late, and the time shift change depending on the buffer size.
I'm working on a proxy plug-in aimed to control hardware equipment through CopperLan. I'm monitoring digital output with a scope to accurately measure the jitter. The idea is that the MidiMessages received in the processBlock are forwarded through CopperLan with a timestamp (calculated from the samplepos) telling exactly when it must be applied. This timestamp is referenced to the CopperLan's global time shared between all equipment, this is reliable (already validated).
I send also a (not-timestamped) message on each processBlock call, so I can monitor this call regularity on the scope: there is sub-millisecond jitter on processBlock.
So in my opinion the message shift is due to a bad MidiMessage positionning, sometimes a message is schedduled in the next buffer instead of the current one... This has been observed on Mac, AU plug-in, under Ableton Live and Numerology.
It goes completely unnoticed if you're using small buffers, but my customer does not pay much attention to the buffer size since he plays preprogrammed sequence. However, he requires high precision trigger (drum context).
Is this a known issue? Is there a solution?
If you're talking about what happens inside a plugin, then those timestamps were generated by the host.. There's not really much scope for the plugin wrapper code to get the value wrong, it's just a sample number.
Yes indeed, I read Juce code and understood that it's just forwarding information provided by the host... so it means that the host is triggering some MIDI events one buffer too late
It seems to me so incredible...
If this is true, how can Expert Sleepers guys trigger sample accurate events on their devices? however they claim they do!
I may be wrong, but looking at the Expert Sleepers stuff, it looks like they are sending audio over S/PDIF to thier hardware, which is what gives them 'sample accuracy' at that end of the chain. I'm not sure thier claim covers what you are talking about, ie. the sample accuracy of midi events within the plugin. But, I only did a quick scan of material relating to the product line.
Ok ok... I found the issue... I was convinced that the buffer size passed to the processBlock was always the same, equal to the value passed to prepareToPlay. I was wrong... I setup 2048 samples, and processBlock is usually processing 120 to 200 samples buffers... So my timestamp calculation based on (buffer count x buffer duration) was wrong. Now I update the absolute time reference at the end of each processBlock, based on the real buffer length, and it works like a charm: sub-millisecond jitter on a hardware that can be located 400m away :-)
This issue was so stupid... copy 100 times "always, always check assumptions!!!"...