Config format description

WORK-IN-PROGRESS

This document is not finished yet

This document describes the format of the Electra One configuration file. The configuration file allow users to customize behaviour of the controler.

Config JSON format

JSON schema

The JSON schema of the Electra configuration file is available at GitHub.

Minification

We strongly advise minifying the JSON data prior to transfer to Electra One over the USB MIDI protocol. Minification greatly affects the amount of data that must be transferred, therefore it speeds up the time of uploading and downloading configuration files.

Top level objects

A preset has a number of top-level objects. These are either simple elements providing info about the preset itself or complex objects that define the structure and data of the preset.

{
   "version":2,
   "router":{
   },
   "presetBanks":[
   ],
   "pinnedSlots":[
   ],
   "usbHostAssignments":[
   ],
   "midiControl":{
   },
   "remote":{
   },
   "uiFeatures":{
   },
   "hardware":{
   },
   "satellite":{
   }
}

Every top level object is optional. The controller reads the file one section at a time, each into its own small document, and a section that is missing, malformed or too large is logged and left at its default. No section can fail a load.

version

The controller writes "version":2 at the head of every file it saves.

It never reads it back. There is no version check anywhere in the reader, so the number in a file the controller is given has no effect at all, whatever it says, and a file without it is read exactly like a file with it.

• optional
• numeric

router

An object that holds the MIDI router: the static routes that forward inbound MIDI messages, and the switch for preset router scripts. The Router chapter of the user guide explains how routing works.

• optional
• object

example:

"router":{
   "lua":{
      "presetRouters":true,
      "budget":20000
   },
   "routes":[
      {
         "srcInterface":"midiUsbHost",
         "srcPort":"port1",
         "destInterface":"midiIo",
         "destPort":"port1"
      },
      {
         "srcInterface":"midiUsbDev",
         "srcPort":"port2",
         "srcChannel":1,
         "destSystem":"remote"
      },
      {
         "srcInterface":"midiIo",
         "srcPort":"port2",
         "srcChannel":0,
         "destSystem":"midiControl"
      },
      {
         "srcSystem":"remote",
         "destInterface":"midiUsbDev",
         "destPort":"port2",
         "destChannel":1
      }
   ]
}

lua

Settings for preset router scripts.

attribute	description
presetRouters	boolean. When true, a preset's router.lua runs while the preset is active. When false or missing, router scripts are ignored.
budget	number, optional. How many Lua instructions a router script may run for one call into it - one message, one scheduled function, one parameter change. The script body and init() get ten times as much. It must be a whole, non-negative number; anything else, a fraction or a string among them, is ignored. Accepted from 1000 to 1000000; a value outside that range is ignored and the previous setting kept. Defaults to 20000. A router is given the budget when it starts, so a change reaches a running router only when its preset is loaded or re-entered.

routes

An array of routes. The router applies all of them; there is no order. Each route is one of three kinds, told apart by the attributes it has.

Interface to interface. Forwards every message that arrives on a source port to a destination port, unchanged, on all channels.

attribute	description
srcInterface	the interface the messages arrive on
srcPort	the port the messages arrive on
destInterface	the interface the messages are sent to
destPort	the port the messages are sent to

Interface to system. Tells one of the controller's services which messages to listen to. It does not forward anything. A message the service uses is not passed to the preset. One it has no use for - a control change or note no remote knob slot or remote map names, a message no MIDI Control mapping matches - is passed on to the preset as if the route were not there. Interface-to-interface routes from the same source forward both.

attribute	description
srcInterface	the interface the messages arrive on
srcPort	the port the messages arrive on
srcChannel	the MIDI channel, 1 to 16, or 0 for all channels. A service that listens to several channels of one port has one route per channel.
destSystem	remote for the Remote Knobs, midiControl for MIDI Control

System to interface. Where a service sends its own messages. Only remote is supported, for the outgoing Remote Knobs messages.

attribute	description
srcSystem	remote
destInterface	the interface the messages are sent to
destPort	the port the messages are sent to
destChannel	the MIDI channel, 1 to 16

Values of the interface and port attributes:

value	description
midiIo	the MIDI sockets
midiUsbDev	the USB Device port, as the computer sees it
midiUsbHost	the USB MIDI devices connected to the USB Host port
port1	Port 1
port2	Port 2
ctrl	the CTRL port

Messages addressed to the CTRL port with preset, snapshot and capture commands are handled by the controller without any route.

What the reader does with a value it cannot use:

• An interface name it does not know - and a missing one - drops the route. Besides the three above, the reader also accepts midiAll, which stands for every interface at once. The controller never writes it into a route, and as a source it matches nothing, because a message always arrives on one real interface.
• A port name it does not know, and a missing one, reads as port1.
• A srcChannel or destChannel above 16 reads as 0, which is every channel. A missing one is 0 as well.
• A destSystem or srcSystem it does not know drops the route. Only remote and midiControl are accepted inbound, and only remote outbound.

how many routes fit

The routes array is parsed whole, into a document of 4024 bytes on the controller. A route costs five slots of 24 bytes each, so about 32 routes fit and the thirty-third does not. A file mixing system routes in - they carry longer key names - reaches the ceiling one or two routes earlier.

Nothing partial is kept. When the array does not fit, the parse fails and the whole array is dropped - and because the controller then sees a file with no routes, it falls back to the legacy booleans below, which in a modern file are absent. The router is left with no routes at all. The other sections are unaffected, because each is read separately.

An empty "routes":[] is a routes array like any other. It clears every route and suppresses the legacy booleans, which is how a file says the router forwards nothing.

The mappings arrays of midiControl and remote are not parsed this way. They are streamed one entry at a time and have no such ceiling.

legacy format

Configurations written by older firmware describe the router with a set of booleans instead of routes. They are still read, and turned into the equivalent routes, but only when the file has no routes array. A file carrying both is read as if the booleans were not there. New configurations should use routes.

key	the routes it stands for
usbDevToUsbHost	USB Device to USB Host, port 1 to port 1 and port 2 to port 2
usbDevToMidiIo	USB Device to the MIDI sockets, both ports
usbHostToUsbDev	USB Host to USB Device, both ports
usbHostToMidiIo	USB Host to the MIDI sockets, both ports
midiIoToUsbDev	the MIDI sockets to USB Device, both ports
midiIoToUsbHost	the MIDI sockets to USB Host, both ports
midiIo1Thru	MIDI socket port 1 back to itself
midiIo2Thru	MIDI socket port 2 back to itself

Each is a boolean, and each pairs port 1 with port 1 and port 2 with port 2. They only ever add routes; there is no boolean that removes one.

Three more keys of the old format describe MIDI Control, and they are read together, again only when the file has no routes array:

key	what it means
usbDevToMidiControl	whether MIDI Control is on. Defaults to true, and a midiControl object read afterwards replaces it with its own enabled
midiControlPort	the port MIDI Control listens on: 0 is Port 1, 1 is Port 2, 2 is the CTRL port. Defaults to the CTRL port
midiControlChannel	the channel, 1 to 16, or 0 for every channel, which is the default

The old format has one rule whose source is every interface, so the three keys become three inbound system routes - one per interface, all naming that port and channel. That is what the modern routes array spells out, and the controller writes it in the modern form on the next save.

Older firmware read these three into a structure it then discarded, so MIDI Control came up switched on and receiving nothing - including on the factory configuration the Electra One app writes. A controller running firmware 5.0.0c or newer builds the routes.

presetBanks

An array of preset bank definitions. A preset bank is a named collection of preset slots. How many banks a model has, and how many slots are in a bank, differs by model:

model	banks	slots in a bank	slots
mk2	6	12	72
mini	5	8	40

The reader uses those numbers. An entry whose id is outside 1 to the model's bank count is skipped with a warning and the rest of the array is still read, so a configuration file taken from an mk2 loses its sixth bank on a mini rather than keeping one nothing can reach. The controller writes back only the banks it has.

The array as a whole replaces the default banks, and a bank the array does not mention keeps its default name and colour.

• optional
• array

example:

"presetBanks":[
   {
      "id":1,
      "name":"FX UNITS",
      "color":"FFFFFF"
   },
   {
      "id":2,
      "name":"SAMPLERS",
      "color":"529DEC"
   }
]

pinnedSlots

An array of the preset slots that are pinned and started when the controller boots. A pinned preset keeps running in the background after the user switches away from it, and this is the list that survives a restart.

The controller writes this list itself, from what is pinned at that moment, when SAVE STATE is pressed in the settings screen - or when a host asks for the same thing over SysEx with Save the application state. It is read on startup: every slot named here is loaded and pinned, and the preset that was last on screen is the one shown. A slot whose preset is replaced or removed is taken off the list, and the configuration file is written again without it.

Banks and slots are counted from one, as everywhere else in this file. An entry missing either number, or carrying a zero, is skipped with a warning and the rest of the list is still read.

Both numbers are checked against the model before anything else happens: a bank above the model's bank count, or a slot above the number of slots in a bank, is dropped with a warning naming the pair. What is left is turned into a single slot number - the bank, less one, times the number of slots in a bank, plus the slot, less one. A slot already in the list is not added twice.

This array is parsed whole, into a document of 2024 bytes, which holds about 27 entries. A longer list does not fit, and nothing is pinned at all.

• optional
• array

example:

"pinnedSlots":[
   {
      "bankNumber":1,
      "presetSlot":2
   },
   {
      "bankNumber":2,
      "presetSlot":11
   }
]

usbHostAssignments

An array of instructions on how to assign USB Host devices to Electra's ports.

• optional
• array

examples:

"usbHostAssignments":[
   {
      "pattern":"KEYSTEP",
      "port":"port1"
   },
   {
      "pattern":"LAUNCHPAD MINI MK3",
      "ports":[
         {
            "pattern":"DAW",
            "port":"port1"
         },
         {
            "pattern":"MIDI",
            "port":"port2"
         }
      ],
      "bankNumber":3,
      "presetSlot":1
   },
   {
      "pattern":"NANOKONTROL2",
      "ports":[
         {
            "cable":0,
            "port":"ctrl"
         }
      ]
   }
]

attribute	description
pattern	text contained in the USB device's product name, at most 20 characters. Matching ignores upper and lower case.
port	the port the whole device is assigned to: port1, port2 or ctrl. The numbers 1, 2 and 3 are also accepted.
ports	optional. For a device with several USB MIDI ports of its own: a list that assigns each of them separately, picked by the text in the port's name (pattern) or by its number counted from 0 (cable), to a port.
bankNumber, presetSlot	optional. When both are given, plugging the device in switches to the preset in that bank and slot.

The first rule whose pattern is found in the product name decides; later matches are ignored. A device no rule names goes to port 1, in both directions - it is not silenced.

An entry in ports names its cable either by pattern or by cable, never by both: when cable is present and is a number, pattern is not read at all. A cable that no entry names is left unused, and sends and receives nothing.

A port name the reader does not know, and a missing one, reads as port1. A number outside 1 to 3 reads as port1 as well.

This array is parsed whole, into a document of 1024 bytes - the smallest of the sections - which holds about a dozen simple assignments. Long patterns and ports lists cost more, and a list that does not fit is dropped entirely, so every device then falls back to port 1.

midiControl

An object that holds MIDI Control: assignments of MIDI messages to Electra's internal commands, such as page and preset switching.

The MIDI ports and channels that MIDI Control listens to are not part of this object. They are inbound system routes, held in the router object with destSystem set to midiControl.

• optional
• object

example:

