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
If the handler receives a MIDI message and throws, the program keeps running as if nothing happend. But after the handler has thrown once, it will not be called ever again with any later MIDI messages.
Similar behavior occurs when throwing in getNextAudioBlock:
Once the 1000th buffer has been reached, audio will stop and not resume.
What is the expected behaviour?
Silently breaking the program is unexpected to me. I would expect the program to either abort fatally (which happens e.g. if you throw in the paint method), or catch the exceptions and do a jassertfalse. If catching exceptions is a performance issue, this could be only done if JUCE_DEBUG is enabled.
With the current behavior you will only notice that something went wrong if you have a debugger attached. Without a debugger, the program will continue as usual but the MIDI input will stop working.
For the audio handler the issue will be obvious immediately (since audio stops) but for the MIDI handler it's a bit more subtle to understand what happened (especially if the exceptions get thrown very rarely due to some corner case).
Operating systems
macOS
What versions of the operating systems?
macOS 14.5 (23F79)
Architectures
ARM
Stacktrace
No response
Plug-in formats (if applicable)
Standalone
Plug-in host applications (DAWs) (if applicable)
No response
Testing on the develop branch
The bug is present on the develop branch
Code of Conduct
I agree to follow the Code of Conduct
The text was updated successfully, but these errors were encountered:
Detailed steps on how to reproduce the bug
Create a standalone app, which has a
MidiInputCallback
implemented:If the handler receives a MIDI message and throws, the program keeps running as if nothing happend. But after the handler has thrown once, it will not be called ever again with any later MIDI messages.
Similar behavior occurs when throwing in
getNextAudioBlock
:Once the 1000th buffer has been reached, audio will stop and not resume.
What is the expected behaviour?
Silently breaking the program is unexpected to me. I would expect the program to either abort fatally (which happens e.g. if you
throw
in thepaint
method), or catch the exceptions and do ajassertfalse
. If catching exceptions is a performance issue, this could be only done ifJUCE_DEBUG
is enabled.With the current behavior you will only notice that something went wrong if you have a debugger attached. Without a debugger, the program will continue as usual but the MIDI input will stop working.
For the audio handler the issue will be obvious immediately (since audio stops) but for the MIDI handler it's a bit more subtle to understand what happened (especially if the exceptions get thrown very rarely due to some corner case).
Operating systems
macOS
What versions of the operating systems?
macOS 14.5 (23F79)
Architectures
ARM
Stacktrace
No response
Plug-in formats (if applicable)
Standalone
Plug-in host applications (DAWs) (if applicable)
No response
Testing on the
develop
branchThe bug is present on the
develop
branchCode of Conduct
The text was updated successfully, but these errors were encountered: