Expose tie information read-only to QML plugins
QML plugins need to know when notes are merely members of a chain of tied notes, i.e., that adjacent notes are tied. This is an essential part of the musical content of a score, and any plugin attempting to process a score, either for musical analysis or conversion to some other format, needs to know this. What's more, MuseScore is somewhat picky about what articulation parameters (on-time, len) for such notes mean, and where articulation parameters for chains of tied notes should be placed. The ability of plugins (especially new ones concerning articulation parameters already proving useful) to read note tie relationships is essential to the progress of these capabilities.
Access to the firstTiedNote/lastTiedNote and tieback/tieforward objects and their start/end notes is sorely needed at this juncture (and has been prototyped in private builds).
Comments
Now posted as:
https://github.com/musescore/MuseScore/pull/5258
-Dale
I've attached some of our test scripts to this post.
Link to preliminary discussions related to this feature:
https://musescore.org/en/node/292900#comment-937888
-Dale
Another test script that adds some focus on parentage.
-Dale
Here's a later version of tie-tests-hashing which exploits the ability to store user properties in objects subsequent to identity canonicalization.
A new version of the test script is attached having
elementId's replaces (for laughs) withobject.valueOf()'s.-Dale
In reply to A new version of the test… by DLLarson
Does it return the same value, and, if so, how does it address any of dmitrio's objections?
I would save just give it a try if you want to see the details. I don't think it helps our problem at all. Its only saving grace is that it is a Javascript standard function. Since it contains the address of the object I think it has the same problems as
elementIdin that its representation is totally ephemeral and not persistable (which we already knew.)If every object provided the equivalent of a GUID or UUID we'd be in great shape!
-Dale
The wrapper must know where the real object is, whether it lets Javascript know or not. Something in the wrapper has to persist. What happens if a "real object" is deleted? The fact that there might be half-a-dozen wrappers representing it remains a problem whether or not the address is shared with Javascript. Do the wrappers include QPointers that evoke callbacks when the pointed-to object is deleted? Isn't that enough to invalidate whatever wrappers point to it? If there are, in fact, multiple wrappers representing a single real object, each with QPointers to it, doesn't the real object have to track all of them?
Fixed in branch master, commit b60fea52cf
_Fix #293008: Plugin: Provide Note.tieBack & Note.tieForward properties in QML.
Provide Note.tieBack & Note.tieForward properties and their
associated Tie objects in QML. Also provides Note.firstTiedNote
and lastTiedNote methods to locate a tie range._
Fixed in branch master, commit 2c82d0db4a
_Merge pull request #5258 from DLLarson/plugin-expose-note-ties
Fix #293008: Plugin: Provide Note.tieBack & Note.tieForward properties in QML._
Automatically closed -- issue fixed for 2 weeks with no activity.