"midiControl":{
   "enabled":true,
   "mappings":[
      {
         "command":"switchPage",
         "commandParameter":1,
         "midiMessage":"cc7",
         "parameterNumber":1
      },
      {
         "command":"switchPageNext",
         "midiMessage":"note",
         "parameterNumber":36
      },
      {
         "command":"switchPreset",
         "commandParameter":1,
         "midiMessage":"program",
         "parameterNumber":1
      },
      {
         "command":"switchPresetPrev",
         "midiMessage":"note",
         "parameterNumber":50
      }
   ]
}

attribute	description
enabled	boolean, optional. Turns MIDI Control on or off. Missing reads as false, so a midiControl object without it switches MIDI Control off.
mappings	an array of assignments

Attributes of an assignment:

attribute	description
command	the command to run, for example switchPage. The names are the ones listed under command in the preset format. A name the controller does not know is read as no command, and the assignment then does nothing.
commandParameter	optional. The command's parameter, for example the page number. Missing reads as 0.
midiMessage	cc7, note, noteOn, noteOff or program. note and noteOn are the same thing. Any other value never matches an incoming message.
parameterNumber	the controller, note or program number, 0 to 127. A value above 127 reads as 0.

Not every command name can be triggered this way. The ones that are acted on are the menus and popups, page, preset and control set switching, the performance page, pot sensitivity, ALT, requestPatch, the detail window, the default and randomise commands, handle switching and the custom layout commands. A name outside that set is stored and matched, and then nothing happens.

switchPreset takes a slot counted from 1 across all banks, not a bank and a slot. switchPage takes a page id counted from 1, and switchControlSet a control set from 1 to 3.

The assignments are kept in the order the controller reads them reversed: the last entry in the file is tested first. The first entry whose message type and parameter number match wins.

Older configurations store the assignments directly as an array, "midiControl":[ ... ], and name command and commandParameter event and eventParameter. Both forms are still read, and a file may even mix them - the command key wins over event when both are present on one assignment.

The mappings array is streamed one entry at a time rather than read whole, so there is no ceiling on how many assignments a file may carry.

remote

An object that holds the Remote Knobs configuration: the global enable switch and the dynamic mappings of MIDI CC numbers onto Electra's knob slots.

Note that the MIDI ports and channels the Remote Knobs listen to are not part of this object. They are inbound system routes and are held in the router object, with destSystem set to remote.

• optional
• object

example:

"remote":{
   "enabled":true,
   "takeover":"scale",
   "mappings":[
      {
         "source":16,
         "destination":1,
         "type":"value"
      },
      {
         "source":17,
         "destination":2,
         "type":"change",
         "encoding":"signedBit"
      }
   ]
}

enabled

Turns the whole Remote Knobs feature on or off. Mappings are preserved while the feature is disabled.

Missing reads as false, so a remote object without it switches the feature off.

• optional
• boolean, defaults to false

syncOnLoad

Whether to send every absolute Remote Knobs assignment outbound when a preset or a snapshot is loaded.

A load moves the parameters without touching the hardware that drives them, so a motorised surface is wrong until each fader happens to be moved again—and a value a snapshot left alone never moves at all. This walks the assignments instead of waiting.

Off by default: it is a burst of MIDI on every load, and a controller with no motors or lights has nothing to gain from it.

This is the default for every preset. A remote map may say otherwise for the one preset it belongs to—see the remote map format.

• optional
• boolean, defaults to false

syncOnPageChange

Whether to send every mapped Dynamic knob slot outbound when the user turns to another page.

A knob slot names a position on the page rather than a control, so turning a page hands all of them to different parameters at once—and none of those parameters has moved, so nothing reports them. This is the slots' counterpart to syncOnLoad, and it is off for the same reason.

It concerns the knob slots only. A preset carrying a remote map of its own switches the slots off, and a static assignment reaches its control whichever page is on screen, so there is nothing for a page turn to correct.

• optional
• boolean, defaults to false

takeover

