I have a suggestion that could help with the following issues:

#9
#6
#3

How about a "device profile" type of abstraction that allows to configure one or more device profiles. A device profile would include:

• Name
• Device
• Port
• (arbitrarily) 8 CC mappings

Devices would be stored as an array in the JSON file and deserialised into a list such that a node could reference a device profile index (and mapped CC index). A change in the underlying hardware configuration would only require updating the device profiles.

This improves the UX in the following ways:

• Users can associate a friendly name for a set of properties relating to a device. For instance, if I have two synths on the same MIDI device using different ports I can refer to the synths by name, rather than having to remember the device and port associated with it.
• Selecting the the properties I need to send messages from a node to a specific MIDI device becomes as easy as selecting the device profile.
• A reconfiguration of the underlying hardware, e.g. different computer, rearranging studio, etc. only requires updating the device profiles and not every individual node that uses it.
• Remembering the last used device becomes less of a concern as there are fewer permutations to setup per node.

I'm not sure where the device profiles would best be stored. It seems like it would make sense to be a separate configuration to the node storage, as its more related to the underlying system than an individual canvas. Signls could look for a default filename of profiles.json, but allow specifying the filename. If no filename is given and the default does not exist, Signls could create it and populate it with some sensible defaults.