Why does curScore.staves fail?
Based on the documentation "staves" is a list property of score. Yet the below code produces errors, as shown below as well.
var listOfStaves = curScore.staves;
console.log("---- ---- Do We Have a List of Staves Object? <", listOfStaves.length,">");
Warning: QMetaProperty::read: Unable to handle unregistered datatype 'QQmlListProperty' for property 'Ms::PluginAPI::Score::staves'
446:-1: TypeError: Cannot read property 'length' of undefined
(I am using the Musescore 3.6 release)
If it matters, in the same qml file, the following references work just fine:
curScore.parts
curScore.selection
Any help or hints appreciated.
Comments
Seems to be a bug, I have created a pull request to correct this.
As a partial workaround, if you only need staves count you should be able to use an older nstaves property of
Scoreobjects. Also you can find a staff for a given element by using its staff property, that also appears to work correctly.In reply to Seems to be a bug, I have… by dmitrio95
Ok, at least I'm not crazy then. I did figure out another way to get what I needed.
What I needed was to find the pathway to get at the instrument stringData object for a given staff index. I was able to get to it via a pathway from the Cursor, by first ensuring I had the cursor on a valid element object.
(For example, I have, let's say, 6 staves among a few parts and instruments. I have the staffIdx value for a specific TAB staff I'm going to work on within my plugin. What I need is the open string tuning for the instrument that staff represents. I haven't been able to directly get to the stringData object from a staff. But given a staff object I can get the part it is within, and then I can confirm that part has a tab staff; and I can then walk through that part's instrument list and finally get the stringData. Way too convoluted - but it's the only way I've work out to do it. (Of course, it kinda goes without saying, methinks, that one should be able to retrieve stringData directly from the staff object as each given staff must be associated to one, and only one, instrument.))
In reply to Ok, at least I'm not crazy… by rocchio
> each given staff must be associated to one, and only one, instrument
Actually each part may be assigned multiple instruments, although only one can be active at a certain point in time (see also
instrumentAtTick()method ofPart). This may result from Instrument Change elements if they are present in a score. Also a part may contain multiple staves (for example, a grand staff for piano consists of two staves belonging to the same piano part). Therefore the structure of objects is that somewhat complicated — and it actually mostly repeats the structure used internally in MuseScore. I agree that certain shortcuts for this structure could be helpful, but when initially implementing instruments API in PR 6090 I thought it would be good to get the most basic access to this structure working, and this API has not been modified since then.In reply to > each given staff must be… by dmitrio95
Yes, you are, of course, correct dimitrio. Being only an amateur musician I do tend to under appreciate the full complexity of music. I should probably fix in my head the truer fluidity of the Staff. It is a flow across time; with tempo changes occurring, maybe key changes, instrument changes, et al. As an old data-modeler from the dawn of the information engineering age I have a tendency to want to see systems from a static-data perspective. Thanks, and have a great day!
In reply to > each given staff must be… by dmitrio95
The PR got merged into the 3.x brnach, so would be in a corresponding development buid not, and in 3.6.3 if and when zthat happems. It seems needed for master too though, for it to be in MuseScore 4 one day
^ what he said