How an absolute Dynamic mapping behaves when the physical control and the parameter disagree. Relative and note mappings ignore it.

It does not reach a remote map. A Static assignment carries its own takeover, because one surface routinely wants more than one behaviour — see the remote map format.

An unknown or missing value is read as jump, which is how the controller behaved before takeover existed.

• optional
• enum, defaults to jump
  • jump — the parameter follows the incoming value immediately
  • pickup — incoming values are ignored until the control passes through the parameter's value
  • scale — the parameter moves proportionally, converging as the control reaches an end of its travel
  • nudge — the parameter is moved by the amount the control moved

mappings

The dynamic mappings. Each entry binds one MIDI CC number to one knob slot.

The array is streamed one entry at a time rather than read whole, so there is no ceiling on how many entries a file may carry. Each end of a mapping binds to one thing: mapping a slot that is already mapped, or a CC that is already mapped, releases the earlier binding.

The whole table is cleared whenever a remote object is found, even one carrying no mappings at all.

• optional
• array

remoteMapping

example:

{
   "source":16,
   "destination":1,
   "type":"value"
}

source

The MIDI CC number the mapping listens to.

• mandatory
• numeric
• min = 0
• max = 127

destination

The knob slot the CC message drives, counted from 1. A slot is a position within a control set, not a control: the control set, times the number of knobs, plus the pot id, plus one.

model	slots	made of
mk2	1..36	three control sets of twelve knobs
mini	1..12	one control set: eight knobs and four buttons

The reader does not know the model. It accepts any slot from 1 to 127 and rejects 0; a slot past the model's own count is stored and never reaches anything.

• mandatory
• numeric
• min = 1
• max = 127

type

How the CC value is read. A missing or unrecognised type drops the mapping.

• mandatory
• enum
  • value — the value 0 to 127 is an absolute position
  • change — the value is a relative increment

encoding

PROPOSED — NOT YET IMPLEMENTED

For change mappings, the relative encoding the sending device uses. Ignored for value mappings.

• optional
• enum, defaults to twosComplement
  • twosComplement — increments 1 to 63, decrements 127 down to 65
  • signedBit — increments 1 to 63, decrements 65 to 127
  • signedBit2 — increments 65 to 127, decrements 1 to 63

uiFeatures

The UI features object is used to configure / customize the user interface of the controller.

example:

{
   "version":2,
   "uiFeatures":{
      "touchSwitchControlSets":true,
      "usePotTouchSelections":true,
      "activeControlSetMode":"global",
      "controlDoubleClickAction":"resetToDefault",
      "controlLongTouchAction":"openDetail",
      "keepPresetState":true,
      "loadPresetStateOnStartup":false,
      "dimInactiveControlSets":false
   }
}

The writer emits all eight keys on every save. The reader reads each one on its own, so a file may carry any subset of them.

touchSwitchControlSets

When set to true, touch on controls changes the active control set (section of active controls). When set to false, only hardware buttons switch the active control set.

• optional
• boolean, defaults to true

usePotTouchSelections

When set to true, touching a knob opens the selection windows - pages, presets - on the item the knob stands for.

• optional
• boolean, defaults to true

activeControlSetMode

Which control set is active after turning to a page.

• optional
• enum, defaults to global
  • global — the one the controller is already on, whichever page it was set on
  • local — the one that page was left on
  • custom — the one the page names as its default

An unrecognised value reads as global.

An older configuration says the same thing with resetActiveControlSet, a boolean: true is custom, false is global. It is read only when activeControlSetMode is absent.

controlDoubleClickAction

What a double tap on a control does.

• optional
• enum, defaults to resetToDefault
  • none
  • resetToDefault
  • openDetail

An unrecognised value reads as none, not as the default.

controlLongTouchAction

What a long touch on a control does. The same three values.

• optional
• enum, defaults to openDetail

An unrecognised value reads as none.

keepPresetState

