Expose Element.posX & Element.posY values to plugins

The Pull Request is posted:

https://github.com/musescore/MuseScore/pull/5254

I've attach a testing version of the tin-whistle-tab plugin that uses the element.posX values to position finger hole pattern images. This script will fall back to a heuristic approach when the pos member is not available to the plugin.

-Dale

Hello,

I've now updated the shipping notename.qml plugin to utilize the Element.posX/Y exposure.

Here is a bit of score listing note names for grace notes using the existing notenames.qml:

Here is the same score using the updated notename-v2.qml (attached to this posting) that uses the exposed element.posX/Y values:

Here's a another example of chord stacks... As before here it is with the shipping notenames.qml:

and here are the results using element.posX/Y exposure:

-Dale

I've finished work on MuseScore's notenames.qml plugin and pushed the changes up to github.

Here's the output from the current version of notenames.qml with a four voice score:

Here's the output from the updated version of notenames.qml:

-Dale

That data is certainly in there.

I can see how having bounding boxes available would be really valuable.

I'll take a look!

-Dale

If you're interested in exploring the possibilities I've created commit on top of this issue's work that provides read-only access to this Element values:

  /**
   * Reference position of this element relative to its parent element.
   *
   * This is an offset from the parent object that is determined by the 
   * autoplace feature. It includes any other offsets applied to the 
   * element. You can use this value to accurately position other elements 
   * related to the same parent.
   *
   * This value is in spatium units for compatiblity with Element.offsetX.
   * \since MuseScore 3.3
   */
  Q_PROPERTY(qreal posX READ posX)
  /**
   * Reference position of this element relative to its parent element.
   *
   * This is an offset from the parent object that is determined by the 
   * autoplace feature. It includes any other offsets applied to the 
   * element. You can use this value to accurately position other elements 
   * related to the same parent.
   *
   * This value is in spatium units for compatiblity with Element.offsetY.
   * \since MuseScore 3.3
   */
  Q_PROPERTY(qreal posY READ posY)
  /**
   * Spatium value for this element.
   *
   * \since MuseScore 3.3
   */
  Q_PROPERTY(qreal spatium READ spatium)
  /**
   * pos value for this element.
   *
   * \since MuseScore 3.3
   */
  Q_PROPERTY(QPointF pos READ pos)
  /**
   * Bounding box for this element.
   *
   * \since MuseScore 3.3
   */
  Q_PROPERTY(QRectF boundBox READ boundBox)
  /**
   * Canvas position for this element.
   *
   * \since MuseScore 3.3
   */
  Q_PROPERTY(QPointF canvasPos READ canvasPos)
  /**
   * Page bounding rectangle for this element.
   *
   * \since MuseScore 3.3
   */
  Q_PROPERTY(QRectF pageBoundingRect READ pageBoundingRect)
  /**
   * Canvas bounding rectangle for this element.
   *
   * \since MuseScore 3.3
   */
  Q_PROPERTY(QRectF canvasBoundingRect READ canvasBoundingRect)

Here is the branch you can use to test the new proposed plugin apis.

https://github.com/DLLarson/MuseScore/tree/plugin-expose-element-pos-in…

It builds on the PR for this issue so you would get the posX/Y features as well.

Unfortunately you will have to build this patch on your own as I don't want to send this on to the main MuseScore repository without a feature request issue to hang it on. I don't want to muddy up this particular issue.

If you would like to compose a feature request I would be happy to move this info into that place for discussion. At that point I can create a WIP pull request to the main repo where it can be tracked.

I've also attached a plugin script that just dumps all this data to the console to see what's provided.

-Dale

Yep... I'm in the middle of exposing the tie stuff. Just started testing. It would be good if we had an actual issue to hang the pull request on for it though. A sponsor so-to-speak. ;)

I don't want to muck up this issue with the other.

-Dale

>I hope you read my (this morning version) of "adjusting tied notes", w

Yes I did. I did expose the Tie stuff as well.

I think it needs some exercise to determine usefulness.

I just pushed it up to my fork of the MuseScore repo:

https://github.com/DLLarson/MuseScore/tree/plugin-expose-note-ties

I won't make it a PR until it has a issue for it though.

This issue has now been closed as they merged my changes to master.

-Dale

Ok...

I've attached a test script to this post.

-Dale

Hey.... Don't look at me! I don't have a music license....

-Dale

