devel-ipc

• IPC
  • IPC configuration
  • OSC
  • MIDI

IPC

FLAM is, first and foremost, orientated towards off-process GUI management. This means some IPC must exist.

First IPC protocols supported will be OSC and MIDI (via alsa-seq and, later on, jackmidi.) Other control-rate protocols that might be incorporated in the future:

• dbus.
• jackd (there is some talk in LAD about extending jack with control-rate signalling.)

IPC configuration

IPC operation will be configured via Q_PROPERTY properties editable in Qt Designer.

OSC

Properties:

• oscAddress: including the starting slash.
• oscTypeTag: OSC types supported are 's', 'i', 'f' and 'm'.
• oscArguments: arguments expression.

oscArguments is a expression that follows a pattern syntax. There is one pattern for every argument in the OSC message. Patterns are separated by commas and may be one of the following:

• A state pattern: it takes the form of the character '$' followed by an integer. When the widget receives an OSC message its state will change according to the argument(s) in the message that correspond(s) with the state pattern(s) configured here. Conversely, when the user actuates the widget it will emit an OSC message with its state encoded in the corresponding argument(s) of the expression.
• A mirror pattern: it takes the form of the character '*'. When the widget receives an OSC message it will store internally those arguments marked with a mirror pattern. When the widget emits an OSC message it will use the stored value as the argument for this part of the expression.

NOTE: a OSC exchange protocol that needs the use of mirror patterns should imply some kind of initialization from a master device, which a FLAM application should never be. But what happens anyway when the user changes a widget and the state of its mirror patterns has not been initialized by a previously received OSC message? I see some alternatives:

1. Disable OSC output until an incoming message has initialized the mirror patterns. Disadvantage: might be confusing for the user if the control is unresponsive for no apparent reason.

2. Emit whatever passes for NULL given the type of the argument: zero, empty string, 0xFFFFFFFF for MIDI (reference)...

3. Allow the designer to specify a default literal value for mirror patterns: ...,25,...,"Hello, world",...

• A literal value: the literal value will be used verbatim in the OSC message emitted by the widget. It can be one of the following:
  • 's': a string literal. It must be enclosed in double quotes, and the comma and double quote characters must be escaped with a backslash.
  • 'f' or 'i': a numeric literal.
  • 'm': 4 2-digit hexadecimal representation, case insensitive, separated by colons, where one of the bytes may be substituted by a variable expression.

Examples for DSSI:

DSSI message
oscAddress
oscTypeTag
oscArguments

Control
/control
if
3,$0

Bank
/program
ii
$0,*

Program
/program
ii
*,$0

Configure
/configure
ss
"polyphony",$0

Midi
/midi
m
00:90:3C:$0 1

1 Port id = 0, note on channel 0 (indicates MIDI channel 1), pitch C4, velocity dependent on the state of the control, in this case a push button with max and min values of 64 and 0 could be appropriate.

MIDI

Properties:

• midiMessageType: an enumeration, containing values like:
  • Note (9n): midiMessageSubtype will indicate the note's MIDI key. Continuous widgets like dials or sliders use key velocity (non-zero, since zero may be used as note-off); toggle buttons change state every non-zero velocity message; push buttons are pressed or released with the key.
  • Poly pressure (An): midiMessageSubtype will be ignored.
  • Control Change (Bn): midiMessageSubtype will indicate the Control Change number associated to the widget. This message type will only deal with 7-bit values (i.e., CC 0 will only transmit and listen to Bank Select MSB messages.) To use the full 14-bit range we should use BankSelect? from the 14-bit controller list.
  • Program Change (Cn): midiMessageSubtype will be ignored.
  • Aftertouch (Dn): midiMessageSubtype will be ignored.
  • Pitch Bend (En): midiMessageSubtype will be ignored.
  • Well-known 14-bit Control Change messages: midiMessageSubtype will be ignored. These include: bank select, modulation, breath, foot, portamento, balance, pan, expression, FX1, FX2, General Purpose 1-4.
  • RPN, NRPN: midiMessageSubtype will indicate the parameter number associated to the widget. Both Data Entry bytes will be used. No running status or incremental changes are supported.
• midiMessageSubtype: for certain values of midiMessageType selects one of the subtypes they offer (MIDI key, CC number, parameter number.)

Every MIDI message type that supports 14-bit values is used to its full precision, both in transmission and reception.

The full range of the widget will be linearly translated to the full range the MIDI message type allows. For 7-bit ranges, a 0 MIDI value will be translated to the widget's minimum value, and a 127 MIDI value to its maximum.