Read text via plugin

• Feb 11, 2018 - 18:07

Dear musescore coders,

I'm currently trying to read text via plugin while encountering some problems. Maybe you can enlighten me.

Reading system text, stave text, rehearsal mark, figured bass and Tempo Marking works just fine by using cursor.segment.annotations[x].text.

Unfortunately, chord symbols won't work that way. Can't read them in a fresh opened musescore environment. After "editing" (doubleclickking is enough to enter edit mode) the der chord symbol reading its text works fine.
Lyrics won't read anyway.
Both texts are in the cursor.segment.annotations array but returning the false text = "".

Reading fingering won't work as well. It's not in the cursor.segment.annotations array .

I'm running musescore 2.1.0 revision 871c8ce.

Please explain possible reasoning errors or mark the question as known problem if work is already done on this topic.

Kind regards,
music_maker


Comments

Chord Symbols aren't text elements, but Harmony elements; hence them not having a text property. They are hardly exposed to the plugin framework having only 3 properties (baseTpc/rootTpc/id) of which the value of 'id' is an immediate mystery to me.

Fingering elements are not exposed.

Lyrics can be read (not written to) using the lyrics[] property from a Chord element; see for example https://github.com/jeetee/MuseScore_UltraStar_Exporter/blob/master/Ultr… which is a plugin that exports lyrics in the UltraStar format.

In reply to by jeetee

"id" is a holdover from the Bad Old Days (pre-2.0) when each and every chord symbol needed to be pre-programmed into MuseScore in order to be recognized. We had a fixed list of a couple hundred chord symbols, each with its own ID, and what you typed was matched against this list using a literal string compare. Nowadays, a parser is able to handle arbitrary combinations of tokens and turn them into a usable (to MuseScore) internal representation. We still assign them ID's internally but they are of little interest any more. Unfortunately, we don't currently expose this internal representation to the plugin framework. It would theoretically be possible and maybe not a bad idea some day. Also, as noted, until you've edited a chord symbol, there is no text representation of it, because chord symbols don't work that way. Again, in theory, a plugin function could be written to force text to be generated for all chord symbols.

Do you still have an unanswered question? Please log in first to post your question.