MIDIOutput¶
Send data stream to a MIDI Output Port.
This node can send MIDI data streams to a device that's specified by name, which typically corresponds to a sound card, or an OS-provided MIDI port, but which can also include ports presented by various software applications (e.g., Loopmidi on Windows). On Linux/MacOS this can also include "virtual" MIDI ports, and the node can create such a named virtual port on demand if one does not yet exist. The node can currently send two kinds of MIDI messages, "note on" messages (equivalent to key presses on a MIDI keyboard), as well as "control change" (cc) messages, which correspond to actions of various other widgets on such keyboard (levers, sliders, buttons, etc.) or other MIDI-compatible devices. It's also possible to have the node automatically send "note off" messages when a note is no longer playing via the note_messages parameter. The node can send data simultaneously over any combination of MIDI channels (1-16), and it can accept data from multiple streams. Marker streams are ignored, but all other numeric data is generally emitted. There are two possible schemes for determining the MIDI channel that some value will go to: either based on the names of the incoming data channels (if a space axis is present), using a mapping dictionary that can be provided, and where multiple channels can go to the same MIDI channel OR based on the name of the stream (if multiple streams are incoming), where a simlar name-to-channel table can be specified. Generally, if a mapping match is found based on channel names, it takes precedence over a stream name match, and if nothing matches (or no rules are given), the data are sent over channel 1 (thus one can group data easily by stream, but have selective per-channel overrides on top of that). If time and/or instance axes are in the data, they are sent ordered by increasing time, but otherwise immediately upon arrival in the node. The type of MIDI message can be controlled as follows: if a feature axis is present, a Control Change message is sent for every data value, using a message type that depends on the respective feature name, where names can be either number strings (corresponding to 0-based MIDI control #'s, e.g., '10' meaning "Pan"), or the name of predefined MIDI control parameter (e.g., "Effect Control 2"), or a substring of a MIDI parameter (e.g., "Legato" for "Legato Footswitch"; note that if there are multiple matches, the one with the lower number will be taken). For convenience, a table of short-hand feature names can also be defined, which allows one to e.g., define that a feature named "feat1" maps to "Portamento"). Otherwise if a frequency axis is present, then a Note On message is sent where the frequency value determines the node after rounding (e.g., 7.1 maps to note 7). Other axis types are not supported by this node at this time. Not all streams need to have the same axes -- e.g., a stream may have a frequency axis (thus sending note on messages) while another stream may have a feature axis (thus sending note off messages). The node has some limited support for alternative backends and drivers (which require the respective Python and OS packages to be installed in the Python/OS environment). For debugging it is useful to enable the log_messages parameter. Note that values are sent at 7-bit resolution unless the support_lsb option is enabled (this applies only to parameters that support 14 bits). More Info... Version 0.9.6
Ports/Properties¶
data¶
Data to send.
- verbose name: Data
- default value: None
- port type: DataPort
- value type: Packet (can be None)
- data direction: IN
port_name¶
The name of the MIDI output device, physical or virtual, to stream MIDI events to. If not provided, the first available device is used.
- verbose name: Midi Output Port
- default value: None
- port type: StringPort
- value type: str (can be None)
default_channel¶
Default MIDI channel. If there is neither a per-stream override nor a per-channel override, the node will send data to this MIDI channel.
- verbose name: Default Channel
- default value: 1
- port type: IntPort
- value type: int (can be None)
streams_to_channels¶
Associate stream names with channels. If provided, each input stream can be mapped onto a given MIDI channel. Wilcard characters are supported, and multiple streams can be mapped onto the same channel. For example, {'eeg*': 3, 'ecg',4} will remap data from any stream starting with 'eeg' to channel 3, and the ECG stream to channel 4. Note that MIDI channel numbering is 1-based (1-16).
- verbose name: Streams To Channels
- default value: {}
- port type: DictPort
- value type: dict (can be None)
names_to_channels¶
Associate input signal channel names (in a space axis) with MIDI channels. For example, {'mychan': 13'} will map data from each channel named 'mychan' (across any streams) to MIDI channel 13. Wilcard characters are supported (e.g., {'ch*': 16} would map all channels starting with ch to MIDI channel 16. Multiple data channels can be mapped onto the same MIDI channel.
- verbose name: Names To Channels
- default value: {}
- port type: DictPort
- value type: dict (can be None)
features_to_controls¶
Convenience substitution table from feature names to control code names. See MIDI 1.0 Spec, Control Change Message Types for the options and their official names. Note that you can also directly name your features to match certain control codes, e.g., "Volume". If your name is a substring of one of the control codes (e.g., "Volume" instead of "Channel Volume"), the first matching control code will be used. Lengthy substrings can also be abbreviated with wildchard characters, e.g., "General * 5" will match "General Purpose Controller 5"). This table is mostly useful to define short-hand feature names and/or as a way to swap the control mapping in once place.
- verbose name: Features To Controls
- default value: {'gp1': 'General Purpose Controller 1', 'gp2': 'General Purpose Controller 2', 'gp3': 'General Purpose Controller 3', 'gp4': 'General Purpose Controller 4', 'gp5': 'General Purpose Controller 5', 'gp6': 'General Purpose Controller 6', 'gp7': 'General Purpose Controller 7', 'gp8': 'General Purpose Controller 8', 'cc0': 'Bank Select', 'cc1': 'Modulation Wheel or Lever', 'cc2': 'Breath Controller', 'cc3': 'CC03', 'cc4': 'Foot Controller', 'cc5': 'Portamento Time', 'cc6': 'Data Entry', 'cc7': 'Channel Volume', 'sc1': 'Sound Controller 1', 'sc2': 'Sound Controller 2', 'sc3': 'Sound Controller 3', 'sc4': 'Sound Controller 4', 'sc5': 'Sound Controller 5', 'sc6': 'Sound Controller 6', 'sc7': 'Sound Controller 7', 'sc8': 'Sound Controller 8'}
- port type: DictPort
- value type: dict (can be None)
midi_backend¶
MIDI Backend to use. RtMidi is the recommended and more flexible backend, particularly on Windows. PortMidi requires PortMidi to be installed.
- verbose name: Midi Backend
- default value: RtMidi
- port type: EnumPort
- value type: str (can be None)
os_driver¶
OS-level driver to use. Currently, the JACK option is only available on Linux and MacOS, and only if rtmidi was installed with JACK support compiled in.
- verbose name: Os Driver
- default value: OS Native
- port type: EnumPort
- value type: str (can be None)
note_messages¶
How note messages should be emitted. This is only used if incoming data has a frequency axis that encodes the notes to play. In repeated mode, note_on messages are sent repeatedly for each active note, and in retained mode, a single note_on message is sent whenever the data value changes, and once no more data is incoming, a note_off message is sent. Note that empty packages are currently ignored by this node, so you will not receive note_off messages when you stop sending data into the MIDI ndoe altogether.
- verbose name: Note Messages
- default value: repeated
- port type: EnumPort
- value type: str (can be None)
autoreset_on_close¶
Auto-reset on close. This emits reset commands over the port before closing to restore a clean slate in the devices that receive data from NeuroPype.
- verbose name: Autoreset On Close
- default value: False
- port type: BoolPort
- value type: bool (can be None)
use_virtual_ports¶
If a port name is provided and does not match one of the existing available output ports, an attempt is made to create a virtual MIDI port (not supported on Windows).
- verbose name: Use Virtual Ports
- default value: True
- port type: BoolPort
- value type: bool (can be None)
support_lsb¶
Support sending LSB values. If enabled, then those parameters that support LSB values (14-bit resolution data) will have them sent.
- verbose name: Support Sending Lsb Values
- default value: False
- port type: BoolPort
- value type: bool (can be None)
log_messages¶
Enable debug logging of messages sent. Note that this will print the channels as 0-based, i.e., in the range 0-15 since this is a low-level printout.
- verbose name: Log Messages
- default value: False
- port type: BoolPort
- value type: bool (can be None)
ignore_signal_changes¶
Do not reset the state when a signal changed message is received from upstream nodes.
- verbose name: Ignore Signal Changes
- default value: True
- port type: BoolPort
- value type: bool (can be None)
set_breakpoint¶
Set a breakpoint on this node. If this is enabled, your debugger (if one is attached) will trigger a breakpoint.
- verbose name: Set Breakpoint (Debug Only)
- default value: False
- port type: BoolPort
- value type: bool (can be None)
metadata¶
User-definable meta-data associated with the node. Usually reserved for technical purposes.
- verbose name: Metadata
- default value: {}
- port type: DictPort
- value type: dict (can be None)