Changes to TAB made by PlugIn not saved

• Jan 27, 2021 - 23:59
Reported version
3.6
Type
Plugins
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

Changes to TAB made by PlugIn not saved

The below seems like a Musescore bug; tho I'm hoping it's caused by something I may be ommiting in my plugin code.

I wrote a plugin that walks through a non-linked TAB staff and makes changes to the fret numbers (this has to do with Mountain Dulcimer TAB conventions). It appears to work just fine, it makes the changes exactly as I coded it to do. After it runs all looks fine and appears to work fine. Before saving, I can make new parts, format the staff my plugin changed, add/remove instruments. I can export MP3, MIDI, and PDF files and all the changes my plugin made all work fine for all those actions.

BUT - then I save my updated score; and upon reopening it the TAB staff my plugin modified is pretty messed up. No reported file corruption and no apparent technical corruption - but what happens is that most of the staff has reverted back to the fret numbers prior to running the plugin; yet not all of them do that. There is some degree of randomness involved. And a few fret numbers show up as out of range (tho in my attached example there are no out of range notes, the example provided here is shorter and simpler than the bigger score that did create out of range notes). Also note that I can save the score as many times as I like without any apparent problems as long as I keep the score open. It is only when I close and reopen after saving that the problem appears.

Here's what I've tried to see if there is a workaround that might inform what's going on - all of the below have no effect:

1. Removed the bracketing curScore.startCmd(); / curScore.endCmd(); statements in my plugin's code.

2. Before saving, in my revised TAB staff, did a select all, copy; then on a new TAB staff did a Paste. That also looked just fine. After save / reopen both of those TAB staffs have the exact same messed up appearance. (So this result does suggest a systemic fault as opposed to random changes.)

3. After running my plugin, created a completely new score, with a new TAB staff, and pasted the contents from my plugin modified staff to that. Saved that file. Upon reopening that score - exact same messed up fret numbering. (Again - points to some sort of mismatch between the underlying data structures of the revised TAB notes/frets vs what is displayed prior to saving the score ??)

Attached is:

A. My plugin MtnDulcimer-TransCromoTABtoDiatonic.qml.

B. A screen shot of the score, after running plugin, as it appears on my screen before I save it SS_PostPlugin_Presave.png . This shows that all is well just after running the plugin.

C. A screen shot of the score, after after saving it, then reopening it SS_PostPlugin_ReopenPostSave.png .

D. The score that I ran my plugin on Step-1_Original-Score.mscz.


Comments

Observation 1: What MuseScore shows upon opening the file from step D matches what is stored into the file; For m5 the stored fret/string is that 0,5,5 in the file itself.

Observation 2: after running your plugin, the fret number changed, but the status bar keeps showing the old notename for those notes.
If you then add a linked standard staff to that tablature staff, you'll also see the original (non-modified) pitches are being displayed. Funny enough the playback sound is lower.

So this indeed supports the theory that not all the necessary information is updated correctly.

In reply to by jeetee

Right. As another possible data point: I have created another plugin, taking a different approach as a workaround. Inside this other plugin I read notes from the standard staff and then write tab notes to match. Then after writing the tab note I attempt to retrieve the string and fret number (inside my plugin) that musescore internally assigned to the TAB note, only to discover that what I get back is undefined. I don't know if it's related to this issue, but my instincts say there's some connection there regarding the timing of when the note's metadata is updated.

Status active closed
Fix version 3.6.0

First off, I started by assigning string and fret before pitch to match other (known to be working) plugins. This did not solve your problem.

The problem became obvious once I added that linked staff and then after running the plugin tried moving notes up/down on the staff using arrow up/down which made the note jump around seemingly randomly. The reason is that you update the pitch of the note itself, but not the "pitch spelling" of the note. (The latter is also used to show the note name in the status bar)
Have a look at https://musescore.github.io/MuseScore_PluginAPI_Docs/plugins/html/tpc.h… to learn about TPC's.

I've added updating the tpc of the note and slightly reworked the lookup array you were using. As far as I can tell, the changes work on your example score and now do survive save/reload.

Attachment Size
MtnDulcimer-TransCromoTABtoDiatonic.qml 9.79 KB

In reply to by jeetee

You're awesome jeetee! I won't be able to study this until the morning, but am excited to have this working!

Now let me ask this: to my mind this is the sort of thing that should be clearly documented. Is there a defined place to document something like this other than people having to find it in these forum & issue posts?

For me, while the auto generated plug-in API documentation from the c++ code base is a critical resource, it really isn't sufficient for plug-in developers. Other than searching these forum issue topics I haven't seen any wiki, or other places, where the documentation can be annotated for these subtleties, or to provide coding examples, which would be extremely helpful.

The main problem with getting the plugin framework properly documented is finding someone that has the knowledge, time and will available to do so. So yes, unfortunately at this point in time your best bet is checking out other plugins and post questions in the plugin forum where we can all try to work out stuff together.

There is some (or at least used to be) documentation in the developers handbook; which in itself is a wiki-style thing that can be edited/appended by any registered user (such as yourself ;-) ).

Fix version
3.6.0