Backend Suggestion

[Blane245]

This may be more than you want to do but can make the application more multiuser and the scale information maintainable separate from the frontend application.
The suggestion is to split the application into a front end and a back end. The front end would look very much like it does today. The backend would provide a database to store the scales and comments.
This structure would allow you to maintain the scales without changing a JSON file that is part of the client application. It would alos allow each user to maintain their own comments about the scales

Here's the backend (server) description:
There is a database with three tables for starters.

• A table called Scales. The rows are the contents of the Wikipedia scales and modes table
• A table that define users. Could be as lax or as tight security as you wish. At least a user id would be needed
• A table of scale comments for each user.
  A set of websocket tranactions between the client (front end) and the server (backend). These transaction would be constructed to meet client use case needs. For example, a client request to list all scale comments for the user, a client request to add a new scale comment, a client request to delete a scale comment, a client request to modify a scale comment

The frontend (client) description:

• A window to login. When successful, the recorder-notes window is displayed
• On Recorder notes startup, it requests all of the scales/modes from the server, populates the pulldown, and displays the window with all of the goodies
• Most of the actions on the client are as they are today. When the user selects a scale, the client requests the comment for that scale from the server. You would add add/delete/modify capability to the comment field. When the user does one of these, the client sends the change to the server.