Whether a preset's values survive its slot being read again. A preset that is merely switched away from stays in memory with its parameter map, so an ordinary switch never loses anything and never writes to the card. What loses the values is the slot being read from the file again: a reload, a preset uploaded into the slot, a background load, or entering a slot whose preset had been reset.

When it is on, the parameter map is written to ctrlv2/maps/[projectId].map at that moment, and the load that follows reads it back. When it is off, the preset comes up with the values its file defines.

The note of what was put aside carries the project id, not the slot, so a different preset loaded into the same slot is never handed those values. A preset that declares no projectId keeps nothing, since every one of them would share the same file.

The reader has no default for this one: a uiFeatures object that leaves it out switches it off.

• optional
• boolean, off when absent

loadPresetStateOnStartup

The other half of keepPresetState, and about surviving a power cycle rather than a reload. When it is on, the parameter maps in use are written out as the controller goes to sleep, and a preset recalls its map on every load - which after a restart is the first one. When it is off, and keepPresetState is off too, a loaded preset starts with its map forgotten.

The two are independent. With this one on and keepPresetState off, the controller starts up where it left off while a reload during the session still brings the preset up as its file defines it.

Read the same way as keepPresetState: a uiFeatures object that leaves it out switches it off.

• optional
• boolean, off when absent

dimInactiveControlSets

How the controller marks the active control set.

When set to true, the controls of the other control sets are dimmed. When set to false, an Electra One mk2 draws a bar down each side of the screen beside the active control set; the other models draw no indicator at all.

• optional
• boolean, defaults to false

activeControlSetType is gone

Firmware 4 replaced the activeControlSetType enum - none, dim, bars, background - with the boolean above. Two of its four values were the two indicators the controller has; the other two were never drawn. A configuration still carrying the old field is accepted and the field is ignored.

hardware

What the controller's own buttons do. The writer emits this object on every save.

example:

"hardware":{
   "useDefaultLayout":true,
   "usePotTouchShortcuts":true,
   "buttons":{
      "leftTop":{
         "primary":"openPresetsMenu",
         "alt":"openMenu"
      },
      "rightBottom":{
         "primary":"switchPageNext"
      }
   }
}

attribute	type	default	description
useDefaultLayout	boolean	true	Use the controller's built-in button layout.
usePotTouchShortcuts	boolean	true	While a knob is being touched, the buttons run the built-in touch shortcuts instead. mk2 only, and only while useDefaultLayout is on.
buttons	object	none	The assignments, keyed by button name.

Both booleans are read with those defaults, and the same defaults are used when hardware is present but is not an object. When the whole section is missing the two are true and no button is assigned.

On the Electra One mk2, useDefaultLayout wins: while it is on, the built-in layout is used and the assignments in buttons are not reached at all - only a preset's own button overrides come before it. On the mini, the default layout applies only while nothing at all is assigned; a single assignment anywhere makes the whole row the user's own, so the defaults never fill the gaps of a partly configured row.

button names

They differ by model, and a name the model does not know is skipped with a warning.

model	names
mk2	leftTop, leftMiddle, leftBottom, rightTop, rightMiddle, rightBottom
mini	context1, context2, context3, context4

what a button carries

Each button is an object. Every key is optional, and the value is a command name from the list under command in the preset format. A name the controller does not know is read as no command.

key	when it is used
primary	an ordinary press
alt	a press while ALT is held
knobTouch	a press while a knob is being touched, on the mini's context buttons

The writer leaves out any of the four that is unassigned, leaves out a button with no assignments at all, and leaves out buttons the model has no name for - the mini's knob switches among them.

satellite

What a satellite's context buttons do. A satellite has a row of buttons under its screen like the controller's, and what each one does is the owner's choice, so it is kept here rather than on the satellite.

The writer emits the object on every save, but it writes buttons into it only when at least one button is assigned - an empty buttons would say a satellite had been configured to do nothing, which is not the same as not having been configured. A saved file with nothing assigned therefore carries "satellite":{}.

example:

