I’m trying to get the sample position of incoming midi messages in the audio processor process block. I thought getTimeStamp() would return the position in the buffer in samples but it always seems to return 0?
void processBlock (juce::AudioBuffer& buffer, juce::MidiBuffer& midi) override
for (const auto metadata : midi) // 
const auto msg = metadata.getMessage();
DBG(msg.getTimeStamp()); //always prints 0
Will get you that information.
Try adding another instance of your plugin in your DAW. Create a midi sequence and duplicate it so that both instances are playing the same midi sequence at the same, and check if this gives you different results.
If you are using Logic as your DAW and you only have one channel in your project, Logic will slice its buffers so that midi messages will appear at position 0. I’m sure other hosts do it as well.
But when having multiple channels, slicinig buffers so that every message on every channel will be at position 0 is not possible, so then you should have a non-zero timestamp.
But in any case, whatever you get from your
getTimeStamp() output is what you should be using for any purpse, because it is the the true timestamp relevant to the buffer it sits in.
This is possible if you play live with a hardware MIDI controller. In this case, the host makes sure that the note plays as soon as possible and this is timeStamp 0.
I tried your suggestion in FL studio and it was still always zero. However I tested the plugin in reaper and bitwig and it seems to be working. So this is definitely something specific to fl studio
And what is your use case of the timestamp value? Is getting timestamp 0 somehow causes other bugs in your process chain?
If not, just use whatever you get from
getTimeStamp() and you should be fine.
I’m making a simple plugin that changes the midi channel of the incoming midi messages to something else,
so I just want to make sure that the plugin keeps the original timing of the messages. .
Easy to test. Convert the midi sequence to an audio clip and test it against a metronome.
Make sure to use multiple channels for the reason I stated above.
Okay I tested it: with non-fixed buffersizes (which is the default in fl studio) the timings were accurate but with fixed buffersize there was an inconsinstent amount of delay to each note and really short notes wouldn’t get triggered at all. So I guess it’s just FL studio not working with fixed buffersizes, I’ll have to ask about this in the imageline forums. Thank you for your help
idk but it could also be that fl just always sends at sample 0 but makes sure to split the buffer accordingly at variable buffer size. maybe they just didn’t think it through for fixed buffer size as that is not the default setting in fl
Yeah I think this is how it works. I tested to see if there was ever more than one midi message in a single buffer using variable buffer size, and there wasn’t (except when two or more midi notes were on the exact same tick)