Yes, I’ve noticed that some developers seem to think that if it works in AUM then that automatically means other host apps are to blame if their app doesn’t work properly in them. Seems ridiculous to me.
My assumption isn’t that the hosts are to blame: I’ve already informed the developer of MPEdie about the problem as well and suggested they check it in hosts other than AUM if nothing else.
In Drambo, everything MPEdie emits at sample offset 0 arrives (its MPE config burst, and bend generated in blocks with no touches). Everything carrying a non-zero in-block offset doesn't, which is Note On and Note Off, since those are timestamped at the sample where the touch happened. That's why the occasional stuck note still follows pitch bend.
The likely reason: JUCE's AUv3 wrapper prefers MIDIOutputEventListBlock when a host offers one, and on that path it writes each packet timestamp as a block-relative offset, passing mSampleTime only as the list's eventSampleTime. On the older MIDIOutputEventBlock path it adds mSampleTime, i.e. absolute. AUM is the one host where MPEdie works.
So: does Drambo set MIDIOutputEventListBlock, and how do you read the per-packet timestamps, absolute, relative to eventSampleTime, or ignored?
Hi @giku , Diego here, MPEdie's developer, following up on my own bug.
It was mine, and it's fixed. But there's something on your side worth knowing, because I only got around it by accident and the next plugin won't.
In Drambo, a note message that shares a timestamp with pitch bend, CC or channel pressure on the same channel doesn't reach the next module. On its own it does.
Minimal repro — MPEdie into MIDISpy, one finger, all filters on:
CH2 PITCHBEND 127 63 ← arrives
CH2 CC 74 64 ← arrives
CH2 PRESSURE 0 ← arrives
CH2 NOTE ON 60 nn ← does not arrive
The same four messages in AUM all arrive. It isn't the order — sending the note first changes nothing — and it isn't the channel, since everything else on that channel gets through. Strip the stream to notes only and they come through fine. It also costs Note Offs: with a finger sliding, the release lands in a block full of expression updates and the note hangs.
My fix was to emit notes one sample after everything else, which sidesteps it entirely.
Why it may be worth a look at your end: the MPE spec asks that a note's initial bend, timbre and pressure be sent before the Note On, on the same channel, and the obvious way to implement that is to put the whole group at the sample where the touch happened. That's what MPEdie did, and it's why it was silent. The spec asks for the ordering, not for a particular spacing, so one sample of separation was enough and leaves me just as compliant as before. I can't tell you what other controllers do at that resolution, a MIDI monitor's timestamp column is far too coarse to show sample offsets, so I'm only reporting mine.
Happy to test any build, and thanks for saying you'd look, that mattered while I was still lost.
Comments
Thanks! I'm gonna check it.
btw.
Some devs test only in aum.
Then some initialization timing differences between daws reveal internal bugs.
But thats only an assumption, most cases are like that.
Yes, I’ve noticed that some developers seem to think that if it works in AUM then that automatically means other host apps are to blame if their app doesn’t work properly in them. Seems ridiculous to me.
My assumption isn’t that the hosts are to blame: I’ve already informed the developer of MPEdie about the problem as well and suggested they check it in hosts other than AUM if nothing else.
Hi Giku,
MPEdie's developer here...
In Drambo, everything MPEdie emits at sample offset 0 arrives (its MPE config burst, and bend generated in blocks with no touches). Everything carrying a non-zero in-block offset doesn't, which is Note On and Note Off, since those are timestamped at the sample where the touch happened. That's why the occasional stuck note still follows pitch bend.
The likely reason: JUCE's AUv3 wrapper prefers MIDIOutputEventListBlock when a host offers one, and on that path it writes each packet timestamp as a block-relative offset, passing mSampleTime only as the list's eventSampleTime. On the older MIDIOutputEventBlock path it adds mSampleTime, i.e. absolute. AUM is the one host where MPEdie works.
So: does Drambo set MIDIOutputEventListBlock, and how do you read the per-packet timestamps, absolute, relative to eventSampleTime, or ignored?
Thanks,
Diego
Just tagging you in @giku to make sure you see Diego’s message above.
Hi @giku , Diego here, MPEdie's developer, following up on my own bug.
It was mine, and it's fixed. But there's something on your side worth knowing, because I only got around it by accident and the next plugin won't.
In Drambo, a note message that shares a timestamp with pitch bend, CC or channel pressure on the same channel doesn't reach the next module. On its own it does.
Minimal repro — MPEdie into MIDISpy, one finger, all filters on:
The same four messages in AUM all arrive. It isn't the order — sending the note first changes nothing — and it isn't the channel, since everything else on that channel gets through. Strip the stream to notes only and they come through fine. It also costs Note Offs: with a finger sliding, the release lands in a block full of expression updates and the note hangs.
My fix was to emit notes one sample after everything else, which sidesteps it entirely.
Why it may be worth a look at your end: the MPE spec asks that a note's initial bend, timbre and pressure be sent before the Note On, on the same channel, and the obvious way to implement that is to put the whole group at the sample where the touch happened. That's what MPEdie did, and it's why it was silent. The spec asks for the ordering, not for a particular spacing, so one sample of separation was enough and leaves me just as compliant as before. I can't tell you what other controllers do at that resolution, a MIDI monitor's timestamp column is far too coarse to show sample offsets, so I'm only reporting mine.
Happy to test any build, and thanks for saying you'd look, that mattered while I was still lost.
Diego
Thanks for the feedback, I'm gonna check it on my side and get back to you.
Sorry for the delay. It’s been a busy time with the release.