"satellite":{
   "buttons":{
      "1":{
         "primary":"openPresetsMenu"
      },
      "3":{
         "primary":"switchPageNext"
      }
   }
}

attribute	type	default	description
buttons	object	none	The assignments, keyed by button position.

A satellite has four context buttons, and the keys are their positions written as strings, "1" to "4". A key outside that range, one that is not a number, and an entry with no primary, are all skipped and the rest of the object is still read. Only primary is read; there is no alt or knobTouch here.

The value is a command name, read the same way as in hardware. A name the controller does not know is read as no command, which is the same as leaving the button out.

A position this object does not assign falls back to what the same position does on the controller itself - its hardware primary - so an unconfigured satellite behaves like the instrument beside it rather than doing nothing.

The satellite is never told what any of this means. It is sent labels and it reports which button was pressed; the controller resolves that against this object and runs the command.

presetBank

A preset bank is a named collection of preset slots - twelve on an mk2, eight on a mini. Each bank has a name and a colour.

example:

{
   "id":1,
   "name":"FX UNITS",
   "color":"FFFFFF"
}

id

A unique identifier of the preset bank. The reader accepts 1 to 6 on every model, although a mini only has five banks. An entry outside that range is skipped.

• mandatory
• numeric
• min = 1
• max = 6

name

A user-defined name of the bank. The name makes it easier for users to remember and identify the banks. A longer name is cut to twenty characters, and a missing one reads as an empty name.

• mandatory
• string
• minLength = 1
• maxLength = 20

color

A 24-bit RGB code of the bank's colour, six hexadecimal digits with no leading #. The colours are limited to the six below.

The string is read with a plain hexadecimal conversion, so anything that is not a hex number - a leading # among them - reads as 0, black. A missing color reads as black as well, not as white.

Only the six are stored faithfully. Any other colour is accepted, and is written back on the next save as FFFFFF.

• optional
• string
• black when absent
• enum
  • FFFFFF (white)
  • F45C51 (red)
  • F49500 (orange)
  • 529DEC (blue)
  • 03A598 (green)
  • C44795 (pink)

usbHostAssignment

USB Host assignments allow automating the assignment of MIDI devices connected to the USB host interface to Electra's internal ports. A string pattern is used to match the product name of USB devices.

example:

{
   "pattern":"launchpad",
   "port":3
}

pattern

A string to be matched with USB Device product name. If the pattern is found within the product name, the device is assigned to the specified port. The matching algorithm is case-insensitive. The first match results in the port assignment, subsequent matches are ignored. A longer pattern is cut to twenty characters.

• mandatory
• string
• minLength = 1
• maxLength = 20

port

An identifier of Electra's internal port. The port may be written as a name - port1, port2, ctrl - or as a number, where Port CTRL is 3. A number outside 1 to 3, and a name the controller does not know, read as Port 1.

• string or numeric
• min = 1
• max = 3

midiControl

A rule that tells what internal command will be run after receipt of the given MIDI message. The MIDI message is defined by the MIDI message type and the parameter number.

This is the older spelling of an entry of midiControl.mappings, and it is still read. event and eventParameter are what command and commandParameter are called here. When an entry carries both spellings, command wins.

example:

{
   "event":"switchPreset",
   "eventParameter":1,
   "midiMessage":"program",
   "parameterNumber":1
}

event

A command to be run. Any of the names listed under command in the preset format is accepted, though only some of them are acted on - see midiControl above. A name the controller does not know is read as no command.

• mandatory
• string

eventParameter

An optional parameter of the command, eg. the page number.

• optional
• numeric
• min = 0
• max = 127

midiMessage

A MIDI message type that will trigger the command. note and noteOn are the same thing.

• mandatory
• string
• enum
  • note
  • noteOn
  • noteOff
  • cc7
  • program

parameterNumber

A parameter of MIDI message that will trigger the command. A value above 127 reads as 0.

• mandatory
• numeric
• min = 0
• max = 127