MIDI Data Panel: a possible implementation

I've often wished there was a way to know various MIDI values at any given point in a playable score, and i've come up with a possible solution to a future feature — the MIDI Data Panel (or "Data Panel" for short).

As MuseScore begins to incorporate features that make it not just a music notation application, but a more comprehensive score playing application as well, it becomes necessary for users to know what state various parameters are in. For example, what is the current tempo at this measure or note? How can i tell the note velocity of one or more notes (which is not viewable in a standard score)?

So i've come up with a possible solution to viewing and editing that elusive invisible data — the Data Panel! Keep in mind, i'm not a programmer, i'm just putting out there.

Here's a mockup of what the Panel would look like:

The first issue about the Data Panel is how to view the MIDI data in a concise and efficient way. Borrowing from sequencing software (like Master Tracks Pro-4), the best implementation of this is to make it available only when the user is viewing the score in Continuous View mode. This makes for a single, time-based graph that runs along a single staff or system, following (and being updated with) the scroll of the view.

The second issue concerns what data can be viewed. Here is the list i've come up with for now, but i can foresee future enhancements to this list.

1. Tempo: The graph displays the tempo with a shaded chart. The tempo values will be in the range of MuseScore's minimum and maximum. The above image shows how it might look.

2. Channel Volume: In the same way, the graph will show the volume of the currently visible measures, but without the shaded values. Since different staves may have different volumes, we can apply different colors to the values dependent on the staff the color represents, as shown here:
   

3. Note Velocity: Perhaps the most elusive data that users need is the Key Velocity of any given note. The graph indicates the force of the Key Velocity by charting this value at each Note-On. Notice how the strength of the velocity is represented by a downward line. The harder the note is struck, the farther down the line goes. Again, we use different colors for notes of different staves.
   

4. MIDI Event: The graph can also show which and when MIDI Events happen. A box at each time point shows what event was passed, and its value is charted in a single colored dot. Most of these are not linked with a score marking, but hopefully in the future, MuseScore will develop its way of indicating (on the score itself) what happens in the MIDI world.
   

The third issue is how editing of data values is done. The whole idea here is to make editing this data efficient and intuitive.

I toyed with the idea of being able to edit only the selected notes. But this is not very intuitive and it makes for unnecessary clicks. Instead the graph should be instantly editable. In most cases, the user can just click on a spot to add the data at that location in the score, click-and-drag to insert a series of values, or grab the endpoint of an existing data line to modify the value.

Let's go thru each data type to see how editing would be done.

1. Tempo: The user click at any location within the graph. An invisible tempo marking is placed in the score at the given x value, using the y value as the tempo [this technology already exists]. Click-and-drag to enter many tempo changes at once. This makes it easy to precisely customize how the user wants to change the tempo. Since Tempo is a universal setting, nothing needs to be selected. [However, as of version 3.0, tempo changes can only entered at Note-On events.]

2. Volume: Same as Tempo, but we may need to introduce a MuseScore-specific, non-printable score mark to indicate the entire staff's volume is changed. Staff volume changes would be reflected in the Mixer by updating the Volume slider/dial upon playback. Changing the channel volume for only one staff would require any element in that staff to be selected.

3. Velocity: Same as Tempo, except that Velocities are only modified at Note-Ons. To change the velocities of only one note in a note-chord, that note would need to be selected. Otherwise, without any selected notes, the same velocity is installed in all notes where the Velocity lines were clicked (or dragged over).

4. Events: Introducing or modifying MIDI events would require a single click (or clicking-and-dragging). A dropdown menu would appear allowing the user to choose the event they want at that point in the playback. If there is a linked score marking to that type of MIDI Event, that would be inserted into the score at the corresponding location.

NOTES

1. Showing values for multiple notes at once: Even if you have only one staff, the staff can have dozens of notes that start all at once. So, for things like Key Velocity, how do you depict the lines/values of each note in a chord? To get around this problem, i think the graph should show the average Key Velocity for a note-chord in one staff (with all voices combined). If the user needs the specific velocities for individual notes, he can select only those notes, and the graph will update to show the values of the selected notes.

2. Volume vs. velocity: In most scenarios, the volume depicted on a staff is assumed by the strength the instrument on that staff is played. But there are times when the instrument is played at one level, but the playback or mixdown should be at a different volume. This is especially true of orchestral scores. Playing French Horns, for example, at maximum level is not the same as the violin section playing at its loudest. Therefore, the difference between staff volume and instrument velocity should be addressed
   With MIDI Instruments, playing at maximum Key Velocity will sometimes activate a different sample, especially in soundfonts. But if you need this to be lowered in volume, how is it notated? I think the best way when dealing with the Data Panel is that dynamics marking can be introduced for only that staff when we're talking about Key Velocity (how hard to play the instrument), but dynamics markings for overall volume of that staff would be assigned to the Part.

3. The panel is supposed to be an adjunct to the Continuous View page, so that as you scroll, whether by swiping the page with the mouse or scrolling with the scrollbar handles, the Data Panel stays perfectly linked with the staff, measure by measure. I’m hoping the same behavior will exist even during playback. This means that the Data Panel isn’t resizable horizontally (it adheres to the size of the window), but it could be resizable vertically to show the data more or less compressed.