>implying that you wrap notes in some newly-allocated QML wrapper each time,

I intentionally didn't mention it to see if it would be noticed. And....Ding...Ding...Ding!!!!

Yes! You are correct, in fact near as I can tell it's always been true. This is the first time I wanted to make a decision based on comparing notes and found it useless.

I'm looking to see if Qt exposes a unique object id rather than creating something. The obvious need is to compare the addresses of what the wrappers are pointing at. This isn't a unique problem so I'm going to look at what the QML/C++ integration stuff does (or doesn't).

-Dale

>My career as an operating systems programmer...

Time for a throw down.... ;)

>how, when i call in to set some property of a playEvent or a note, do you know which internal object I'm talking about? The back-pointer must be in there somewhere.<

Of course there is!

We just have the n-wrappers to one object mapping that Javascript isn't aware of. It's a MuseScore contrivance--kinda like onRun. I don't see a language supported method so...

If the underlying Qt objects were directly exported to QML like I think it was in MuseScore 2 you wouldn't have the problem since there is no wrapper.

At this very moment I'm testing exposing 'Element.elementId' on all elements which, essentially gives you the underlying object address. When I'm happy with it I push the change up and drop a note.

-Dale

I'm back!

I just pushed up a replacement commit for the branch. It add elementId to all elements. I will tell you that 64bit addressing is a PITA when trying to make sure you don't overflow numbers. C++ is VERY picky about even type casts now!

https://github.com/DLLarson/MuseScore/tree/plugin-expose-note-ties

I've attached a new version of the test script at is seems to work very well a discriminating elements.

>then js can build a hash-table on it or whatever is necessary... js has to do the garbage-collection -- the C++ side can't know if these objects are in use or not, so it can't efficiently maintain its own hash-table.<

The plugin framework already handles that (thankfully!) all wrappers are owned by QML engine. The objects they refer to are another matter but also accounted for.

Give it a go!

-Dale

> do the wrapper objects corresponding to the real objects referenced by Note (or any element) exist at any time earlier than my reference to the object properties pointing to them?<

No. They are created on-demand. They are also cleaned up via garbage collection (gc) or when the QML engine destroyed.

>Are there any fields of a QML object representing an MS element, other than elementId and anything a user stores in it, which are actually in the js object, and not implemented by calls in?<

I'm having a problem parsing this question.

My best stab...

FIrst you can't change the elementId. It's read-only and invariant. It is literally the address of the MuseScore object pointed to by the wrapper object. In addition wrapper objects are always owned by the QML engine so they will be garbage collected when nothing references them and a gc is triggered. The thing they are pointing to may or may not be owned by the QML Engine. If you create an element with newElement it is owned by the QML engine until it is added to the score. Then it switches ownership to the C++ code so the QML engine won't delete it during wrapper gc.

In general the only thing in a wrapper is the pointer to the wrapped object. It's all delegation to the wrapped object after that.

-Dale

>You are saying that even atomic-object fields (e.g., "pitch") are delegated to C++ to read that field at access time?

Yes. Exactly. Very thin interface.

>Hopefully, js can store its own values in these wrappers

Why would you want that? I'm missing the utility here.

Are you wishing you could amend the functionality of the wrapper's Javascript object?

You can do stuff like this:

 var note = notes[idx];
 note.joe = "this is a test." // Create new property named 'joe'
 console.log("note.joe=" + note.joe) // It exists here.
 console.log("note.firstTiedNote.joe=" + note.firstTiedNote.joe) // But not here since a different wrapper to same note (in this case anyway).

I don't think you can add functions/properties to the underlying wrapper 'class' (or prototype in Javascript parlance.)

-Dale

Ohhh. I forgot to mention...

I pushed up an updated commit for this work. It moves the elementId up the class hierarchy to ScoreElement so Parts and Score's can be compared as well.

-Dale

>Are we having the discussion here about object identity?

I hope so! The PR was just inspected.

The elementId addition was pulled from the commit due to objections until a discussion takes place. I've directed the GitHub PR to here for the discussion. Let's see what happens.

https://github.com/musescore/MuseScore/pull/5258

Check out dmitrio95's comments there.

We may ultimately want a separate issue for the discussion though. This particular issue is closed.

-Dale

I created an issue for the object comparison problem and initially submitted the elementId mods to a PR associated with that issue:

https://musescore.org/en/node/293837

We should continue discussion there.

-Dale