You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For clarity I am opening a new, separate issue as I'm currently debugging and stress testing the hosting of AUv3 plugins on iOS.
I noticed some MIDI messages are completely discarded which can result in hanging notes as they don't reach the AudioUnitPluginInstance.
In MidiInputDeviceNode::processSection(), we can see this bit of code which discards scheduled MIDI events if the last block took too long to process:
// if it's been a long time since the last block, clear the buffer because
// it means we were muted or glitching
if (timeNow > lastReadTime + maxExpectedMsPerBuffer)
{
//jassertfalse
numMessages = 0;
}
maxExpectedMsPerBuffer is calculated this way in MidiInputDeviceNode::prepareToPlay() :
While I understand it might be necessary to flush accumulated or old MIDI messages, it's quite easy for this check to be triggered even with just one plugin running.
I wonder if this could be rendered optional, or, make the check slightly more accurate.
BTW, I am feeding MIDI events through a VirtualMidiDevice connected to an AudioTrack hosting an ExternalPlugin.
Even in release mode and with just one plugin this issue arise.
Happy to discuss solutions with the team to make hosting AUv3 on iOS rock solid!
Thanks in advance,
Cheers!
The text was updated successfully, but these errors were encountered:
Hey,
For clarity I am opening a new, separate issue as I'm currently debugging and stress testing the hosting of AUv3 plugins on iOS.
I noticed some MIDI messages are completely discarded which can result in hanging notes as they don't reach the
AudioUnitPluginInstance
.In
MidiInputDeviceNode::processSection()
, we can see this bit of code which discards scheduled MIDI events if the last block took too long to process:maxExpectedMsPerBuffer
is calculated this way inMidiInputDeviceNode::prepareToPlay()
:BTW,
blockSize
is 282 in my case, adjusted from the 256 samples latency inEditPlaybackContext::setNode()
:blockSize = juce::roundToInt (blockSize * (1.0 + (10.0 * 0.01))); // max speed comp
While I understand it might be necessary to flush accumulated or old MIDI messages, it's quite easy for this check to be triggered even with just one plugin running.
I wonder if this could be rendered optional, or, make the check slightly more accurate.
BTW, I am feeding MIDI events through a
VirtualMidiDevice
connected to anAudioTrack
hosting anExternalPlugin
.Even in release mode and with just one plugin this issue arise.
Happy to discuss solutions with the team to make hosting AUv3 on iOS rock solid!
Thanks in advance,
Cheers!
The text was updated successfully, but these errors were encountered: