User's Manual
Table Of Contents
- 1 Welcome
- 2 Quick Start
- 3 MIDI Setup Guide
- 4 Program Interface
- 5 MIDI Translator Concepts
- 6 The Project
- 7 The Preset
- 8 The Translator Entry
- 9 Actions
- 9.1 MIDI
- 9.2 Keystrokes
- 9.3 Timer
- 9.4 Preset Change
- 9.5 Disable/Enable Processing Actions
- 9.6 Mouse (Outgoing)
- 9.7 Execute File (Outgoing)
- 9.8 Serial Port
- 9.9 AppleScript
- 10 Rules and Variables
- 11 Settings
- 12 Behind the Scenes
- 13 Tips & Tricks
- 14 Usage Example
- 15 MIDI Translator in Hardware: the BomeBox
- 16 Reference
Bome MIDI Translator: User's Manual 12 Behind the Scenes
Keystroke emulation takes a while to execute. So if you generate keystrokes
from a MIDI message but also do a lot of MIDI-to-MIDI translation, the
emulated keystroke would interrupt the MIDI translations until the
keystrokes are sent. For that reason, Outgoing Keystrokes are usually
enqueued for asynchronous execution.
Asynchronous execution has the advantage that it allows for much better
runtime performance. But on the other hand, it will be impossible to foresee
in which sequence Outgoing Actions are going to be executed: in the
example above, MIDI events arriving after the Outgoing Keystroke action
was enqueued are likely be processed before the Outgoing Keystroke(s) are
fully sent.
To make processing deterministic, the engine always guarantees that
outgoing actions of the same type are executed in the correct order.
12.3 Parallel Processing
MIDI Translator's engine is using advanced optimization techniques to
provide the best realtime processing performance even at heavy load and
when processing many different types of incoming events.
In particular, the engine is multi-threaded, using all processor cores on
modern multi-core processors. For example, the engine can process MIDI
events from different MIDI ports simultaneously. Some Outgoing Actions
can be executed simultaneously with other Outgoing Actions, some
Outgoing Actions are forced to be executed asynchronously in a separate
thread (see the example with Keystrokes in the previous chapter).
Multi-threading is nice for performance, but it may bring unexpected
behavior. In particular, be aware of parallel processing when using global
variables. Race conditions may occur where two events are processed
simultaneously and both change the same global variable. As a general rule,
you should use local variables whenever possible. Local variables' scope is
restricted to the particular incoming event, so it is not possible for a
concurrent event to cause problems with local variables.
(c) 2019 by Bome Software GmbH & Co. KG page 80